vac:p2p:ift:2025q4-nimlibp2p-mix
Upstream spec for mix protocol and add stream reuse to reduce latency
Description
The mix specification currently resides in vacp2p#rfc-index. The goal is to upstream it into libp2p#specs, ensuring adoption across libp2p implementations. Additionally, in late Q3 we identified an improvement: rather than opening and closing a new stream for each mix packet, streams can be reused, reducing lifecycle overhead and lowering end-to-end latency. Finally we found out that there’s a possible metadata leakage when multiple Sphinx packets are broadcasted due to gragmentation of a large message by an upstram protocol sent in a burst.
Task List
Specs
- fully qualified name:
vac:p2p:ift:2025q4-nimlibp2p-mix:specs - owner:
- status: not started
- start-date:
- end-date:
Description
Collaborate with ACZ team into upstreaming initial mix design and rationale to
libp2p/spec as proposal or draft PR. This task was originally part of Q3 but moved to
Q4 as specs update was not completed
Deliverables
- Draft PR merged into
libp2p/specs
Stream Reuse
- fully qualified name:
vac:p2p:ift:2025q4-nimlibp2p-mix:stream-reuse - owner:
- status: not started
- start-date:
- end-date:
Description
Implement long-lived stream reuse between mix nodes, by establishing a persistent stream between mix peers. Maintain a queue of outgoing Sphinx packets per peer, and dispatch them over the persistent stream. vacp2p/mix#88
Deliverables
- Persistent streams established between peers
- Packet queue mechanism implemented
- Test units
Rate limit publishing
- fully qualified name:
vac:p2p:ift:2025q4-nimlibp2p-mix:rate-limit - owner:
- status: not started
- start-date:
- end-date:
Description
Introduce a randomized delay before the initiator sends each Sphinx packet to the first hop. This is important to avoid metadata leakage when multiple Sphinx packets (e.g., due to fragmentation of a large message by an upstream protocol) are sent in a burst.
Deliverables
- Sender should not be able to send a burst of mix messages but instead have them rate limited with a random delay similar to the one used for hops.