We are living in an eventful and reactive world. We subscribe to newsletters, and follow people and companies on Twitter, Facebook, or LinkedIn. We buy and sell stocks when the stock prices get to some predefined limits. In a traditional application scenario, an event-driven architecture with a messaging service might be a popular choice for this kind of use case to make the event source and event consumer integrate together asynchronously.

Whisper is a decentralized messaging mechanism designed for asynchronous low bandwidth, uncertain latency communication and data transmission between decentralized applications. It is almost the same in concept as JMS (Java Message Service) in the Java world, or newer ones like Kafka. A message is an atomic unit of work of data passed from the source application to one or more destination applications. It is up to the receiving party to look into the messages and take action.

Messages can be handled in both the request/reply model or publish/subscribe model. In the request/reply model, DApp A needs to send a message to DApp B in one message channel, and expects the response back from B in another message channel. In the publish/subscribe case, a group of DApps can subscribe messages with a certain topic, and will be able to receive such messages whenever the source system publishes a message about the topic.

When DApp A needs to send a message to B, it will send the messages to the decentralized network. Here, the Whisper nodes will relay the messages to all Whisper nodes, and the targeted receiver or the subscriber, DApp B, will be able to pick up the messages from any of the nodes.

The following list further explains the process:

  • Behind the scene, Whisper maintains the messages similar to a distributed hash table (DHT), and uses a datagram messaging protocol, like UDP, for relaying messages between the Whisper nodes.
  • A message in Ethereum is a data packet with of to 64KB in size, normally about 256 bytes. It is neither suitable for large data exchanges, nor for real-time communication.
  • Typical usages of messages include low-latency signaling messages from one DApp to one or more receiving DApps, or high-latency publication messages.
  • Whisper provides low-level APIs for DApps to send or watch the messages. During the transmission of a message, it is packaged within an envelope, which is encoded with the recursive length prefix (RLP) encoding schema, something along the lines of:

[expiry: P, ttl: P, [topic0: B_4, topic1: B_4, ...], data: B, nonce: P]

The envelope structure is as follows: expiry is the field as the intended expiry date/time for the message, ttl is the time to live given in seconds, which means the message should no longer be transmitted once it is past the time to live time.

The nonce here is conceptually similar to the nonce in the PoW; it is an arbitrary value intended to demonstrate proof of work in composing the message. Topics are a set of indexes intended to help the message recipients watch and find the expected messages.

Whisper provides low-level APIs in web3.shh for DApps to send or watch the messages.

Messages can be sent as anonymous or public messages, can be signed or not signed, can be encrypted or sent as plain messages. It can be sent to one or more recipients, or published to anyone. When sent as signed messages, the message sender will sign the messages with the SHA-256 hash to show the authenticity of the owner of the messages. When encrypted, it can be encrypted using symmetric key, or public and private key pairs. Whoever owns the symmetric key or private keys can decrypt the messages.

This article is written in collaboration with Brian Wu.