Principles from Basel

Archive
1

During the Basel Secure messaging met up we spent some time discussing principles at Status - the things that we value the most, and how these will feed into product decisions.

We started with a “wall of shame” - a list of items people have concerns with, followed by a list of possible product values reflecting why these items were concerning. We then clustered these sets of values into key areas. This resulted in nine key areas / principles.

These principles are very much a work in progress and they overlap with some existing work. Here is the outcome of this.

Principles

1. Liberty

We believe in the right of individuals to have autonomy and responsibility over his or her own life. We aim to maximize social, political and economic freedoms. Status is an agnostic platform.

2. Censorship resistance

We aim to avoid the suppression of information. No content is under surveillance. One of the design goals of Ethereum is to be censorship resistant, and we should provide the same guarantees across Status.

3. Security

We don’t compromise on security when building features. We will use state of the art and research new security methods and technologies to make strong security guarantees.

4. Privacy

The power to selectively reveal oneself to the world. Protecting privacy in communication and transactions, as well as the right to total anonymity.

5. Transparency

We strive for complete openness and symmetry of information, and have no border between our core contributors and our community. We will be frank about our faults, especially when making short-term tradeoffs in service of our long-term goals.

6. Free culture

The software we create is a public good. It will be made available via a free and open source license, for anyone to share, modify and benefit from.

7. Decentralization

We will minimize centralization across both the software and the organization. In other words: 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.

8. Inclusivity

We believe in fair and widespread access to our software, with an emphasis on ease of use. Also extends to social inclusivity, inviting participation in the organization, and investing in educational efforts.

9. Continuance

We aim to create software that will continue to exist and improve without the stewardship of a single entity or any current team members.

Trade-offs, considerations and example applications

Liberty

Considerations:

  • Distribution in markets like China - is potentially releasing a subset of Status a net benefit in terms of liberty, provided we are transparent about it?

Example application:

  • We will not compromise freedom of speech or right to assembly by even having the option to selectively prevent this.

Censorship resistance

Security

  • Tradeoffs: Lack of PFS, cluster size, seed phrase storage, bandwidth usage, password and seed phrase UX, distribution channels (App Store, Play Store), DevP2P encryption broken.

Privacy

  • Tradeoffs: Ethereum / unshielded transactions, same key for chat/Dapps/wallet, users can’t remove contacts, transactions are public, no plausible deniability, MixPanel.

Transparency

  • Tradeoffs: Marketing messaging is not open about our faults, we don’t document the tradeoffs that we’re making.

  • Considerations: Finances aren’t public, but complete tranparency may violate laws in some jurisdictions

Free culture

  • Tradeoffs: Slack/Google Docs, finances, cluster repositories are private.

Decentralization

  • Tradeoffs: cluster, mailserver, infura.io.

  • Considerations: We’re choosing efficiency.

Inclusivity

  • Tradeoffs: Slack/Google Docs, device minimum requirements, barriers to entry in contributing.

  • Considerations: We’re focused on mass adoption but making concessions in security and elsewhere.

Continuance

  • Tradeoffs: cluster, core contributors dependent on fiat payroll, lack of transparency from using Slack, lack of incentivization to run nodes.

  • Considerations: We have no pressing need to be more resourceful because we have the means to sustain ourselves for a long time.

Raw links

Voting doc: https://docs.google.com/spreadsheets/d/1RaI3XvcCD6QsnKtAGIV1Btch8gcXEotdNvY4FOR3Fto/edit#gid=0
Video: TBD
Principles doc: My first HackMD note (playground) - HackMD

Questions

  1. Are there any principles that seem unclear, nonsensical or not meaningful to you?
  2. Are there any principles you disagree with?
  3. Are there any principles you feel are missing?
  4. What are some examples of trade-offs, considerations, and practical applications of these principles?
9 Likes
2

Is there a backstory on the “subset of Status” in China? Curious to learn more about what that means in this context.

4

