specs/x4.md

---
sip: x4
title: Initial Status Protocol Overview
status: Draft
type: Standard
author: Adam Babik <adam@status.im>, Oskar Thorén <oskar@status.im>
created: 2019-04-18
updated:
---

# Abstract

Ethereum empowers users and developers to interact with totally new kind of applications called Dapps (Decentralized applications). These application allows to interact with the blockchain on a completely new level which is not only about exchanging values but also executing arbitrary logic. This logic can form very sophisticated programs like DAOs (Decentralized autonomous organizations). The missing part here is how users of Dapps can communicate securely and in a decentralized way with each other. Communication is an essential part of any activity. In this document, we specify a secure and decentralized messaging protocol, onwards called Status Protocol, that is capable of running on the Ethereum network.

# Protocol overview

TODO:
* why p2p?
* why on Ethereum stack?
* designed for mobile from the beginning

# Guiding principles

**TODO: This needs some tweaking, as it was taken from https://github.com/status-im/swarms/blob/master/ideas/311-status-protocol.md which also includes how to work, as opposed to how the prinicples apply technically**

One way of looking at our protocol stack is as a reflection of our principles. While this isn't always true in practice right now, this is what we are aiming for, and also what we want to see in future specification proposals.

The protocol should be a reflection of our principles.

    I. Liberty - enable sovereignty of individuals with things like key management, as well as economic freedom, etc, by enabling transaction of funds and socio-economic coordination between small groups of people. This also includes being coercion resistant, and not forcing updates on people.

    II. Censorship resistance - enable censorship resistance through things like pluggable transports, as well as being agnostic to the information being transported.

    III. Security - use state-of-the-art technologies, and research new security methods and technologies to make strong security guarantees.

    IV. Privacy - protect privacy in communication and transactions, and strive to provide right to total anonymity.

    V. Transparency - be open about what we are doing, allow community contributions and be clear about trade-offs.

    VI. Openness - specification is open and under a permissive license.

    VII. Decentralization - p2p network, maximizing number of computers/humans who can control and use the protocol we are building.

    VIII. Inclusivity - easy to use our protocols, as well as working towards interopability with other protocols, and educating users.

    IX. Continuance - network should be incentivized to continue on its own.

    X. Resourcefulness - work with other teams to avoid duplication of effort, study prior work deeply to minimize wasted and duplicate effort.

In the following sections we will elaborate more on these.

# Protocol Layers

The Status Protocol stack consists of multiple protocols at multiple levels. In this document, we give a brief overview of each layer and what they provide. We also note any specific considerations when it comes to using these components together.

| Layer             | Purpose                         | Technology                   |
|-------------------|---------------------------------|------------------------------|
| Data              | End user functionality          | 1:1, group chat, public chat |
| Security          | Confidentiality, PFS            | Double Ratchet               |
| Privacy           | Metadata protection             | Whisper                      |
| P2P               | Overlay routing, NAT traversal  | devp2p                       |

Note that the Status Protocol was documented after the fact, which might lead to some inconsistencies or questionable design choices.

# Data layer

Data layer specifies a format of payloads exchanged between clients communicating using the Status Protocol. The robust and well-defined format is required in order to provide some security guarantees, for example, client should not display messages that do not conform to the format, and allow the clients to upgrade the protocol safely in the future.

The well-defined format also makes it possible to support multiple types of conversations as well as multiple types of content.

Please refer to [Initial Message Payload Specification](x8.md) for more details.

# Security layer

Security layer provides various cryptographical properties to the Status Protocol:
* encryption
* assurance of the origin
* forward secrecy

Encryption makes sure that only author and the recipient can read the content of the message.

Assurance of the origin using a digital signature ensures that the message was actually sent by the owner of a given public key and the message has not been changed induring the transport over the wire.

Note: exchange and verification of the public keys is not a trivial problem. Read more about this problem in [Initial Trust Establishment Specification](x5.md).

Note: The Status Procol can work with PFS enabled and disabled. In the case of disabled PFS, the encryption is moved to the Privacy Layer and handled by Whisper. Whisper does **not** provide forward secrecy. This is a flaw of the original design which mixes security and private layer responsibilities.

Please refer to [Initial Conversational Security Specification](x6.md) for more details.

# Privacy layer

The purpose of the privacy layer is to hide metadata (provide darkness) that are always sent when communicating over the internet. In some cases, leaked metadata might be as dangerous as leaking the actual payload so it's important to reduce that.

The Status Protocol uses [Whisper in version 6](https://github.com/ethereum/wiki/wiki/Whisper) as a privacy protection protocol. Whisper routes messages by broadcasting them to all connected peers so that identifying of the recipient is almost impossible (the sender is not equally protected, though). [Read more](https://github.com/ethereum/go-ethereum/wiki/Achieving-Darkness) about how Whisper achieves darkness.

Note: there is one more cross-layer dependency in the Status Protocol between the privacy and data layers. Whisper uses topics to reduce traffic and preliminarily filter out messages. However, selecting a topic depends on the type of the message that is a topic for 1-1 chat will be different from a topic for a public chat.

Please refer to [Initial Transport Privacy through Whisper Specification](x7.md) for more details.

# P2P layer

P2P layer allows various clients to securely communicate with each other through the internet in a decetralized fashion, envetually forming a peer-to-peer network. Due to our close relationship to Ethereum and the fact that Whisper is built on top of [devp2p](https://github.com/ethereum/devp2p), we selected [devp2p](https://github.com/ethereum/devp2p) as a P2P layer.

A client in order to rely a message needs to first find other clients within the peer-to-peer network (this is called node discovery). Then, the message needs to be properly routed handling obstacles like NAT traversal. All these things are handled by devp2p.

# Censorship resistance

TODO

# Availability/Robustness

TODO

# Continuance

TODO

# Existing implementations

TODO

# Known issues

## Dependencies between layers

As it was mentioned above, there are cases when two layers dependen on one another:
* encrypting messages is done by the privacy layer instead of security layer
* the privacy layer needs to know some details of the payload to properly route it.

In the next version of the protocol, we will try to remove these dependencies so that all layers are orthogonal and if necessary there is a clean interface between one and another.

# TODO

## Review each section

Each section, if possible, should follow this structure:
- Current protocl
- How we use it
- Future considerations
- Desired by Status
- The ethereum txn viewpoint