Peer-to-Peer Messaging – Where Whisper Falls Short and Waku Picks Up
Status v1.2 is a significant milestone in the development of the private messenger, integrated crypto wallet, and secure web3 browser. It introduces Waku – a fork of the previously used peer-to-peer messaging protocol Whisper. Waku aims to solve some of the issues of Whisper in an iterative fashion and enable greater scalability.
This post will briefly explain some of the key concepts of peer-to-peer messaging, the shortcomings of Whisper, how Waku addresses those issues and the tradeoffs made.
In very simple terms, peer-to-peer messaging removes the need for centralized third party servers to pass messages throughout a network. In traditional client-server networks (in use by most major messaging applications today), messages are sent from person A (Alice) to a central server in the network for processing and then forwarded on to person B (Bob). These servers host and process all messages in the network and become major privacy and security risks as they become single points of failure and centralized attack vectors. Even with advanced forms of end-to-end encryption and other privacy measures, these centralized servers present security and privacy risks..
In the case of peer-to-peer messaging networks, specifically Whisper and now Waku, when Alice wants to send a message to Bob, she broadcasts it to multiple nodes (or other people) in the network, and that message bounces from node to node, ending up with Bob.
This may sound counterintuitive - why would I want many people in a network to have access to my messages? Well only Bob has access, the other nodes simply help to route the messages. All messages are end-to-end encrypted by default so only the intended recipient, Bob, can unlock and view the contents of the message.
This is an extremely high level overview of the standard client-server model vs peer-to-peer messaging intended to illustrate the dangers of the former and how decentralized, peer-to-peer models aim to deliver greater privacy and censorship resistance. There are a number of features including dark routing, time to live, envelopes, topics and more designed for privacy, security, and “plausible deniability” which we go into in more detail in this article.
In short, peer-to-peer messaging aims to deliver:
- 1Removal of centralized rent seeking intermediaries
- 2Decentralization of the network and removal of single points of failure
- 3Censorship resistance
Whisper is the original messaging protocol of the Ethereum tech stack. When Status first kicked off development back in 2017, it was being built on the premise that development of the protocol would continue.
However, with much of the Ethereum ecosystem's efforts and resources focused on Eth1.X and Eth2.0, Status willingly picked up the messaging mantle and began work on our own implementation of Whisper.
Whisper, being a somewhat esoteric protocol with some fundamental issues, hasn’t seen a lot of use. The Status team had been making minor ad hoc modifications to ensure Whisper runs on mobile devices. Still, fundamental issues exist:
Scalability - Whisper doesn't scale very well, specifically when it comes to bandwidth usage on mobile devices. We found that as the network reaches ~1k daily active users, most cases show bandwidth usage ~100MB per day and that number increases rapidly the more users are in the network. Meaning individual users will use lots of data and the battery will drain pretty quickly. The more nodes that are in the network means more messages are being sent to each node. Ultimately resulting in more messages being routed through your phone – whether intended for you or not.
Whisper nodes leverage bloom filters which let the node’s peers know what kind of information the node is interested in. This means that your node will listen for and receive a bunch messages of a certain topic including some that are not meant for it. Nodes will even duplicate messages and forward them to flood the network to obfuscate the message path.
Spam-resistance - Proof of work requires too much battery and compute power for most mobile phones making it a poor mechanism for heterogeneous nodes. What makes proof of work spam resistant is extra power. Mobile devices simply don’t have the resources to keep up efficiently. In Status, the PoW requirement was set very low meaning anyone could boot up a server and calculate the PoW quickly, thus spamming the whole network, even still, PoW creates significant additional work for mobile devices.
No incentivized infrastructure - There is no incentive to run a Whisper node. This forced Status to set up a cluster that includes a number of nodes provided by Infura, mail servers, and other third party infrastructure. These services result in centralized choke points in the network.
Lack of formal and unambiguous specification - Whisper was originally designed as the communication layer of Ethereum enabling Dapps to communicate with each other. As mentioned above, the Ethereum ecosystem decided to shift focus on Eth1.X and Eth2.0 leaving Whisper and its original documentation behind. While a few teams created ad hoc implementations, the formal specification was not maintained, rendering it very difficult to analyze and implement.
Running over devp2p - This limits where Whisper can run and how. For example, it cannot run over websockets in browsers. It also has a certain fingerprint which may make it easier to censor traffic. We will discuss how Waku runs over libp2p and the benefits associated below.
In order to make Status more scalable, the Vac team forked Whisper and created Waku. The latest release of Status, v1.2, introduces the initial version of Waku and improves scalability of the network by 10x. However, this is still an iterative approach to producing a truly private, censorship resistant, peer-to-peer messaging protocol.
Here are some of the solutions put in place to address the concerns discussed above:
Scalability - Whisper nodes leverage bloom filters (as noted above) but Waku nodes do not. While bloom filters enable greater privacy via plausible deniability, Waku is based on topic interest as it is optimized for better usability. In short, topics are short strings - hashes to be precise - which are set by the sender (or at the application layer) and help categorize messages. So instead of receiving tons of messages in the network, Waku nodes will only receive messages of a certain topic they subscribe to. This drastically reduces the amount of messages received and therefore reduces bandwidth consumption.
While this does reduce bandwidth consumption rendering Status more scalable, the removal of bloom filters does in fact make a privacy tradeoff for end users.
Spam Resistance - Waku implements rate limiting. Rate limiting allows a node to control the rate of requests it receives. If it receives a lot of messages on a specific topic from a specific IP, the node can reduce the amount of requests allowed. Nodes can optionally block other nodes as well. This does come with tradeoffs i.e., a peer can skip messages so they do not violate other peer rate limits
It is important to note that this is reference to network level spam, not user level spam which is directly visible in the chat interface. User level spam is a moderation issue.
No incentivized infrastructure - this is currently in R&D by Vac and partner projects.
Lack of formal and unambiguous specification - Waku includes much more rigorous specifications which make it easier to have multiple clients and to determine what is required in terms of interfaces.
Running over libp2p - While Whisper runs over devp2p, Waku runs over libp2p. The most immediate benefit of libp2p is being able to run in a browser. There are also a number of extensions that can be implemented making Waku a much more versatile and usable protocol. Also, Nimbus and the entire Eth2 ecosystem are moving to libp2p rendering Waku a more future thinking option than Whisper.
Peer-to-peer messaging presents the opportunity to truly decentralize communication and return sovereignty and privacy back into the hands of the individual. Like most paradigm shifting technologies, the solutions will come in iterative fashion – building on the achievements and addressing shortcomings of the protocols that come before.
Whisper presented a novel approach to peer-to-peer messaging with some significant issues around scalability. This first iteration of Waku addresses some of those issues, making the network and Status 10x more scalable before bandwidth consumption becomes an issue.
Future iterations of Waku will continue to make the protocol more scalable through DNS based node discovery, and continue to improve privacy for end users. Stay tuned for future updates and more information from Vac - the team behind Waku.
Install Status v1.2 now in the App Store, Playstore, and via APK
