Goal
One of Status’s core principles is to be decentralized. At the moment Status has centralized areas of infrastructure which makes it vulnerable to Ddos attacks as well as been opposed to Status’s principle of decentralization.
This problem affects these items on the wall of shame:
The Status Cluster is centralized: Cluster Single Point of Failure · Issue #5592 · status-im/status-mobile · GitHub
The Status Cluster can be easily spammed, taking down the service: Cluster DDoS protection · Issue #5589 · status-im/status-mobile · GitHub
Status is vulnerable to a Ddos attack through whisper packages: Whisper spamming protection · Issue #5590 · status-im/status-mobile · GitHub
As well as these OKR’s
P0 Improve decentralization
P2 50 users running Status nodes
The goal is to have a decentralized infrastructure which can provide messaging/communication services for Status users without being susceptible to attacks which may render the service unusable. This is a large goal with many moving parts. The objective of this post is to gather feedback on the first steps to gettings on where we need to be.
How Status currently works (High level)
Currently, when a user sends a message on Status it will use the Status cluster. This cluster consists of nodes which run Whisper and mail server software. The reason for these specific “Status” nodes is that:
Whisper nodes require proof of work, however, this is not feasible for mobile devices as it drains the battery so Status nodes running whisper do not require messages to perform proof of work, leaving them vulnerable to Ddos attacks/spam.
In order for users to see messages which were sent when they were offline they need to connect to a mail server, essentially a computer which records all messages sent on whisper network and replays those messages when requested by a client. Without it, users would only be able to see chat messages which were sent when they were online.
Important to note that the Status foundation currently pays for the hosting and running of this cluster. If it goes down then users will have an unacceptable user experience (losing contacts, having to be online to receive messages, unreliable message sending)
Challenges
Whisper node level
When a user, via the status client connects to a whisper node, they need to know that the nodes provide a good service, otherwise poor service could compromise the user experience. Currently, when a user connects to a node for the first time there is no way to know the quality of the node.
The challenge is to design a reputation system which cannot be gamed so that user may send messages via nodes which provide a good service. Please find Dmitry Shulyak’s work on the topic of creating a reputation system for whisper nodes here. [WIP] Whisper reputation system and incentivization 0.0.2 - HackMD
This work will help assure that the user experience of using a decentralized network for communications is good.
Mailserver level
Mail servers, software run on whisper nodes which stores a users contacts and chats so that they may be accessed when the user comes online. These mail servers also need to provide a good service and should be decentralized and attack resistant. They can be hosted on Status nodes or on Whispers nodes.
Adam Babik’s ideas can be found here: Incentivization, Spam Protection and Validation in Whisper - HackMD a proof of concept is proposed to encourage users to register nodes by staking SNT. The staked SNT acts as an incentive for the mail server to provide good service and potentially earn SNT. The SNT earnings for running a mail node will come from a pool of SNT provided by Status.
This PoC will help us learn about just how easy it is to setup a mail server, stake SNT and how much rewards could be earned (and if it surpasses the costs).
Status Node level
Status nodes run whisper and mail server software, are largely run by Status and have a particular configuration. Work has been done to investigate status “Master Nodes”. These will be computers running status nodes but on a cloud provider which should lead to a good service. https://github.com/status-im/ideas/tree/update-168-paid-master/ideas/168-paid-master-nodes
The challenges comes down how to incentivize the running of master nodes without direct payment from States core team.
Next Steps?
Start with the low hanging fruit, these are actions which bring us closer to the goal and are the least complex. Is it these?
-
Using Dapp Node https://dappnode.io/ to decentralize the Status cluster, this should, in theory, open Status cluster open to other providers to host nodes.
-
Create documentation/guide for community members and core contributors to host their own status nodes.
This does not answer questions of spam/attack in the sense that the cluster can still be spammed. It does answer an important usability question, how easy is it to run a status node? Understanding this difficulty will be key to decentralizing network. Love to hear what other measure are simple, well understood and will unlock learnings to achieve the goal of a stable, persistant and decentralzied chat network.