Waku is the result of work from VAC, the R&D division of Status. It is the evolution of Whisper, the original Ethereum messaging protocol over ÐΞVp2p.
This implementation does not concern Waku v1, and goes directly towards Waku v2.
Waku v2 implements a PubSub service over libp2p, in addition to:
- retrieving historical messages for mostly off-line devices
- adaptive nodes
- bandwidth preserving
As a first iteration, waku-rs
aims to cover the following specs, which are listed as the recommendations for a minimal implementation of a new Waku v2 client:
- 10/WAKU2 - main spec
- 11/WAKU2-RELAY - for basic operation
- 14/WAKU2-MESSAGE - version 0 (unencrypted)
- 13/WAKU2-STORE - for historical messaging (query mode only)
- 19/WAKU2-LIGHTPUSH - for pushing messages
Currently, waku-rs
cares about the current libp2p
protocol identifiers proposed by Waku:
/vac/waku/relay/2.0.0
/vac/waku/store/2.0.0-beta4
/vac/waku/lightpush/2.0.0-beta1
Messages are exchanged over a bi-directional binary stream. Therefore, libp2p
protocols prefix binary message payloads with the length of the message in bytes. The length integer is encoded as a protobuf varint.
Waku proposes three domains for networking activity:
- gossip
- discovery
- request/response
Waku gossips to disseminate messages throughout the network.
The gossip protocol identifier under libp2p
is /vac/waku/relay/2.0.0
, and is specified under 11/WAKU2-RELAY.
The 23/WAKU2-TOPICS provides specifications for the recommended topic usage.
waku-rs
uses DNS-based discovery to retrieve a list of nodes to connect to, defined by EIP-1459.
Waku provides the following Request/Response protocols, which are designed for low bandwidth and being mostly offline.
- 12/WAKU2-FILTER - content filtering: makes fetching of a subset of messages bandwidth preserving -
/vac/waku/filter/2.0.0-beta1
- 19/WAKU2-LIGHTPUSH - light push: used for nodes with short connection windows and limited bandwidth to publish messages -
/vac/waku/lightpush/2.0.0-beta1
As a specification, Waku is transport agonistic.
waku-rs
supports the TCP transport, both dialing and listening.
waku-rs
supports secure websockets for bidirectional communication streams.
The diagram below displays an overview of how different protocol interact under Waku:
Say we have 6 nodes: A-F. The pubtopic
and pubtopic2
PubSub Topics indicate which topic each node is interested in under the relay routing scheme.
- Node A creates
msg1
withcontentTopic1
as Content Topic. - Node F requests to get messages filtered by
pubtopic1
andcontentTopic1
. - Node D starts forwarding messages that match
pubtopic1
and `contentTopic1 to F. - Node A publishes
msg1
onpubtopic1
. The message gets relayed further from B to D, but not C. - Node D saves
msg1
for possible later retrieval by other nodes. - Node D pushes
msg1
to F, since it has previously subscribed F to this filter. - At a later time, E comes online. Then, it requests messages matching
pubtopic1
andcontentTopic1
from Node D. Node D with messages meeting this criteria.