2019-08-26 14:16:32 +00:00
|
|
|
# Status Client Specification
|
|
|
|
|
|
|
|
> Version: 0.1 (Draft)
|
|
|
|
>
|
|
|
|
> Authors: Oskar Thorén <oskar@status.im>, Dean Eigenmann <dean@status.im>
|
|
|
|
|
|
|
|
## Table of Contents
|
|
|
|
|
|
|
|
- [Abstract](#abstract)
|
2019-08-26 14:45:27 +00:00
|
|
|
- [P2P Overlay](#p2p-overlay)
|
|
|
|
- [Node discovery and roles](#node-discovery-and-roles)
|
2019-08-26 14:16:32 +00:00
|
|
|
- [Design Rationale](#design-rationale)
|
2019-08-26 14:45:27 +00:00
|
|
|
- [P2P Overlay](#p2p-overlay-1)
|
|
|
|
- [Why devp2p? Why not use libp2p?](#why-devp2p-why-not-use-libp2p)
|
|
|
|
- [What about other RLPx subprotocols like LES, and Swarm?](#what-about-other-rlpx-subprotocols-like-les-and-swarm)
|
|
|
|
- [Why do you use Whisper?](#why-do-you-use-whisper)
|
|
|
|
- [I heard you were moving away from Whisper?](#i-heard-you-were-moving-away-from-whisper)
|
2019-08-26 14:16:32 +00:00
|
|
|
- [Footnotes](#footnotes)
|
|
|
|
- [Acknowledgements](#acknowledgements)
|
|
|
|
|
|
|
|
## Abstract
|
|
|
|
|
|
|
|
In this specification, we describe how to write a Status client for
|
|
|
|
communicating with other Status clients.
|
|
|
|
|
|
|
|
We present a reference implementation of the protocol <sup>1</sup> that is used
|
|
|
|
in a command line client <sup>2</sup> and a mobile app <sup>3</sup>.
|
|
|
|
|
|
|
|
This document consists of two parts. The first outlines the specifications that
|
|
|
|
have to be implemented in order to be a full Status client.
|
|
|
|
|
2019-08-26 14:28:59 +00:00
|
|
|
## P2P Overlay
|
|
|
|
|
|
|
|
Status clients run on the public Ethereum network, as specified by the devP2P
|
|
|
|
network protocols. devP2P provides a protocol for node discovery which is in
|
|
|
|
draft mode
|
|
|
|
(here)[https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md]. See
|
|
|
|
more on node discovery and management in the next section.
|
|
|
|
|
|
|
|
To communicate between Ethereum nodes, the (RLPx Transport
|
|
|
|
Protocol, v5)[https://github.com/ethereum/devp2p/blob/master/rlpx.md] is used, which
|
|
|
|
allows for TCP-based communication between nodes.
|
|
|
|
|
2019-08-26 14:36:04 +00:00
|
|
|
On top of this we run the RLPx-based subprotocol (Whisper
|
|
|
|
v6)[https://eips.ethereum.org/EIPS/eip-627] for privacy-preserving messaging.
|
|
|
|
|
2019-08-26 14:28:59 +00:00
|
|
|
## Node discovery and roles
|
|
|
|
|
2019-08-26 14:56:24 +00:00
|
|
|
There are four types of node roles:
|
|
|
|
1. Bootstrap nodes
|
|
|
|
2. Whisper relayers
|
|
|
|
3. Mailservers (servers and clients)
|
|
|
|
4. Mobile nodes (Status Clients)
|
|
|
|
|
|
|
|
To implement a standard Status client you MUST implement the last node type. The
|
|
|
|
other node types are optional, but we RECOMMEND you implement a mailserver
|
|
|
|
client mode, otherwise the user experience is likely to be poor.
|
|
|
|
|
|
|
|
### Bootstrapping
|
|
|
|
|
|
|
|
To connect to other Status nodes you need to connect to a bootstrap node. These
|
|
|
|
nodes allow you to discover other nodes of the network.
|
|
|
|
|
|
|
|
Currently the main bootstrap nodes are provided by Status Gmbh, but anyone can
|
|
|
|
run these provided they are connected to the rest of the Whisper network.
|
|
|
|
|
|
|
|
<!-- TODO: Add a link to bootstrap nodes -->
|
|
|
|
|
|
|
|
### Discovery
|
|
|
|
|
|
|
|
<!-- TODO: Add a link to Discovery v5 / Rendezvous spec -->
|
|
|
|
|
|
|
|
### Mailservers
|
|
|
|
|
|
|
|
Whisper Mailservers are special nodes that helps with offline inboxing. This
|
|
|
|
means you can receive Whisper envelopes after they have expired, which is useful
|
|
|
|
if they are sent while a node is offline. They operate on a store-and-forward
|
|
|
|
model.
|
|
|
|
|
|
|
|
<!-- TODO: Add a link to mailserver spec spec -->
|
|
|
|
|
|
|
|
### Mobile nodes
|
|
|
|
|
|
|
|
This is a Whisper node which connects to part of the Whisper network. It MAY
|
|
|
|
relay messages, and it MUST set a PoW requirement of at least `0.01` to be
|
|
|
|
accepted by other Status nodes.
|
2019-08-26 14:28:59 +00:00
|
|
|
|
2019-08-26 14:16:32 +00:00
|
|
|
## Design Rationale
|
|
|
|
|
2019-08-26 14:29:06 +00:00
|
|
|
### P2P Overlay
|
|
|
|
|
|
|
|
#### Why devp2p? Why not use libp2p?
|
|
|
|
|
|
|
|
At the time the main Status clients were being developed, devp2p was the most
|
|
|
|
mature. However, it is likely we'll move over to libp2p in the future, 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](https://github.com/status-im/murmur).
|
|
|
|
|
2019-08-26 14:32:46 +00:00
|
|
|
#### What about other RLPx subprotocols like LES, and Swarm?
|
|
|
|
|
|
|
|
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 better Ethereum light client support, see (Re-enable LES as
|
|
|
|
option)[https://github.com/status-im/status-go/issues/1025]. For better Swarm
|
|
|
|
support, see (Swarm adaptive
|
|
|
|
nodes)[https://github.com/ethersphere/SWIPs/pull/12].
|
|
|
|
|
|
|
|
For transaction support, Status clients currently have to rely on Infura.
|
|
|
|
|
|
|
|
Status clients currently do not offer native support for file storage.
|
|
|
|
|
2019-08-26 14:43:37 +00:00
|
|
|
#### Why do you use Whisper?
|
|
|
|
|
|
|
|
Whisper is one of the (three parts)[http://gavwood.com/dappsweb3.html] 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.
|
|
|
|
|
|
|
|
#### I heard you were moving away from Whisper?
|
|
|
|
|
|
|
|
Whisper is not currently under active development, and it has several drawbacks.
|
|
|
|
Among others:
|
|
|
|
|
|
|
|
- It is very wasteful bandwidth-wise and it doesn't appear to be scalable
|
|
|
|
- Proof of work is a poor spam protection mechanism for heterogenerous devices
|
|
|
|
- The privacy guarantees provided are not rigorous
|
|
|
|
- There's no incentives to run a node
|
|
|
|
|
|
|
|
Finding a more suitable transport privacy is an ongoing research effort,
|
|
|
|
together with (Vac)[https://vac.dev/vac-overview] and other teams in the space.
|
|
|
|
|
2019-08-26 14:16:32 +00:00
|
|
|
## Footnotes
|
|
|
|
|
|
|
|
1. <https://github.com/status-im/status-protocol-go/>
|
|
|
|
1. <https://github.com/status-im/status-console-client/>
|
|
|
|
1. <https://github.com/status-im/status-react/>
|
|
|
|
|
|
|
|
## Acknowledgements
|