The document describes [libp2p mix](https://rfc.vac.dev/vac/raw/mix/) integration into waku.
This integration provides higher anonymity for users publishing or querying for messages to/from the Waku network.
This document covers integration of mix with [lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) and [store](https://rfc.vac.dev/waku/standards/core/13/store) protocols.
Both of these are `request-response` based protocols that follow a service-user and a service-provider model.
A node that initiates the request is a `service-user/client` whereas a node that replies to the request is the `service-provider/service-node`.
This document also covers the aspect of relay nodes acting as mix nodes.
Integration of [waku relay](https://rfc.vac.dev/waku/standards/core/11/relay) with mix is not covered in this document.
## Background / Rationale / Motivation
Waku protocols have weak sender/originator anonymity as explained in [Waku Privacy and Anonymity Analysis](https://vac.dev/rlog/wakuv2-relay-anon/).
Without further anonymization, it is easy to analyze the network traffic and determine the originator of messages published into the network.
Topic interests of a user can be identified by analyzing [Store](https://rfc.vac.dev/waku/standards/core/13/store) query messages sent by a user.
Same applies for topic subscriptions via [Filter](https://rfc.vac.dev/waku/standards/core/12/filter) protocol.
`Mix` protocol allows libp2p nodes to send messages without revealing the sender's identity (peer ID, IP address) to intermediary mix nodes or the recipient/destination.
Anonymity is achieved by using the [Sphinx packet format](#references), which encrypts and routes messages through a series of mix nodes before reaching the recipient.
By integrating the `mix` protocol into the waku network, we can improve the anonymity for publishers and store query users.
They MAY do so by updating their [ENR](#enr-updates) and using one of the ENR based discovery methods.
Nodes that want higher anonymity while publishing a message via [lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) or performing a [store](https://rfc.vac.dev/waku/standards/core/13/store) query SHOULD use the `mix` protocol to route their messages to the destination.
Sender Node that would like to use `mix` protocol SHOULD discover enough mix nodes so that there is always a healthy pool of mix nodes available for selection.
The pool size of mix nodes SHOULD be large enough for the mixing to be effective.
We RECOMMEND a pool size of at least 100 mix nodes for the mixing to be effective.
The serialized [Waku Message](https://rfc.vac.dev/waku/standards/core/14/message) MUST be the payload in the [sphinx packet](https://rfc.vac.dev/vac/raw/mix#4-sphinx-packet-format).
In order to provide anonymity of the sender node from the `service-node`, `Single Use reply blocks` or `anonymous replies` as specified in the original [sphinx](#references) paper SHALL be used.
A node that sends messages using `mix` MAY use two redundant (paths)[https://rfc.vac.dev/vac/raw/mix#24-node-discovery] to have better reliability of the message being delivered.
It is up to the higher-layer mixed protocol to deduplicate redundant messages received in this way.
## Node Roles
Mix protocol defines 3 roles for the nodes in the mix network - `sender`, `exit`, `intermediary`.
- An `sender` node is the originator node of a message, i.e a node that wishes to publish/query messages to/from the waku network.
- An `exit` node is responsible for delivering messages to destination peer in the network.
- An `intermediary` node is responsible for forwarding a mix packet to the next mix node in the path.
A Waku relay node SHOULD by default have mix `intermediary` and `exit` node roles in the network.
The implementation MAY provide a configuration to disable a node from acting as an `intermediary\exit` node.
Each waku node that supports the `mix intermediary or exit role` SHOULD indicate the same in its discoverable [ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md).
- The `bit 5` in the [waku2 ENR key](https://github.com/waku-org/specs/blob/master/standards/core/enr.md#waku2-enr-key) is reserved to indicate `mix` support. This bit MUST be set to true to indicate `mix` support.
This moves the problem into discovery domain and requires the following from discovery mechanisms:
1. It is important for nodes to be able to discover as many nodes as possible quickly. This becomes especially important for edge nodes that come online just to publish/query messages for a short period of time.
2. It is important to have the most recent online status of the nodes so that mix paths that are selected are not broken which lead to reliability issues.
Point-2 above can be mitigated partially by choosing redundant mix paths for the same message by the sender node.
This may not be an effective solution as it increases the overall bandwidth usage.
## Spam Protection
Mix protocol in waku network SHOULD have `rate-limiting/spam` protection to handle scenarios such as below:
1. Any node can generate a mix packet and publish into the mix network. Hence there needs to be some validation as to who is allowed to publish and whether the user is within allowed rate-limits.
2. Any node can intentionally generate paths which are broken and send messages into the mix network.
3. An attacker can spawn a huge number of mix nodes so that user behaviour is observed in order to determine traffic patterns and deanonymize users.
There is a need to enforce rate-limits and spam protect the mix network.
