early review request for a mixnet implementation in go-libp2p before I open a PR

[nehraa]

Hi all,

I’d like early feedback on a feature idea I’ve been prototyping in my fork before I open a PR.

Motivation

I started exploring this because I was working on a decentralized network that needed stronger
metadata privacy for audio/video communication.

I initially considered routing that traffic over Tor, but that did not seem like a good fit for
the use case:

• the performance was too slow for the kind of media traffic I was testing
• the TCP-oriented model was not ideal for what I wanted
• I was already using libp2p as the networking base, so I wanted something that integrated more
  naturally with the libp2p stack

That led me to experiment with a mixnet-style design on top of libp2p.

That original project is currently on hold while I do more research and because I have not found
enough collaborators/funding yet, so I thought it would be useful to ask whether this idea could
make sense as a contribution to go-libp2p.

Proposed feature

The idea is to provide an optional metadata-private overlay for libp2p communication rather than
replacing the existing transport stack.

The prototype currently follows this model:

• build configurable multi-hop routes through relay peers
• use multiple parallel circuits for distribution/redundancy
• discover relays through the DHT
• support relay selection modes such as RTT, random, and hybrid
• support onion-style forwarding with full and header-only encryption modes
• optionally process payloads through a compress/encrypt/shard pipeline
• support reconstruction from partial shard delivery
• include privacy-hardening controls such as header padding, payload padding, auth tags, and
  timing jitter
• expose a stream-style API surface for applications

The intended use case is that applications which need stronger metadata privacy could opt into
this layer while remaining within the libp2p ecosystem.

Current status

In my fork, I currently have a mixnet package with a runtime plus stream-like entry points such
as Send, OpenStream, and AcceptStream, along with relay-side forwarding, recovery logic, and
tests for end-to-end send/receive, header-only forwarding, relay behavior, and failure/recovery
scenarios.

I also previously split out at least one privacy-related fix in my fork as a separate PR: adding
MaxJitter to reduce timing correlation between shards.

For performance discussion, I do not want to quote absolute MB/s numbers in this issue because
those are too hardware-dependent. The more useful signal seems to be relative overhead. In my
local testing, header-only mode showed essentially identical relative overhead behavior compared
with the baseline runs I was using, but I would treat that as preliminary until there is broader
review.

There is also a CES pipeline, which is compression, encryption, and sharding in this order. Compression obscutes the data, and then we encrypt it, shard it, and distribute it. but its optional the same way multi circuit data delivery and the no of hops are also configurable.
Request for feedback

Before I prepare a PR, I’d like feedback on the following:

• does this belong in go-libp2p conceptually
• does the general architecture make sense for libp2p
• are there obvious security or protocol-design problems
• is the API direction compatible with libp2p conventions
• should this be split, simplified, or scoped differently before a PR
• what benchmarks, interoperability checks, or threat-model validation would you want before
  review

One important note: I used an AI coding agent for part of the implementation, so I would
especially appreciate human review of the architecture, protocol assumptions, and code quality
before I turn this into a formal PR.

If this seems directionally interesting, I can open a draft PR for concrete discussion.