This post is one of the seed posts in order to get the discussion going. The following post was originally written by @divan in Slack June 7th.
One of the topics we brought into discussion in Cardona was introducing so-called Revolution Mode (or, as some suggested, Ludicrous Mode)) – special mode for the cases when users are in the adversarial environment and Status app is an active target for blocking/banning. First, the “modes” concept is familiar to users and easy to grasp (i.e. “incognito mode”). Second, tradeoffs for “normal mode” and “revolution mode” can vary to the great extent, and the mere action of switching mode will help to adjust user’s expectations.
The use case I was presenting is the real situation of being in a crowd and communicating with friends during the revolution in Ukraine we had 4 years ago. Luckily, there was no internet shutdown (govt simply wasn’t prepared for that), but in other countries (Arab Spring, Taksim, etc) it’s practised, and Russian govt, for example, has prepared to shut down the internet in case of future protests in a minute.
This use case is a bit special in the terms of features’ prioritization the users need from chat. And I believe that’s exactly the use case where all other messengers are doomed, and Status can be the only real option.
This mode assumes that underlying network is partially disrupted and attacker is exploiting the weak points of Status design to shut down it. One of the examples is blocking bootnodes, preserving new apps from discovering peers, rendering it unusable. Normally, bootnodes are hardcoded, but we may want to introduce different channels to get updated/user-provided list of bootnodes that aren’t blocked. It may include showing an instruction for technical users how to run and share new bootnode, adding new nodes via QR-codes, aggressively looking into alternative channels of information, leveraging collateral freedom effect (posting on GitHub, push notifications, etc.).
We may want to disable some features (like message history storage), or tune some hardcoded constants to more aggressive values, which are suboptimal in ‘normal case’ or even start experimental and energy-expensive mesh-networks solution.
The end goal of this idea is to make Status a truly “die-hard” survivor under heavily censored conditions. I also see this as a strong selling point – we don’t have a shortage of messengers “that just work”, and don’t want to create just one more Whatsapp competitor. There is a reason why we believe in decentralized approach, and while it can have inherently worse performance limitations, being uncensorable is ultimately will be the huge win.
Would love to hear thoughts on this.