Part 2/2.
V. Transparency
We strive for complete openness and symmetry of information within the
organization, and have no border between our core contributors and our
community. We are frank about our shortcomings, especially when making
short-term tradeoffs in service of our long-term goals.
TRA-1. Lack of insight and control into what is collected, communicated and leaked
Principles violation
transparency, security, privacy
Details
Lack of clarity on how transparent we are, how and what we track. And what we
leak.
Example: Paranoid mode to switch off, no collect data should be possible
ideally. Example: Testfairy.
Additionally, copy of actions as a form of audit log based on actions taken in
Status.
The app doesn’t make our approach to privacy and data very clear. When you open
Status, it looks like a messenger/wallet app - it’s not clear what our policies
or unique features are.
Success looks like? no collection of data, UI/UX for a user to understand which
state they are in. Clear to the user from first install/look what we are, and
how we store data.
Additionally: Leak metadata in logs and sometimes data. This one was identified
in Basel already.
Exposing user data in the logs is equivalent to making it available to anyone
with some amount of technical ability.
TRA-2. Transparancy in Technical Flaws
Principles violation
transparency
Details
This one was identified in Basel already as item 10. Success metrics for this
are unclear, so it is still here. Voting will decide how much of a problem this
is.
Sometimes we convey that our tech is more decentralized or secure than it really
is. Lack of technical proofing of communications leads to this problem. (hence
this document!)
Being (very partially) tracked here:
Related: being explicit about security guarantees, which can be used in
communication
TRA-3. Marketing: Community not involved enough in decision making.
Principles violation
transparency
Details
We don’t really include the community in decision making (or have the tools to
do so), so we’re not really transparent with them as a result.
TRA-4. Lack of easily discoverable decision record artifacts.
Principles violation
transparency, resourcefulness
Details
Decisions are being made, but it can be hard to see where ideas/decisions come.
Sharing more leads to information overload.
ARDs in status-react is example of a small improvement that hasn’t been useful,
but somewhat haphazardly applied.
Additionally: Lack of easily discoverable documentation for QA/release/security
process.
See example of nightly releases and TestFairy seedphrase bug. Even if we have
guidelines they aren’t universally discoverable.
Also:
- Sharing clear notes/outcomes from meetings
- Potentially recording some/all meetings
- Async-consumable meeting notes often lacking
- Better quality notes, recording decisions in public place
Way to go, 51% through the book of shame. Have a cookie! And some milk with it. Keep it up.
TRA-5. Lack of public financial information.
Principles violation
transparency
Details
A clear financial disclosure policy detailing what information we will share,
and what information we will not share (and why). Also relates to fund usage.
TRA-6. Lack of defining transparency in terms of how it helps achieve our goals.
Principles violation
transparency
Details
Are we being too hard on ourselves? What’s the point of all this transparency?
Does it actually get us closer to mass adoption of Ethereum? This is lacking
right now.
TRA-7. Not clear how to get involved as a potential contributor.
Principles violation
transparency, resourcefulness
Details
YT/docs/GH good, not entirely clear how to get involved, many data/places to
look, where participate?
NOTE: Related to above re CC and how to make impact.
VI. Openness
The software we create is a public good. It is made available via a free and
open source license, for anyone to share, modify and benefit from. We believe
in permission-less participation.
OPE-1. Reliance on closed and permissioned systems.
Principles violation
openness, decentralization, transparency
Details
Example: Google, Slack, and other identity authorization systems are closed and
permissioned. It’s gotten better as we move from Slack, but we still require
Google accounts to get access to much information. And we have other systems in
this general class.
Additionally, we lack an inventory and rationale for the centralized and
propietary services we use. We should describe these and be clear about what we
are using and why it is justified. This can take the form of a service policy.
This also extends to closed repositories of code and information, both in Github
as well as ad hoc.
This one was partly identified in Basel as 25. We rely on Github to host our
code repositories.
OPE-2. Closed financial info and lack of roadmap.
Principles violation
decentralization
Details
Financial information is largely closed right now. It isn’t clear what a roadmap
looks like to get to openness, as well as how to balance this with individual’s
right to privacy.
OPE-3. No consensus on how to balance security and openness.
Principles violation
openness, security
Details
As an open organization with an emphasis on security, we need to be clear on how
we can balance these two commitments. Right now there’s no general policy for
how to balance these things when it comes to things like: security incidents;
dealing with poisioned binaries, etc.
A document that outlines ways of dealing with specific situations, common-law
style, would be useful for core contributors in knowing how to orient themselves
in these matters.
OPE-4. License situation across the board is unclear.
Principles violation
openness, continuance
Details
We produce a lot of code and artifacts in the forms of words and designs, but
the license situation for this isn’t clear across the board. For example, a lot
of things are marked as CC-0 explicitly but we also produce content that isn’t
marked as such. Another example is dependencies, and precise situation around
GPL (status-go) in App Store.
OPE-5. Status Network is a non-rival good, not a public good.
Principles violation
openness, decentralization, continuance, resourcefulness
Details
Right not the Status Network is a non-rival good. That is, more nodes connected
doesn’t necessarily lead to more capacity for the network as a whole. This is
unlike torrent files, where more nodes lead to better overall capacity.
Further example: cost of running mail servers / boot nodes not incentivized.
OPE-6. Lack of open protocol.
Principles violation
liberty, openness
Details
Lack of open protocol, hidden inside application, want ecosystem to use protocol
to build something bigger.
Additionally: lack of instructions for how to use it outside of app.
OPE-7. App not available publicly in the App Store.
Principles violation
inclusivity, openness
Details
This limits our use, since Status isn’t freely available.
VII. Decentralization
We minimize centralization across both the software and the organization
itself. In other words, we maximize the number of physical computers composing
the network, and maximize the number of individuals who have control over the
system(s) we are building.
DEC-1. Centralized decision making re hiring/salary/headcount.
Principles violation
decentralization
Details
DEC-2. OSS project but only core contributors contributing.
Principles violation
decentralization, openness, inclusivity, continuance
Details
Success looks like? Having contributors that are not only core.
Having only core contributors contributing presents many of the risks that come
with centralization including how does the project continue if the core
contributors are no longer around? A possible reason for lack of external
contributors is accesibility to average developers.
Idea: Run DX (Developer Experience) sessions during Prague, pairing core with
external developers to try and see how external developers try contribute.
DEC-3. We are a hybrid organization with downsides of both.
Principles violation
resourcefulness, decentralization
Details
As a hybrid organization, we are inefficient as a traditional corporation as
well as not living up to being a DAO, with all its benefits. We should pick one,
or find a way to get the best of both worlds.
DEC-4. Requires JSON-RPC server to work (SPOF) [in progress]
Principles violation
security, decentralization, censorship-resistance
Details
This one was identified in Basel already as item 3. Progress has been made but
still not repented.
JSON-RPC is the only means by which a user can connect to Ethereum using Status.
It’s a trusted intermediary, not decentralized. Light client/ULC is required for
decentralization.
Being worked on Requires JSON-RPC server to work (SPOF) · Issue #5588 · status-im/status-mobile · GitHub (better
home probably exists).
Related: Status Node and Status Ultra Light Node
DEC-5. Zero people running Status nodes.
Principles violation
decentralization
Details
Success looks like? People running Status nodes
DEC-6. We run specialized nodes (mailserver).
Principles violation
decentralization, continuance, inclusivity
Details
If we are running all the mailservers that is a central point of failure for the
network, but if no individuals runs nodes we can’t take the nodes down since
there will be network issues if that happens, this leads to lessening intrinsic
motivation to run nodes and there is currently no deployed economic incentive
mechanism for people to run nodes.
This relates to being able to run all services on one node. Being able to run
all services on a single node makes it more likely the services will run on more
nodes, having to run multiple nodes is likely to turn away some operators.
DEC-7. Reliance on small number of fiat bank accounts.
Principles violation
decentralization, resourcefulness
Details
The need of convert to FIAT generates burocracy within the company and makes the
shift for a DAO more difficult.
Solution: Pay only using SNT, ETH or a decentralized stable coin (e.g DAI).
Burocracy to convert to FIAT (and configure it’s own legal setup) is up to
collaborator.
DEC-8. Organization design is somewhat centralized.
Principles violation
decentralization, continuance
Details
Decision making is centralized into status core developers.
Solution: Status DAO
DEC-9. We don’t have a strong open source community (dependence on CCs).
Principles violation
decentralization, continuance, inclusivity
Details
Core contributors are the only experts on Status.
Solution: Increase popularity, better documentation, easier extendability,
simplier programming languages.
VIII. Inclusivity
We believe in fair and widespread access to our software, with an emphasis on
ease-of-use. This also extends to social inclusivity, permissionless
participation, interoperability, and investing in educational efforts.
INC-1. Status doesn’t run well on old cheap devices/OS.
Principles violation
inclusivity
Details
There are many older devices where performance on Status is so-so, or at least
poorly understood. This also extends to running on tablets, as well as old
versions of e.g. Android.
Having clarity in what we support and rationale would be a minimum here. Better
would be provable coverage for certain regions of the world.
INC-2. Difficult to contribute to Status.
Principles violation
inclusivity, transparency
Details
Manifests itself in many ways.
For example: Desktop codebase opaque, requires skillset in multiple uncommon
languages.
Also: building Status is not easy to the average developer.
Right now building Status is too complicated. This a minimum to allow
contributions, and your average web dev should be able to get it up and running
within a few minutes and high success rate.
Related: mbark: reliance of closed and private tooling for development. On
Embark itself we do a lot of things internally. Can be more open about processes
etc. Ex: We use pivot tracker, private, discuss things privately, etc. Can use
more public bug tracker/public channels instead. Also ongoing discussion vs
privacy. Know context for PR/bug fix as non CC.
INC-3. Lack of educational content with community-driven input.
Principles violation
inclusivity
Details
Ability to run, study, modify Status and its associated code and protocols.
Evidence of success would be community contributions to Status documentation,
fewer people saying education/documentation is an issue, and generally good
coverage of identified key areas that need education.
Relates to Status Studio and leveraging community to create content.
INC-4. Lack of non-english resources.
Principles violation
inclusivity
Details
Principles are only in English; social media English-heavy; Chinese community
starved of news; lack of ability to collaborate across languages (e.g. direct
live translations), including Town Hall / Core Dev calls / release notes.
Evidence of success would be higher inclusion activity, and especially
bi-directional communication, with non-English speaking audiences.
INC-5. Lack of proper contributor and user metrics.
Principles violation
inclusivity, continuance, resourcefulness
Details
We don’t know how well we are doing in terms of monthly active contributors and
daily transacting users. The metrics we have are haphazard and not very
rigorous. We need a way to succeed and fail at a reasonable time scale, such as
weekly. This informs efforts. These metrics should be in one place as opposed to
siloed up in various random documents.
See “Engineering Status Network for Growth” post on Discuss and
analytics.status.im for a start.
Evidence of success would be one place that captures metrics on a reasonable
time frame, as well as outlines metrics that aren’t tracked but should be. Easy
to add new types of metrics from any team to measure efforts.
INC-6. App barely useful enough for even us to rely on it.
Principles violation
inclusivity
Details
Not being useful means we limit widespread use and don’t have an emphasis on
ease of use.
Evidence of succcess would be Status contributors relying on Status, using it a
lot and prefering it for other other solutions.
Related: spam in chat, which was identified as item 13 in Basel. People post
irrelevant or malicious messages in public chats, degrading the quality of the
experience.
Related, item 21 in Basel: Moderation in Chat.
Spam and offensive content happens, and we have no measures in place to protect
public chats from being totally corrupted.
INC-7. Hard to get SNT and ETH in the first place.
Principles violation
inclusivity
Details
Most people don’t have crypto, and especially not SNT. Currently it is hard for
people to get SNT as part of onboarding. This relates to Status Teller Network
and use of Trustlines, and others.
INC-8. Dogmatic design system.
Principles violation
inclusivity, resourcefulness
Details
There’s no design guideline or toolbox that allows people to remix and take
decentralized action and design Status in a Status-like way.
Evidence of success would be Random Joe being able to easily riff on our design
as a developer, and build something Status-like that doesn’t require central
coordination with Status Design, without looking like a copy and paste.
Additionally: lack of component library (modules and designs) for dapp
developers.
INC-9. Users leaking seedphrase
Principles violation
security, inclusivity
Details
This one was identified in Basel already.
Use error. IF users back up their private phrases, they will screenshot, email,
write on paper and throw away, etc. Current UX allows for screenshotting, lazy
users (including myself) will do so. This problem compounds with time as the
user does not care about the value of their wallet at the beginning when it has
nothing in it, but with continued use assets will accumulate and the threat gets
larger.
You made it 75% way through this book, wow, have another cookie!
IX. Continuance
We create software incentivized to continue to exist and improve, without the
stewardship of a single entity or any of the current team members.
CON-1. Lack of work on protocol and app done by non core contributors.
Details
This is way too long. The tldr is that we rely on CCs and don’t have enough
active community involvement, like Ethereum project.
Working on the status client takes time and a working knowledge of closure.
Adding an issue to Status requires use of the client and a desire/investment to
see it improve.
Success looks like: As a true open-source project we see developers contributing
to the status client. Creating PRs and issues.
Possible solutions:
- With other open source projects, first and foremost the project needs to be
used by the contributors. We have made good strides with leaving slack and
moving on to Status. Perhaps a solution looks like moving other organisations
which share similar principles on to Status. - Modify Status for dapp developers. If dapp developers find they can provide
better user experiences for their user base on Status through extensions and
chat notifications, it will be in their interest to work on the platform in
order to keep their user base happy. This solution increases its strength if
dapp developers can access users by having a presence on the Status dapp.
Currently there is no work been done on the status protocol outside of core
contributors.
The status network is a series of servers which run mail software and a
configured version of whisper. The reason for this is that whisper, in its pure
form does not make for a human usable UX, often dropping messages and requiring
both users to be online at the same time. The status network protocol aims to
facilitate human communication which is decentralised. Decentralisation brings
value to human communication through:
- Censorship resistant. In theory, just like how no one can take down bitcoin,
the status network should be able to facilitate human communication despite
attacks/DDos or IP address blocking. - Secure. Communication defeats traffic analysis so that watches may not know
where a message was sent from and where it ended up. - Private. Through techniques like perfect forward secrecy a user’s
communication remains private. To provide these benefits at a level comparable
with web2 standards requires work and attention from academics and experts in
protocol design.
Possible solution: Heavily influenced by Ethereum, a solution to this problem
requires organisations outside of status finding the benefits of the status
network protocol valuable. The more people who find value in the protocol will
mean its in their best interest to participate and improve the protocol.
Success? - Similar to how Ethereum manages protocol upgrades and improvements
through open debate, academic peer review and conferences.
CON-2. Currently there is no incentive to run Status network nodes.
Principles violation
continuance, decentralization
Details
Currently the status organisation hosts and pays for the whisper and mail server
nodes that give status users a chat experience which is comparable with to web2
experiences. If the status organisation has its funds seized and cannot pay for
the nodes the network will stop existing. People require an incentive to run
status network nodes which does not depend on direct financing from Status
companies.
Success looks like: There is an inherent incentive to run Status network nodes
resulting in a strong, decentralised network.
Possible solution: We just need a ton more focus on this problem from experts to
create protocol capable incentivising its existence.
CON-3. Most contributions to Status protocol and app from core contributors
Principles violation
continuance, resourcefulness
Details
CON-4. Hardcoded public chat and Dapp list
Principles violation
continuance, decentralization, censorship-resistance
Details
Currently the list of Dapps and public chats requires a CC to manually updated.
If the CC team had to disappear then list would stay the same and limit
discovery of Apps/Public chats. Additionally it’s an attack vector for
censorship.
Possible solution: A method of discovering public chats/dapps which is
accessible, fair and does not depend on CC to updated it.
Success looks like: The discover of Dapps and public chats do not rely on CC
updating a list.
CON-5. Status project require funding from the Status company.
Principles violation
continuance
Details
Updating and creating new content for Studio, want community contributor to
contribute to it. Ideas but nothing execurted on right now
CON-6. Status is a centralized company.
Principles violation
continuance
Details
Hire people in old employee model, don’t lend itself to working on replacing
yourself kind of mindset, succession plan not reliant on single people (Should
this be bounties or opensource model whereby people can earn money off the
opensource software and thats the incentive to partake/add to it) + Centralized
company structure without open governance. Lots of information is opaque, such
as finances, hiring, roadmap, etc (is this only a problem if we have money in
bank? In the sense that this stops becoming a problem once we run out of money
and hopefully by that stage the software is running on its own). + We don’t have
a structure for further funding or continuance that isn’t based on one big one
time Status multisig + We lack a rigorous alternative to P&L, no breakevent
point
Problem: Status needs to pay people to work in it. If it runs out of money then
no more work will get done on Status.
Success looks like: People working on status without compensation from the
Status company.
CON-7. No incentive to run Whisper or Status nodes.
Principles violation
decentralization, continuance, censorship-resistance
Details
Without an incentive to run whisper nodes there are centralization and
censorship vectors if only a few parties have an interest in running nodes and
if those parties leave the network the network is unlikely to survive.
Success looks like? A network of nodes run by many operators with a clear
incentive model for why the nodes are being operated.
CON-8. Vast majority of our work is never incentivized in open form.
Principles violation
inclusivity, decentralization, continuance, resourcefulness
Details
Currently most work is done by core contributors, not even giving the
opportunity for other people to join in and contribute and get paid for their
efforts. This is connected with current tenure model and not creating proper
issues for problems before attacking them.
Evidence of success would be more contributors, as well as more “money up for
grabs” in an open permission-less way at any point in time. Especially for
smaller efforts (not $1m OSS grant but 1000 $1000 bounties).
CON-9. Reliance on a single legal entity.
Principles violation
decentralization, censorship-resistance, continuance
Details
We rely on legal entities in government jurisdictions to function as an
organisation. This legal entity can be threatened to stop development.
This can be mitigated when we ascened to a DAO.
Solution: Status DAO, decentralization of formal companies, stop paying in fiat.
This one was identified in Basel already as item 27.
X. Resourcefulness
We are relentlessly resourceful. As we grow and have ready access to capital,
it is our obligation to token holders to fight bureaucracy and inefficiencies
within the organization. This means solving problems in the most effective way
possible at lower economic costs (in terms of capital, time and resources).
RES-1. We are a hybrid organization with downsides of both.
Principles violation
resourcefulness, decentralization, transparency
Details
As a hybrid organization, we are inefficient as a traditional corporation as
well as not living up to being a DAO, with all its benefits. We should pick one,
or find a way to get the best of both worlds.
Additionally: in a hybrid DAO/LLC model, unclear what multisig paying for vs
tenure mode. Right now it’s more of a tenure model.
RES-2. Not doing MVPs in a way that serves our OKRs.
Details
Approach to designing MVP, we do big bang designs that require building raw
materials from scratch vs using core components. Not aligned with most OKRs. If
not aligned, why do it? More doing it for other reasons, not explicitly stated.
Bureaucracy etc. Takes longer to build and iterate and learn from users. Can be
done by out of box components and iterate on them.
RES-3. Lack governance tools to make financial decisions.
Principles violation
resourcefulness, continuance
Details
As hybrid, not clear how we make decisions on how much money we spend on people,
things, travel, etc. Lack of visibility / collective oversight on spending.
Don’t have tools for that.
Don’t have governance tools to even do that (financial oversight etc, spending
decisions).
Additionally, on the softer side, there’s the following feeling: there was ICO,
we cash rich, can do whatever. Get into more mindful space. Finite reserve think
mindset. Financial awareness lacking a bit. Mindset not obvious.
RES-4. Lack of analysis in core economic questions.
Principles violation
resourcefulness, continuance
Details
Lack strong opinions on direction to take. E.g. ENS username price set,
important decision. Not enough people who can take opinion of what price is.
Analyze and give answer. Economic decision. Related to information security and
cryptoeconomics.
RES-5. Can’t be resourceful without knowing what building.
Principles violation
resourcefulness
Details
Hard to be resourceful if you don’t what building. E.g. host dinner party 4
people. Going to buy right portions. For us could be 4 people or 200, could be
vegans or meat eaters, not a dinner it is a cocktail party. Etc. Greater clarity
on exactly what building.
RES-6. We don’t understand what resources we have.
Principles violation
resourcefulness
Details
Being resourceful means understanding understanding you have which we don’t do.
Need clear insight. Weakest principle of all of them. Specifically chose org
structure that is inefficient and other principles have priority.
RES-7. We lack a financial mindfulness mindset.
Principles violation
resourcefulness
Details
Feeling: there was ICO, we cash rich, can do whatever. Get into more mindful
space. Finite reserve think mindset. Financial awareness lacking a bit. Mindset
not obvious.
RES-8. We don’t security audit on-boarded core contributors.
Principles violation
security, resourcefulness
Details
Because the majority of organizational security is in the hands of the Core
Contributors, we must have a standard bar of security practices amongst them. In
order to get newcommers to that bar, we have a session with them to inform them
of what it is, and educate them on getting up to it if they are lacking.
Success: On-ramp process has security audit session, as well as a definition of
what the “security bar” is.
RES-9. Even as CC not clear where to make impact and find recent state of effort.
Principles violation
transparency, resourcefulness
Details
What is starting point in various efforts? A lot of things going on, and not
clear how any individual core contributor, let alone community member can make
an impact, see recent state of things, etc.
Appendix: largely solved
Largely solved already. Non-exhaustive list - other items from Basel might
already be solved but not in here.
BASEL-1. Seedphrase stored in database [SOLVED]
Principles violation
security
Details
This one was identified in Basel already.
An attacker who gets access to our database and our encryption key can decrypt
all passphrases for each user, that has not backed up their passphrase yet (in
which case the passphrase is no longer stored in our database). The database
itself is encrypted but ideally, passwords and seedphrases are something that we
should never store on a disk. Other sensitive data, like chat history, should be
encrypted and accessible only by the user’s password.
Being tracked here: Encrypt account realm with user password · Issue #5180 · status-im/status-mobile · GitHub
BASEL-2. Weak certificate checks [SOLVED]
Principles violation
security
Details
This one was identified in Basel already.
Browser only validates whether SSL certificates are valid or not. Phishing sites
can have valid certificates. By comparison, Google Safe Browsing checks
suspicious terms from a site against Google servers.
Being tracked here: Stronger security checks in browser · Issue #5583 · status-im/status-mobile · GitHub
Additional issue: Implement Google Safe Browsing · Issue #6398 · status-im/status-mobile · GitHub
Related issue:
SSL certificate pinning
Largely solved but not 100%.
BASEL-5. Replace usage of MixPanel [SOLVED]
Principles violation
security, privacy
Details
This one was identified in Basel already.
MixPanel is against our ethos and holds data about product usage. We can’t
protect that data. MixPanel has leaked passwords in the past.
Being tracked here: Remove Mixpanel · Issue #5169 · status-im/status-mobile · GitHub
BASEL-19. Reliance on Slack [SOLVED]
Principles violation
privacy, decentralization
Details
This one was identified in Basel already.
Slack is centralized. We’re sending them all our chat history.
Essentially solved with move to Status.
BASEL-16. inject web3 w/o asking for permissions [SOLVED]
Principles violation
privacy
Details
This one was identified in Basel already.
To enable DApps to make transactions on the network, we inject a standard web3
object into the DOM of any site. This object shows not only that the user is on
Ethereum, but can leak more sensitive data related to wallet and transactions as
well. EIP 1102 presents a new standard to correct this.
Addressed.
Wow, you actually made it to the end. Have another cookie! See you in Prague 