Revolution Mode

Status Mobile
1

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.

6 Likes
2

Link to the original post in Slack, with 95+ replies: Workspace Deleted | Slack

1 Like
3

Look in your WiFi list right now, how much WiFi signals are there?
We could use that as a meshing network, if those routers had a meshing network mode, where geth could connect to and use the whisper protocol.
I am sure not all routers would be compatible, but as this hardware is usually replaced within 5-10 years this might not be a problem if market demand routers supporting this tech.
So in future people would be using commercial internet for most of things, but swarm and whisper would be supported by this tech, allowing messaging and storage sharing through the mesh network, or free internet.

2 Likes
4

I think Status could have a real advantage here. If you’re Facebook and routing all your users’ chats through your websocket servers, an internet shutdown is nearly impossible to deal with. But if you’re using p2p messaging already, discovering and routing messages over wifi or bluetooth or even audio or infrared is “just” a matter of the receiving app listening on those channels.

On a semi-related note. I think there’s a real opportunity for philosophically aligned institutions like libraries, universities, non-profits, and others, to contribute well publicized and highly available boot nodes to the community. That way, there could be hard coded nodes but then also easy to find alternative public access nodes.

2 Likes
5

Exactly, as we don’t need all nodes communicate with a server and communications usually are geographical near, for cases of blockall policy censorship in ISP this could be a last resort of communication that is technically impossible to censorship.

1 Like