All-Hands Discussion Points

Why this doc

• Writing down the details wrt mix and waku integration here before we move it to a github discussion or a spec itself.
• Having it in notion helps others like @Akshaya to contribute actively to this doc. I will try to move content from here to appropriate channels as and when we think it is ready.

Key points wrt libp2p mix ↔ Waku.

Mix defines 3 roles for the nodes in the mix network - entry, exit, intermediary. Each node in the network can have all 3 roles or can act as just an entry/exit node as well.

• An entry node is the node that wants to publish messages into the network using mix protocol
• An exit node is responsible for delivery messages to destination peer in the network.
• An intermediary node is responsible for just forwarding mix packet to the next mix node in the path.

For more details please refer here

Mix vs Tor type network

Mix networks are very different from Tor type networks.

1. Tor has a concept of a circuit which is established first before packets are tunneled through the same circuit for a certain duration e.g 10 mins or so.
2. whereas mix networks emphasise that the list of nodes in the mix path are to be chosen at random for each message being sent. this ensures higher anonymity than tor and even works against various forms of passive and timing analysis.
3. mix networks also ensure that packet sent out is always of fixed size so that no observer can analyze and map packet size to path and try to determine the sender
   1. mix uses the Sphinx cryptographic packet format to ensure that both incoming and outgoing packets are of fixed size. The packet is padded up to the maximum size S, but Sphinx doesn’t use traditional padding. Instead, the inner layer is padded to account for both the header and payload, up to the maximum path length r. This padding is also encrypted. As a result, even if the number of hops L is less than r, the padding at each hop will vary based on the difference between L and r. From the network’s perspective, everything including the padding appears indistinguishable. If we choose to set L = r, it could make the system more efficient, but it would reduce flexibility.
4. mix networks have different packet mixing types
   1. continuous time mixes : use random delays and not forward packets in order of receiving by each mix node i.e packets can get jumbled when they are sent out. continuous-time mixes offer larger, theoretically unbounded anonymity sets due to the memoryless property of the exponential distribution. Additionally, continuous-time mixes use bandwidth more effectively and reduce the likelihood of correlation-based attacks.
   2. batch mixes: batch packets received and send out at random/fixed times. These are less efficient and have finite anonymity sets
5. Transport Choice for Mix. Which transport makes more sense TCP , UDP or QUIC. Refer here

Mix Implementation Notes

1. Mix can be implemented in 3 forms as of now. The doc is being written assuming first approach i.e protocol and if this assumption changes after further analysis then the approach and document will have to modified.
   1. mix being implemented as a libp2p protocol that can reuse existing transport connection. mix offers a virtual connection which can be used by existing protocols such as lightpush to publish messages.
      1. can use a separate transport (Separate transport needs to be evaluated and considered in later phases).
   2. mix being implemented as a libp2p transport due to certain limitations, we don’t see any challenges with initial phase, but needs further analysis on impact in general. This will force each node to have 2 different transport connections to same peer (if peer also supports mix).
   3. some sort of a hybrid implementation with protocol and virtual transport taking a cue from circuit-relay??
2. destination node need not support mix protocol.
   1. Mix does not tunnel connections end-to-end, so there is no multistream negotiation within Mix. There are ways to get around this, a possible approach is suggested here
   2. one challenge is that the exit learns the message.

Mix and Waku Integration

libp2p Mix protocol’s integration into waku is being done to provide stronger anonymity for waku users and protocols especially sender anonymity and protection against timing analysis. The current anonymity provided by using StrictNoSign with gossipsub is not sufficient enough. Refer to this article for more details.

Integration of Mix into waku shall be done in multi-phased approach. This enables publishers to have stronger anonymity .