70 lines
3.3 KiB
Markdown
70 lines
3.3 KiB
Markdown
---
|
|
title: Protocols Explained
|
|
---
|
|
|
|
Currently, the main Waku protocols are:
|
|
|
|
### [Waku Relay](https://rfc.vac.dev/spec/11/)
|
|
|
|
`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](https://rfc.vac.dev/spec/12/)
|
|
|
|
`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](https://rfc.vac.dev/spec/13/)
|
|
|
|
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](https://rfc.vac.dev/spec/11/) 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](https://rfc.vac.dev/spec/13/) 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](https://rfc.vac.dev/spec/19/)
|
|
|
|
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](https://rfc.vac.dev/spec/19/).
|
|
|
|
`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](https://rfc.vac.dev/spec/14) and [26/WAKU2-PAYLOAD](https://rfc.vac.dev/spec/26) for message payloads
|
|
- [23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23) and [27/WAKU2-PEERS](https://rfc.vac.dev/spec/27) for recommendations around usage
|
|
|
|
There are also more experimental libp2p protocols such as
|
|
[`WAKU-RLN-RELAY`](https://rfc.vac.dev/spec/17/)
|
|
|
|
You can find more information on this [here](./research-in-progress.md).
|