I believe the example proposed was the following: one could imagine a scenario where some App Store approval would only be contingent on certain modifications. If this implied installing a backdoor, the ethical thing would be to refuse (see liberty and transparency). An alternative pragmatic but ethical way might be to, say:

  • Only expose wallet or dapp browser, removing the capability to chat and be transparent as to why.
  • Making it possible and easy for individuals to build/install the full Status apk for people with technical know how.

Whether this would be a net benefit for liberty seems like an open question.

For relevant examples, see how some companies likely “resolve” this problem by installing backdoors. Others, like Lavabit email provider, shut down their service when they don’t feel confident they can securely provide a certain service. (Lavabit - Wikipedia see gag order)

1 Like
5

Not sure if this was discussed or it is implicit here, but what about avoiding manipulation -by design or other methods- and allow the user to feel in control? One good example is our “share data” feature that was re-designed avoiding dark patterns, contrary to how companies like Google and Facebook use these patterns to guide with questionable intentions in mind Facebook and Google use 'dark patterns' around privacy settings, report says - BBC News.
I think this is not only related to UI/UX design but in general (communication, processes, etc.)

2 Likes
6

I would like to propose an additional Principle. Although it may reside in Inclusivity, maybe we add to it and/or rename it. Alternatively, this could sit as a preamble to the other principles.

Mass Adoption

We build and market to a global audience, with the end goal to deliver the promises of Web3 to the masses through the Status application and ecosystem.

This is one of the primary motivations that drove me to Status. Without mass adoption explicitly in mind, we risk creating an small echo chamber’esque community focused to a small audience. The principles outlined above are deserved by every person, especially those most oppressed.

This principle may result in tension with other principles, but thats the challenge at Status, and why what we do isn’t straight forward. We are setting precedents for almost every decision we make.

9 Likes
7

Yes Nabil 100% agree! I came here to propose something similar but I couldn’t have set it better.

The spark that ignited my interested in Status was Jarrad’s Devcon2 presentation where he outlined how to take ethereum to the masses. He said:

What if we could create digital spaces where we can experiment with new ideas, new economic models, new policies, and new ways of socially organizing… and what if we can use this data to discover something new and then deploy it globally within 30 seconds or less for anyone to use voluntarily. That’s the kind of world that I want to live in. But none of that is possible until we start getting Ethereum into the hands of people.

The key point for me is “none of that is possible until we start getting Ethereum into the hands of people”.

I re-watch it from time to time and I encourage everyone to give it another viewing.

26%20AM
26%20AM1696×874 255 KB

(side note… hearing Jarrad say “what if we can use this data to discover something new” is music to my ears!)

The whitepaper continued this theme and was even subtitled “A strategy towards mass adoption of Ethereum” and restated the mission of making ethereum ubiquitous. It is important to keep this in mind as we try to build for everyone.

1 Like
8

Thank-you so much Chad and Nabil for sharing your perspective, it was sorely underrepresented at this event and I think Status would have leapfrogged in it’s collective mindset if you had both were able to participate in full. I can not emphasize enough that the functions you are enshrined with are critical in our success and the values you embody and people you are in touch with impactfully colour our organisation.

On Mass Adoption

Mass Adoption of Ethereum is certainly what we’re about, but this phrase requires alot of unpacking to truly understand it (and beyond the scope of this post). I will try to express in concrete examples.

The phrase “Mass Adoption of Ethereum” is open to interpretation that can lead us in the wrong directions, to really get this and do both Ethereum & Status justice, it mandates a deep understanding of the technology and mindset.

What does mass adoption mean, and at what cost do we do so? This is an open question that we will come to understand in time.

In Basel, Jacek played devil’s advocate, putting forth a viewpoint that errs closer to mass adoption of Ethereum, sacrificing decentralization in the form of a trusted intermediary server, raising the question if this is okay?

To me, it is a violation of what it means to bring Ethereum to the masses.

This is a genuine critical error because the mass adoption of Ethereum mandates trustlessness and as soon as the client connecting has to trust an intermediary, we have failed, nothing we do matters at that point. From a technology perspective we might as well be using MySQL and PHP.

