Book of Shame and opportunity, Prague edition (2/2)

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-react · 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:

  1. 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.
  2. 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-react · 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-react · GitHub

Additional issue: Implement Google Safe Browsing · Issue #6398 · status-im/status-react · 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-react · 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 :slight_smile: