3.5 KiB
| title |
|---|
| Waku Protocols |
Waku is modular: several protocols are available and applications can decide on how they want to turn the dials on the Anonymity Trilemma. Here are the different types of protocols Waku offers:
Currently, the main Waku protocols are:
Waku Relay
WAKU2-RELAY specifies a Publish/Subscribe approach to peer-to-peer messaging with a strong focus on privacy, censorship-resistance, security and scalability.
Its current implementation is a minor extension of the libp2p GossipSub protocol and prescribes gossip-based dissemination.
An extension of this is WAKU-RLN-RELAY, a privacy-preserving economic spam protection mechanism.
Waku Filter
WAKU2-FILTER is a protocol that enables subscribing to messages that a peer receives.
It enables a node to access the relay network without the connectivity and bandwidth requirements of relay nodes, but it comes with privacy drawbacks.
Light nodes subscribe to service nodes and only receive the messages they desire.
It makes receiving messages more bandwidth preserving.
Waku Store
DApps running on a phone or in a browser are often offline: The browser could be closed or mobile app in the background.
Waku Relay is a gossip protocol. As a user, it means that your peers forward you messages they just received. If you cannot be reached by your peers, then messages are not relayed; relay peers do not save messages for later.
However, Waku Store peers do save messages they relay, allowing you to retrieve them at a later time. The Waku Store protocol is best-effort and does not guarantee data availability. Waku Relay or Waku Filter should still be preferred when online; Waku Store can be used after resuming connectivity: For example, when the dApp starts.
Waku Light Push
Waku Light Push enables a client to receive a confirmation when sending a message.
The Waku Relay protocol sends messages to connected peers but does not provide any information on whether said peers have received messages. This can be an issue when facing potential connectivity issues. For example, when the connection drops easily, or it is connected to a small number of relay peers.
Waku Light Push allows a client to get a response from a remote peer when sending a message. Note this only guarantees that the remote peer has received the message, it cannot guarantee propagation to the network.
It also means weaker privacy properties as the remote peer knows the client is the originator of the message. Whereas with Waku Relay, a remote peer would not know whether the client created or forwarded the message.
You can find Waku Light Push's specifications on Vac RFC.
WAKU2-LIGHTPUSH is a request/response protocol for this.
Additional Protocols
This is in addition to protocols that specify messages, payloads, and recommended usages. For example:
- 14/WAKU2-MESSAGE and 26/WAKU2-PAYLOAD for message payloads
- 23/WAKU2-TOPICS and 27/WAKU2-PEERS for recommendations around usage
There are also more experimental libp2p protocols such as
WAKU-RLN-RELAY
You can find more information on this here.