From a business perspective it also doesn’t make sense, we have to incur the cost of server infrastructure (Infura spends $500k-1M a month on servicing web3 requests) that same amount of money can be put into resources developing real solutions that benefit the individual and maximises liberty.

We are not in the business of mass adoption of a subset of the problems programmable public Blockchains aim to solve, we are here to bring that technology and it’s mindset to the masses, as close as we are able.

We cannot assume benign living or political conditions, if we get this right, we enable people to communicate in hostile environments, communication is the foundation of Law which the concept of Money rests on. We can enable communities to create their own laws, their own money, their one way to socially organize, to create societies without intervention. We can help accelerate the rise of developing countries with the tools to create firm property rights. We can remove trade barriers.

If we enable this on mass, the amount of lost capital we can capture and unlock, the socioeconomic value we can facilitate is truly beyond our imaginations, we’re talking trillions of dollars and billions of lives lifted.

Working to help others on this scale is truly what we should be doing with our privileged lives, it is our duty. It requires all of us being aligned to not make the concessions that violate that value generation, while at the same time bringing it to as many people as possible.

There is a genuine paradigm shift in how these technologies function and the mindset that goes along with it, if we get it wrong - if we make the false concessions, then none of this potential world is possible, and we would be providing no value (or worse yet doing real harm) and using the shittiest, slowest database to do so and we’re doing so for the wrong people and the wrong market in mind.

On Data:

My calls on analysing data also should not be misinterpreted and I understand it is subtle, the assumption rests on understanding how the technology fundamentally works, where the default is public, in which you can still select-fully reveal oneself, or even maintain your (pseudo)anonymity (ZK-STARKS Shielded Transactions). The user consciously must sign every state transition onto the chain, they are etching into stone. The data I am talking about is public by default, it is not held by a trusted intermediary

I will use Mixpanel as a concrete example since it has been a hot topic lately, Mixpanel is an added negative, it is not required for the system to function, even with a one-time optin, the user does not really know what is being sent about them and when or how, they (and we) have no guarantee’s in what Mixpanel does with that data (resell onto 3rd parties, happens all the time).

If we derive our analytics from data directly on chain then we are on equal terms with all, we are actively uncovering our metadata leakages. We are directly attacking our own software which allows us to further improve the software.

My comments were about analysing a concert of smart contracts, machines and people. This has little to do with Status at all. It’s about having an open transactional history of a civilization, of a way of living and identifying what works, and what doesn’t and then understanding why. This is based on open data recorded in the most perfect knowledge system human’s have invented so far. It is a realtime, living Census of all those who use it.

Inclusivity

I view mass adoption as a function of Inclusivity because we are on-boarding people into a new way of thinking, that is quite different from the status-quo. It requires real education, and there are points of friction, walls in which we may be forced to sacrifice mass adoption in certain markets until other markets have reached critical mass and can provide social proof and help with education through personal connections. More concretely, I am talking about early adopters, crypto and privacy communities before “Grandma’s”.

I am not saying not to try and design with them in mind, because later markets have alot to tell us in how to best package these ideas, but we shouldn’t purely design for them either when it comes at the cost of violating the underpinnings of the technology and principles behind the paradigm shift.

We are building for everyone, but this happens over a passage of time, and to reach some, requires reaching others first.

10 Likes
9

Agree 100%. The goal of mass adoption should be only achieved by following the other 9 principles, otherwise we’re launching a messaging app without the benefits of Web3 (imo Web3 encapsulate a lot of the principles outlined above). I still think its valid to call out mass adoption, while acknowledging that we can’t cut corners to get there.

but we shouldn’t purely design for them either when it comes at the cost of violating the underpinnings of the technology and principles behind the paradigm shift.

I also agree 100%, with the same caveat that compromising on our other values to get mass adoption is failure. Without having Mass adoption as an explicit goal (or encapsulated in Inclusivity), we could just design a console as the UI and we’d fulfill all 9 principles.

3 Likes
10

Great work! Principles are definitively something that will help me guide my day to day decisions.

