waku.guide/docs/overview/concepts/protocols-explained.md

3.3 KiB

title
Protocols Explained

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:

There are also more experimental libp2p protocols such as WAKU-RLN-RELAY

You can find more information on this here.