Authors: Adam Babik [email protected], Andrea Maria Piana [email protected], Dean Eigenmann [email protected], Corey Petty [email protected], Oskar Thorén [email protected], Samuel Hawksby-Robinson [email protected] (alphabetical order)
This specification describes how to write a Status client for communicating with other Status clients.
This specification presents a reference implementation of the protocol 1 that is used in a command line client 2 and a mobile app 3.
This document consists of two parts. The first outlines the specifications that have to be implemented in order to be a full Status client. The second gives a design rationale and answers some common questions.
- Table of Contents
- Security Considerations
- Design Rationale
- P2P Overlay
- Data sync
- Appendix A: Security considerations
Implementing a Status clients largely means implementing the following layers. Additionally, there are separate specifications for things like key management and account lifecycle.
Other aspects, such as how a node uses IPFS for stickers or how the browser works, are currently underspecified. These specifications facilitate the implementation of a Status client for basic private communication.
|Data and payloads||End user functionality||1:1, group chat, public chat|
|Data sync||Data consistency||MVDS.|
|Secure transport||Confidentiality, PFS, etc||Double Ratchet|
|Transport privacy||Routing, Metadata protection||Waku / Whisper|
|P2P Overlay||Overlay routing, NAT traversal||devp2p|
protobuf is used in different layers, version
proto3 used is unless stated otherwise.
Status clients run on a public, permissionless peer-to-peer network, as specified by the devP2P network protocols. devP2P provides a protocol for node discovery which is in draft mode here. See more on node discovery and management in the next section.
To communicate between Status nodes, the RLPx Transport Protocol, v5 is used, which allows for TCP-based communication between nodes.
There are four types of node roles:
Mailserver(servers and clients)
Mobile node(Status Clients)
A standard Status client MUST implement both
Whisper/Waku relayer and
Mobile node node types. The other node types are optional, but it is RECOMMEND to implement a
Mailserver client mode, otherwise the user experience is likely to be poor.
Bootstrap nodes allow Status nodes to discover and connect to other Status nodes in the network.
Currently, Status Gmbh provides the main bootstrap nodes, but anyone can run these provided they are connected to the rest of the Whisper/Waku network.
Status maintains a list of production fleet bootstrap nodes in the following locations:
These bootstrap nodes MAY change and are not guaranteed to stay this way forever and at some point circumstances might force them to change.
A Status client MUST discover or have a list of peers to connect to. Status uses a light discovery mechanism based on a combination of Discovery v5 and Rendezvous Protocol, (with some modifications). Additionally, some static nodes MAY also be used.
A Status client MUST use at least one discovery method or use static nodes to communicate with other clients.
Discovery V5 uses bootstrap nodes to discover other peers. Bootstrap nodes MUST support Discovery V5 protocol as well in order to provide peers. It is kademlia-based discovery mechanism and it might consume significant (at least on mobile) amount of network traffic to operate.
In order to take advantage from simpler and more mobile-friendly peers discovery mechanism, i.e. Rendezvous protocol, one MUST provide a list of Rendezvous nodes which speak Rendezvous protocol. Rendezvous protocol is request-response discovery mechanism. It uses Ethereum Node Records (ENR) to report discovered peers.
Both peers discovery mechanisms use topics to provide peers with certain capabilities. There is no point in returning peers that do not support a particular protocol. Status nodes that want to be discovered MUST register to Discovery V5 and/or Rendezvous with the
whisper topic. Status nodes that are
Mailservers and want to be discoverable MUST additionally register with the
It is RECOMMENDED to use both mechanisms but at the same time implement a structure called
PeerPool is responsible for maintaining an optimal number of peers. For mobile nodes, there is no significant advantage to have more than 2-3 peers and one
PeerPool can notify peers discovery protocol implementations that they should suspend their execution because the optimal number of peers is found. They should resume if the number of connected peers drops or a
It is worth noticing that an efficient caching strategy MAY be of great use, especially, on mobile devices. Discovered peers can be cached as they rarely change and used when the client starts again. In such a case, there might be no need to even start peers discovery protocols because cached peers will satisfy the optimal number of peers.
Alternatively, a client MAY rely exclusively on a list of static peers. This is the most efficient way because there are no peers discovery algorithm overhead introduced. The disadvantage is that these peers might be gone and without peers discovery mechanism, it won’t be possible to find new ones.
The current list of static peers is published on https://fleets.status.im/.
eth.prod is the current group of peers the official Status client uses. The others are test networks.
Mobile node is a Whisper and/or Waku node which connects to part of the respective Whisper and/or Waku network(s). A
Mobile node MAY relay messages. See next section for more details on how to use Whisper and/or Waku to communicate with other Status nodes.
Once a Whisper and/or Waku node is up and running there are some specific settings required to communicate with other Status nodes.
In order to provide confidentiality, integrity, authentication and forward secrecy of messages the node implements a secure transport on top of Whisper and Waku. This is used in 1:1 chats and group chats, but not for public chats. See 5/SECURE-TRANSPORT for more.
MVDS is used for 1:1 and group chats, however it is currently not in use for public chats. Status payloads are serialized and then wrapped inside an MVDS message which is added to an MVDS payload, the node encrypts this payload (if necessary for 1-to-1 / group-chats) and sends it using Whisper or Waku which also encrypts it.
On top of secure transport, various types of data sync clients and the node uses payload formats for things like 1:1 chat, group chat and public chat. These have various degrees of standardization. Please refer to 6/PAYLOADS for more details.
For a list of EIPs and BIPs that SHOULD be supported by Status client, please see 8/EIPS.
See Appendix A
At the time Status developed the main Status clients, devp2p was the most mature. However, in the future libp2p is likely to be used, as it’ll provide us with multiple transports, better protocol negotiation, NAT traversal, etc.
For very experimental bridge support, see the bridge between libp2p and devp2p in Murmur.
Status is primarily optimized for resource restricted devices, and at present time light client support for these protocols are suboptimal. This is a work in progress.
For transaction support, Status clients currently have to rely on Infura.
Status clients currently do not offer native support for file storage.
Whisper is one of the three parts of the vision of Ethereum as the world computer, Ethereum and Swarm being the other two. Status was started as an encapsulation of and a clear window to this world computer.
Waku is a direct upgrade and replacement for Whisper, the main motivation for developing and implementing Waku can be found in the Waku specs.
Waku was created to incrementally improve in areas that Whisper is lacking in, with special attention to resource restricted devices. We specify the standard for Waku messages in order to ensure forward compatibility of different Waku clients, backwards compatibility with Whisper clients, as well as to allow multiple implementations of Waku and its capabilities. We also modify the language to be more unambiguous, concise and consistent.
Considerable work has gone into the active development of Ethereum, in contrast Whisper is not currently under active development, and it has several drawbacks. Among others:
- Whisper is very wasteful bandwidth-wise and doesn’t appear to be scalable
- Proof of work is a poor spam protection mechanism for heterogeneous devices
- The privacy guarantees provided are not rigorous
- There are no incentives to run a node
Finding a more suitable transport privacy is an ongoing research effort, together with Vac and other teams in the space.
A higher PoW would be desirable, but this kills the battery on mobile phones, which is a prime target for Status clients.
This means the network is currently vulnerable to DDoS attacks. Alternative methods of spam protection are currently being researched.
At the time of implementing dynamic node discovery, Discovery v5 wasn’t completed yet. Additionally, running a DHT on a mobile leads to slow node discovery, bad battery and poor bandwidth usage. Instead, each client can choose to turn on Discovery v5 for a short period until the node populates their peer list.
For some further investigation, see here.
In order to use a
Mailserver, a given node needs to connect to it directly, i.e. add the
Mailserver as its peer and mark it as trusted. This means that the
Mailserver is able to send direct p2p messages to the node instead of broadcasting them. Effectively, it knows the bloom filter of the topics the node is interested in, when it is online as well as many metadata like IP address.
Currently, public chats are broadcast-based, and there’s no direct way of finding out who is receiving messages. Hence there’s no clear group sync state context whereby participants can sync. Additionally, MVDS is currently not optimized for large group contexts, which means bandwidth usage will be a lot higher than reasonable. See P2P Data Sync for Mobile for more. This is an active area of research.
There are several security considerations to take into account when running Status. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used, such as
Mailserver, light node, and so on.
In version 1 of Status, bandwidth usage is likely to be an issue. In Status version 1.1 this is partially addressed with Waku usage, see the theoretical scaling model.
Mailserver High Availability requirement:
Mailserver has to be online to receive messages for other nodes, this puts a high availability requirement on it.
Use of gossip-based routing doesn’t necessarily scale. It means each node can see a message multiple times, and having too many light nodes can cause propagation probability that is too low. See Whisper vs PSS for more and a possible Kademlia based alternative.
Lack of incentives:
Status currently lacks incentives to run nodes, which means node operators are more likely to create centralized choke points.
Light node privacy:
The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends). This means nodes can make assumptions about what messages (topics) their peers are interested in.
Bloom filter privacy:
A user reveals which messages they are interested in, by setting only the topics they are interested in on the bloom filter. This is a fundamental trade-off between bandwidth usage and privacy, though the trade-off space is likely suboptimal in terms of the Anonymity trilemma.
Mailserver client privacy:
Mailserver client has to trust a
Mailserver, which means they can send direct traffic. This reveals what topics / bloom filter a node is interested in, along with its peerID (with IP).
Privacy guarantees not rigorous:
Privacy for Whisper or Waku hasn’t been studied rigorously for various threat models like global passive adversary, local active attacker, etc. This is unlike e.g. Tor and mixnets.
Similar to bloom filter privacy, using a very specific topic reveals more information. See scalability model linked above.
PoW bad for heterogeneous devices:
Proof of work is a poor spam prevention mechanism. A mobile device can only have a very low PoW in order not to use too much CPU / burn up its phone battery. This means someone can spin up a powerful node and overwhelm the network.
Mailserver trusted connection:
Mailserver has a direct TCP connection, which means they are trusted to send traffic. This means a malicious or malfunctioning
Mailserver can overwhelm an individual node.
Devp2p TCP port blockable:
By default Devp2p runs on port
30303, which is not commonly used for any other service. This means it is easy to censor, e.g. airport WiFi. This can be mitigated somewhat by running on e.g. port
443, but there are still outstanding issues. See libp2p and Tor’s Pluggable Transport for how this can be improved.
See https://github.com/status-im/status-react/issues/6351 for some discussion.
Released May 22, 2020
- Added that Waku SHOULD be used
- Added that Whisper SHOULD NOT be used
- Added language to include Waku in all relevant places
- Change to keep