In general I feel it will be pretty hard to keep so many principles in mind. A way to simplify this could be to introduce more layers and have a simple set of 3-4 core ideas, detailed in sub-layers.

I agree I’d rather not have Mass Adoption as a principle. Mass Adoption might be better suited as a goal of our organization (with concrete OKRS) than a principle (something non negotiable).

Another point to consider is how binding we want those principles to be. Are we open to relax some of them as tradeofs for short term progress?
Might be a slippery slop but given the shortcomings of the platform there might be no others alternatives.

2 Likes
11

@julien One point of our in-person discussion that is not captured in this write-up, is the idea of pragmatism. Some short-term tradeoffs are probably unavoidable, and we accept that. But the core values of the technology can not be compromised, and this document lists some of the ways in which we’ve done that.

To Jarrad’s point, in putting such emphasis on the “mass adoption” portion of our mission, we’ve overlooked the meaning of what we aim to popularize.

On that note…

We cannot assume benign living or political conditions, if we get this right, we enable people to communicate in hostile environments, communication is the foundation of Law which the concept of Money rests on. We can enable communities to create their own laws, their own money, their one way to socially organize, to create societies without intervention. We can help accelerate the rise of developing countries with the tools to create firm property rights. We can remove trade barriers.

When we think about later markets, we tend to picture people who resemble ourselves. I’d be interested in a deeper discussion about the geographic and socioeconomic markets that we hope to prioritize past the initial early adopters.

5 Likes
12

Similar to what @julien has said, I agree that “Mass Adoption” should not be a principle itself, but rather a goal. Our challenge is achieving mass adoption while being true to our principles. That means that ‘compromises’ to achieve mass adoption would not be possible, as its not a principle in itself.

2 Likes
13

@rachel, I think your on point here. It is important to identify your Early Adopters and Early Majority. For a product like Status, that would seem to be folks not in the same situation as your current Innovators. How you target and especially support that market with tech knowledge is key to success. This is an exciting process. The funny thing is you may think it will be tough to operate in a hostile regime, like say, Turkey or Syria, for example. Those will be tough environments to stay truly decentralized and trust-less, but I would argue those are only a proving grounds for the system because the governments technical prowess does not come close to what the system will face when you get to the Late Majority and mass adoption in developed countries. Then your system is dealing with real players like, the NSA, the FBI, British Secret Service and the most advanced intelligence agencies the world has ever seen. Go to the Proving Grounds first and build the system to survive in those hostile environments and take those lessons onto the big game.
That is my two cents. :slight_smile:

3 Likes
14

I would rather refer to this list as Organizational Principles. More applied, sub-layers (@julien) could be Product Principles that help us make a translation to the UI.

So far I’ve seen 3 Product Principles surface:

We notify, warn, educate, instruct, we don’t control
E.g. we will not take control by blocking uses if they haven’t backed up their seedphrase. We will rather look for creative ways to notify, warn, educate, instruct involved users.

We use positive and negative incentives as means of moderation

Security is the default.
The most secure and private option is always the default. We might offer the option to optimize for convenience (e.g. backup of messages), but only by principle of degradation and with consent of all users involved.

3 Likes
15

I’m of the opinion Mass Adoption falls under Inclusivity, and could be stated in our Mission statement.

One principle that was discussed later in the day and relates to sustainability, but didn’t make the list (but perhaps it should) was ‘Resourcefulness’.

As an organization grows, and has ready access to capital, fighting bureaucracy/inefficiency should be an explicit goal as the scrappiness of a small startup tends to dissipate. Moreover, it’s an obligation we have to token holders.

e.g. Resourcefulness - Doing more with less. By optimizing what we have to work with, we aim to solve problems in the most effective way possible at lower economic costs (capital, time and resources)

Some examples where this principle could shape our decisions:

  • Determining future headcount planning for core contributors
  • Community involvement vs. paying an agency for certain tasks
  • Encouraging core contributors to engage in community building efforts, recruiting, and helping out with blog posts, even if it falls outside what was described on our ‘open positions’ page.

