Waku is modular: several protocols are available and applications can decide on how they want to turn the dials on the [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html). Here are the different types of protocols Waku offers:
`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:
