Comment by bawolff
2 days ago
I guess i don't really understand the niche being targeted. How is this different/better than just standard quic with TLS?
[Don't get me wrong, if you just wanted to make your own as a learning project or because its fun, that's cool too]
Good question — this is probably the most important clarification.
I6P is not trying to replace QUIC or TLS, and it’s not a competing transport. QUIC is the transport.
What I6P provides is a reusable P2P connectivity and transport layer built on top of QUIC, so applications don’t need to re-solve the same problems over and over again:
- Cryptographic peer identity decoupled from IPs - Explicit peer-to-peer session semantics (not client/server) - Built-in chunking, Merkle verification, erasure coding, and resumable transfers - Stream pooling and batching tuned for high-throughput P2P links - Session resumption and 0-RTT specifically for peer reconnections - A clean abstraction boundary so existing apps can integrate without rewriting their logic
You absolutely could build all of this directly on raw QUIC — and many projects do, each in slightly incompatible ways. I6P’s goal is to standardize that layer so P2P apps can focus on application logic instead of reimplementing transport mechanics.
So the niche isn’t “better QUIC”, it’s “QUIC-based P2P without bespoke transport stacks per project”.
Yeah, but why would you implement erasure coding over top of a reliable transport like QUIC?
Many of the other things kind of sound like what you would get already with raw quic.