Note Amazon has a good example of something similar and is reflected in many of their decisions: Amazon 9th Principle: Frugality | Jesús Gil Henández

5 Likes
16

My two cents,

  1. Liberty

We believe in the right of individuals to have autonomy and responsibility over his or her own life. We aim to maximize social, political and economic freedoms. Status is an agnostic platform.

The system built on democracy principals will face issues similar to all democracy based processes. To protect liberty of individuals some rules should be developed and built-in. I would adjust above phrase in one of following ways:

We aim to maximize and protect social, political and economic freedoms.

OR

We aim to maximize social, political and economic freedoms of every individual.

I like second variant more, but in process it seems it will be required “to protect” exactly freedoms of individuals. Under “protection” I mean implementation of missed technical features.

3 Likes
17

I was wondering if we should have - Freedom of speech - as a separate principle or if with the current ones you believe its already represented ?

18

Here’s the latest version the Principles document: My first HackMD note (playground) - HackMD

1 Like
19

It’s been going around a few rounds of edit now. Here is the current version that is open for review: https://github.com/status-im/ideas/pull/290

Rough steps:

  • Soft signaling step by upvoting/downvoting/sidevoting
  • Cryptographic signature of a specific version to consensus (specifics TBD)
  • Once consensus is reached, push out as comms and ensure we uphold these principles

Please note that this is something all core contributors will be asked to do. The more signals we can get early (especially disagreeing voices), the better.

1 Like
20

What’s the deal with everyone-signs?

IE, these started out as principles, or guidelines for directing contribution to status, but I don’t remember and haven’t seen there being any discussion about whether they should be (cryptographically) signed or not by contributors.

Signing seems to imply a number of things, but most importantly it changes the bar of being a contributor from “I’m not against the principles” to “I endorse the principles” - each of them. Once could argue it violates privacy and inclusivity at least, akin to how a CLA places unwelcome onus on a contributor.

I’d like to hear more where this is coming from, and what the rationale is (this point stands regardless of what you think of the principles themselves).

1 Like
21

What’s the deal with everyone-signs?

These are our principles and values that we collectively stand behind. This means it should come from all of us, and not just from a select few. That’s what gives them weight and importance. We (cryptographically) sign these to signal this type of commitment and shared agreement, a consensus.

If we can’t reach consensus then we have a problem. Either we just need to work harder to come up with a subset we all can come to consensus about, or we have fundamentally different values and principles. If the latter, what do we do? This isn’t clear, but perhaps that’s an incompatibility where it would make sense to fork (a la BTC/BCH etc). I really don’t think that’s the case or that it’ll come to that, but it’s hypothetically in the realm of possibilities. And that’s OK.

This is why the consensus-seeking process we are going through now and why “disagree early” is so important.

This is why we have this consensus-seeking process. If core contributors don’t feel like they sign the principles as is and work to uphold them, they should raise these concerns in the Github pull request for review. Now is the right time to do it.

The point is that it isn’t just a form of marketing speech, something we push out to the masses but really we don’t all believe in. These are principles every core contributor stands behind when it comes to working at Status the project. The weight of this is intentional - as Eric said (paraphrasing) “now that I have to sign it cryptographically I will read it much more carefully and comment” - and this is exactly the type of engagement and healthy disagreement we we want.

argue it violates privacy

Disagree, at least pseudo-anonymity:

(a) A core contributor can choose to be anonymous and the signing is only linked to that nick/identity
(b) You can use any key when signing and communicate out-of-band that “Core contributor Foo has possession of this key”.

akin to how a CLA [Contributor License Agreement] places unwelcome onus on a contributor.

This is a fair point. I don’t think any individual contributor to a Status project should necessarily have to agree with every principle to the letter. However, core contributors (essentially on retainer for Status, which is sponsored by token holders / the community) should have a much higher bar, and this bar should reflect the core of what we, collectively, think Status is about.

Also see https://github.com/status-im/ideas/pull/290#issuecomment-410005127

3 Likes