Status is an open source, decentralised messaging platform, non-custodial crypto wallet, and web 3.0 browser, designed to act as a network node which interacts with decentralised applications (DApps) that run on the Ethereum network.
Status is an open source community of people committed to building better decentralised tools for web3, and making sure that everyone across the world can access these tools directly from their pockets.
The Status Network is an ecosystem of decentralised applications – building private, secure communication tools. We stand for upholding human rights, and empowering sovereign communities, therein becoming a gateway to undeniable free trade, peer-to-peer payments, and encrypted p2p communication for anyone with a smartphone and internet access.
Over the last few weeks, I have published Status tech-feature articles for the most important, new pieces of Status core functionality, to coincide with the release of the Status V1 client into the App & Playstore.
In today's article, we're going to explore the first of, as I like to call them, The Big 3 pieces of Status functionality – Messenger. Status Messenger has a strong focus on privacy and security, and utilises some pretty exciting tech to achieve this. We'll dive into the functionality of the messenger, and the underlying protocols used to achieve it, alongside the reasons, and extensive research undertaken for each of the underlying pieces of tech.
This article is definitely going to be longer than my previous feature articles. Our Messenger utilises a bunch of different technologies, and I'll explain them all, as best as I can. For in depth details of the protocols used and the tech - please visit our docs and spec.
So, let's dive on in!
What is the Status Messenger?
As one of the big 3, (as I've started referring to them), features of the Status client; Messenger is an integral part of the application. The long term goal of Status has always been to provide communication tools that remove unnecessary, rent-seeking third parties, and oppressive actors to place sovereignty back into the hands of the individual.
Like other popular messengers available today, Status offers private 1:1 chats and public channels – we will be re-introducing group chats soon.
Private Chats - aiming for complete privacy and censorship resistant chats between peers. Without centralised servers and the standard client/server model, no one can access messages - not even Status. We strive for no metadata leakage (e.g. who’s sending, where)
Public channels - entirely public without restrictions to the number of participants. Public channels are based on whisper topics.
Messenger -> Wallet Integration
One of my personal favourite pieces of functionality; is Messenger being seamlessly integrated with the Wallet to enable you to send borderless crypto payments to other peers.
Using chat commands, you can access your wallet from a private 1:1 message, select one of your cryptocurrencies, and sign a transaction to send some to your friend.
Users can also purchase Stickers from the decentralised sticker market using SNT. Stickers are then available for use in all types of chat.
As I mentioned in my last article (multi-account), your chat keys and wallets keys are not connected. If I know your chat key, I do not know anything about your wallet, or your funds, unless you explicitly share that address with me as well.
How is Status different to WhatsApp or Signal?
Well, mainly, Status is built to uphold the highest level of security possible and remove central points of failure. Take a look at the table below to see which privacy and security features Status has to offer, that the alternatives are lacking:
How do I know my Data is secure?
All 1:1 messaging in Status is subject to end-to-end encryption by default to provide users with a strong degree of privacy and security. Public chat messages are publicly readable by anyone since there’s no permission model for who is participating in a public chat.
End-to-end encryption (E2EE) takes place between two clients. The main cryptographic protocol is a Status implementation of the Double Ratchet protocol, which is in turn derived from the Off-the-Record protocol, using a different ratchet.
The message payload is subsequently encrypted by the transport protocol using symmetric key encryption. Furthermore, Status uses the concept of prekeys (through the use of X3DH) to allow the protocol to operate in an asynchronous environment. It is not necessary for two parties to be online at the same time to initiate an encrypted conversation.
Under the Bonnet
P2P Chat Protocol
Status uses Whisper to provide privacy-preserving routing and messaging on top of devP2P. Whisper uses topics to partition its messages, and these are leveraged for all chat capabilities. In the case of public chats, the channel name maps directly to its Whisper topic. This allows allows anyone to listen on a single channel.
Additionally, since anyone can receive Whisper envelopes, it relies on the ability to decrypt messages to decide who is the correct recipient. We do however not rely on this property, but instead implement another secure transport layer on top of Whisper.
Finally, we use an extension of Whisper to provide the ability to do offline messaging.
Message Storage
Being mostly offline is an intrinsic property of mobile clients. They need to save network transfer and battery consumption to avoid spending too much money or constant charging. Whisper protocol, on the other hand, is an online protocol. Messages are available in the Whisper network only for a short period of time; calculated in seconds.
Before I get into explaining how Status stores messages, there are a couple of important terms I want to clear up:
Peer - A device connected to the Status chat network. Each user can represent one or more peers, depending on their number of devices.
And..
Mailserver - A node in the Status network that routes and stores messages, for up to 30 days.
Whisper Mailserver is a Whisper extension that allows to store messages permanently and deliver them to the clients even though they are already not available in the network and expired.
From the network perspective, Mailserver is just like any other Whisper node. The only difference is that it has the capability of archiving messages and delivering them to its peers on-demand.
In order to receive historic messages from a Mailserver, a node must trust the selected mailserver, to receive packets with the P2P Message code. By default, such packets are discarded.
Message Security
Dark routing means that in the standard mode of operation, messages cannot be tracked or inspected and do not leak any metadata. Every message is broadcast to every peer in the network, making patterns between them impossible to understand.
Whisper leverages the following features to strive for true darkness and the prevention of metadata leakage:
- Peer-to-peer: leverages Ethereum’s ÐΞVp2p wire protocol to gossip messages around the network.
- Multicast broadcasting: When sending a message to a specific person, a user actually broadcasts that message to the entire network. Because it is encrypted with the intended recipient’s public key, only the designated recipient can view the message.
- Proof-of-work: Currently, Status sets a lower PoW value for Whisper messages than other clients default to, as higher PoW uses too much battery and compute power for most mobile phones. This is an active area of our research.
- Time-to-live: A message will bounce from node to node in the network even after it reaches its intended recipient until it’s time to live has expired - this provides plausible deniability that the message was intended for a specific recipient.
- Envelopes: As the name suggests, contain all the parts of a message. They can be compared to physical letters - all the nodes, regardless if they are the recipient or not, need to be able to handle the envelope, but only the recipient node knows how to “unseal” the actual message text. They are a packet format that encapsulates message text, along with metadata like time-to-live, and the message itself. Envelopes themselves are not encrypted, as they are part of the protocol and need to be readable by the nodes.
- Topics: Topics are short strings - hashes to be precise - which are set by the sender (or at the application layer) and help categorise messages. In more technical language: topics are cryptographically secure, probabilistic, partial-classifications of the message.
A message will bounce from node to node in the network even after it reaches its intended recipient until it’s time to live has expired - this provides plausible deniability that the message was intended for a specific recipient. For more in depth breakdown of whisper please visit the spec.
Message Sync
For synchronising messages; MVDS is used for 1:1 and group chats, however it is currently not* in use for public chats. Status payloads are serialised and then wrapped inside a MVDS message which is added to an MVDS payload, this payload is then encrypted (if necessary for 1-to-1 / group-chats) and sent using whisper which also encrypts it.
* Why is MVDS not used for public chats?
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 optimised 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. The bandwidth issue is further exacerbated by Whisper being very bandwidth heavy.
Moving from Whisper to Waku
Whisper is not without its limitations and challenges. Status is one of the few instance of Whisper being used in a real production environment, so we’ve made some ad hoc modifications to support our use case.
What are these fundamental issues? In short:
- Whisper is not scalable, most pressingly when it comes to bandwidth usage—there are not enough active Whisper nodes to support great volume of use.
- It has low spam resistance: proof-of-work is a poor mechanism for Whisper’s heterogeneous nodes.
- Lack of incentivised infrastructure leads to reliance on Status’ own nodes as centralised choke points.
- Lack of formal, clearcut specification makes it hard to analyse and implement.
- Whisper runs over over devp2p, which limits where it can run and how.
In the coming months, Status will supplement the current implementation of Whisper with a fork of a protocol called Waku.
Waku is being developed by the Vac team at Status, which conducts R&D on a modular, peer-to-peer messaging stack for private, secure, censorship resistant communication.
Check out this video of two of our extremely talented engineers; Dean Eigenman & Oskar Thoren, talking about the move from Whisper to Waku:
Learn more about Vac and Waku here.
Frequently Asked Questions
Are my messages on the blockchain?
In a word; no.. Your messages are not on the blockchain. Messages are stored on a mailserver for two weeks, and on your phone once you receive them by opening Status and connecting to the network. To reach you, messages pass over devp2p — the transport layer for Whisper — but are not transported through the Ethereum Virtual Machine. In other words, they are not stored on the blockchain, and they don’t cost anything to send
Refer to my section above on Message Storage to find out exactly where your messages are stored.
Is messenger completely decentralised?
Once again – in a word; no.. We need to store your message history somewhere, and since that's not on the blockchain, we must leverage mailservers and bootnodes.
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.
What about other RLPx subprotocols like LES, and Swarm?
Status is primarily optimised 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. For better Swarm support, see Swarm adaptive nodes.
For transaction support, Status clients currently have to rely on Infura.
Status clients currently do not offer native support for file storage.
Why do you use Whisper?
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 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 heterogeneous 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 and other teams in the space.
Why is PoW for Whisper set so low?
A higher PoW would be desirable, but this kills the battery on mobile phones, which are prime targets for the Status clients.
This means the network is currently vulnerable to DDoS attacks. Alternative methods of spam protection are currently being researched.
Why do you not use Discovery v5 for node discovery?
At the time we implemented 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 of time until their peer list is populated.
For some further investigation, see here.
I heard something about mailservers being trusted somehow?
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 mail server 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.
Conclusion
Well, that's it! ~2300 words later, I hope I've explained all you need to know about Messenger, and its privacy and security functionality. If you feel my explanations to be lacking, and you still have questions:
Feel free to email us at support@status.im or better yet, join our chat.
Want to learn more about the tech used? Looking for a specific answer? Ask your question in our open forum discuss.status.im.
Not finding what you need? Get support in the #support channel in Discord.
Otherwise, if you would like to reach out to me personally, you can do so here!
