9 ms·

Designing an IPv6-native P2P transport – lessons from building I6P

64 points by TheusHen 9mo ago

deleted 9mo ago
[deleted]
TheusHen 9mo ago
Author here. This article focuses on the transport-layer design, not a torrent client replacement. The goal is to provide a reusable IPv6-native P2P connection layer (QUIC-based, NAT-free) that existing clients or new applications can integrate without touching their higher-level logic. Feedback on design trade-offs is very welcome.
- bflesch 9mo ago
  Thanks for sharing. I want to ask you something: I understand that with IPv6 the idea is that every household receives several of IPv6 addresses so that every single IoT device has their unique IPv6 address and there is no NAT needed. Would it be possible to use a dozen of IPv6 addresses at the same time? Like send one UDP packet over certain IPv6 interface, next packet over another IPv6 interface, and so on. If both sending and receiving end have access to multiple IPv6 addresses I can see how this significantly increases complexity for tracking. Could you split up the traffic across dozens or hundreds of IPv6 source addresses?
  - neilalexander 9mo ago
    If you assign a subnet to a host, or allow the host to claim multiple addresses via ND from the link subnet, then you can use as many addresses as you want. You could give every process on your machine its own IPv6 address for example.
    - bflesch 9mo ago
      Yes, and if your host has access to several IPv6 addresses and maybe an IPv4 address it'd be nice to have something like wireguard actually utilize all of them in some random order. Same on the receiving end, wireguard server listenes both on IPv4 and IPv6 at same time and internally puts received packets in the proper order. I feel this would create significant struggles for any surveillance software because most firewalls I know are modeled on a source address / target address basis. If you have access to enough source IPv6 addresses you might even put your whole wireguard traffic into ICMP packet payload?
    - vaylian 9mo ago
      > via ND What is ND? Do you have a link with details?
      - immibis 9mo ago
        Neighbour discovery - IPv6 equivalent of ARP
  - pastage 9mo ago
    It is quite easy todo 100 lines of Python, you can even send ip packets with faked source adress.
    - bflesch 9mo ago
      Packets with fake source address can easily be spotted, and will raise an alert. In terms of using multiple interfaces for a single service it might be easy to hack together in a python script, but last time I checked the linux kernel support for bundling multiple interfaces is limited to redundancy and failover. What I'd like to have is a single service dynamically using many network interfaces with randomized packet timings and randomized packet scheduling (5 packets on first interface, pause on 2nd, some on third interface, sometimes send traffic simultaneously).
      - pastage 9mo ago
        If you want to hide you need to be in a place where you can do these kinds of stuff. Getting a peering without source filtering is possible, but even getting the simple version might be too hard for most.
    - ale42 9mo ago
      Networks are supposed to do egress filtering to prevent any packets with fake IPs from ever leaving the network. In practice it's not always so, but it mostly is. So you'd be limited to fake IP addresses in your own network, and doing so might raise alerts depending on the network infrastructure you live in.
  - krab 9mo ago
    > Could you split up the traffic across dozens or hundreds of IPv6 source addresses? Yes > I can see how this significantly increases complexity for tracking Not really. You just track at some prefix level. In general, the ISP will hand out a /64 per consumer so that's what you can track. From there, you can build more complex and more precise grouping rules for tracking.
    - bflesch 9mo ago
      I'd mix in some IPv4 of course, maybe pipe some of the connection via VPN interface so the physical route is not same for all packets.
  - jasonjayr 9mo ago
    IIRC you could still track because all those mutiple IPv6 addresses will have the same prefix.
  - jeroenhd 9mo ago
    The biggest tracking hurdle is to figure out if the ISP that handed out the block of addresses is handing out /64s, /56s, or /48s. The network provided to you is functionally the same as the IP address assigned to you with IPv4. In theory I could rent an IPv4 /29 (of which 6 addresses are usable) for like 20 euros a month from my home ISP to cause the same confusion but I doubt it'd confuse trackers to use those.
    - tucnak 9mo ago
      I thought most ISP's give out at least /64's for free these days? Telia gives out a /56, although unfortunately there's no way to migrate them. This was a big deal for my homelab when I was moving, as I had to manually update all prefixes everywhere. A pain in the ass.
      - fc417fc802 9mo ago
        By convention they're supposed to DHCP you at least a /64 if not something wider. I don't believe there's any expectation it be static (although it typically is AFAIK) and there are some providers that defy expectations by handing out narrower slices (up to and including /128).
        tucnak 9mo ago
        There's totally expectation of it being static, because why wouldn't it? They cut the ranges up at distribution switches and that's it. We're talking about IPv6 after all. There's absolutely zero benefit to dynamically-allocating ranges for ISP's here, in fact that would make things more complicated, and only serve to add additional load to the routing tables.
      - jeroenhd 9mo ago
        ISPs do, cloud providers often give smaller ranges. Re: renaming all the prefixes, that's why I use a ULA within my home network. Not as useful if you want your services available from the outside if you move ISPs (NAT66 can help on the inside but you'd still need to update all DNS records to use the new prefix). I'll stick with my ULA + VPN fallback for now, I don't expect the prefix to change more than once every five or six years. If you want a static prefix with a changing prefix, you're probably better off with getting a Hurricane Electric tunnel. Or if you want to go hard on the IPv6 homelab hobby, get your personal IPv6 address space and a bring-your-own-IP business ISP.
  - darkr 9mo ago
    yes - this is also part of the privacy extensions spec: https://datatracker.ietf.org/doc/html/rfc4941 https://datatracker.ietf.org/doc/html/rfc4941
  - immibis 9mo ago
    Yes, but realistically the guy who is tracking you tracks the first 64 bits of the address, which identify the network.
    - fc417fc802 9mo ago
      That's merely convention. I've encountered at least one VPS provider handing out /128's.
      - craftkiller 9mo ago
        It is more than convention, the /64 is the minimum allocation to support SLAAC. If you're getting less than a /64 you're not getting full support for IPv6.
        fc417fc802 9mo ago
        Well you're not getting support for SLAAC but I didn't understand that to be a core requirement to qualify as a functional IPv6 implementation. Regardless, my point is that allocations narrower than /64 exist in the wild for better or worse. So do IPv6 NAT implementations for that matter. If you assume either of those things don't exist then you might be in for a surprise.
      - Dylan16807 9mo ago
        While a situation like that is really annoying, I bet it's still generally following the rule of one /64 per network. What you're not getting is control over your IPs on that network.
      - immibis 9mo ago
        Whoever is tracking you is happy to block VPS providers so that's a win-win for them.
- walkthisway 9mo ago
  https://github.com/TheusHen https://github.com/TheusHen says you're 14 years old. The project is very impressive, as is https://github.com/TheusHen/ternary-ibex https://github.com/TheusHen/ternary-ibex and having papers: https://orcid.org/0009-0009-5055-5884 https://orcid.org/0009-0009-5055-5884 What's the education path for a 14 year old that does this stuff?
  - TheusHen 9mo ago
    I don’t really follow a “standard” education path. I’ve been interested in technology for as long as I can remember and had early access to computers and the internet. I’m about to turn 15 in a few days, and I’ve been programming for almost 6 years now — I started when I was 9. Most of what I know comes from self-study, experimentation, reading documentation, breaking things, and rebuilding them. I usually learn by doing projects rather than following a fixed curriculum. As for papers, I mostly write by organizing ideas that come to my head and then grounding them with research and practical knowledge. Lately, I’ve been considering writing one about implantable RFID microchips, just to explore the topic more deeply.
- fc417fc802 9mo ago
  > QUIC-based, NAT-free I realize it's intended to be an unsupported edge case but I'm curious. What happens in the event a NAT is present along the IPv6 network path? Do you just forward a port the same as you would with the various IPv4 solutions and move on? Or does it break catastrophically? Something else?
lxgr 9mo ago
> IPv6 restores globally routable addresses to every node, letting peers connect without contortions. Global routeability doesn't automatically mean global reachability. Many consumer and professional routers will block inbound TCP connections, and incoming UDP traffic without at least similar outbound UDP traffic preceding it, so you will still need hole punching. Hole punching does get significantly more easy with v6, though, since there's really only one way to do "outbound connections only" firewalling (while there's several ways to port translate, some really hostile to hole punching). Arguably one thing that's missing is a very simple, implicit standard that allows signalling a willingness to accept an inbound TCP connection from a given IP/port that such stateful firewalls can honor, similar to how they already implicitly do it for UDP, but with HTTP 3 running over UDP, the point might well be moot soon.
- Giefo6ah 9mo ago
  That simple, implicit standard exists since RFC793: Simultaneous initiation is only slightly more complex, as is shown in figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to ESTABLISHED. TCP A TCP B 1. CLOSED CLOSED 2. SYN-SENT --> <SEQ=100><CTL=SYN> ... 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ... 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED Simultaneous Connection Synchronization Figure 8. Every stateful firewall supports this. All you need to communicate off-band is IP addresses and ports.
  - lxgr 9mo ago
    Huh, TIL, thank you! Are you sure all firewalls support this? RFC 5382 seems to specify it, but then again, middleboxes aren't exactly known for strict RFC compliance...
- the8472 9mo ago
  At least there's an explicit standard for signalling: RFC 6887 Port Control Protocol. Many routers also support it. But it's often disabled for the same reason as having router-level firewalls in the first place.
egberts1 9mo ago
If it weren't for Internet infrastructure hobbling SCTP (via firewall), SCTP provides the same QUICC (session multiplexing) within same 5-tuple and with way much lower packet overhead and smaller code base too. As with any network protocol design, the tradeoff is slighty gained from versatility over loss of privacy. So it depends on your triage of needs: security, privacy, confidentiality. Now with the latest "quadage", unobservability (plausible deniability).
- jeroenhd 9mo ago
  From what I recall, one downside to SCTP is that things like resuming from different IP addresses and arbitrarily changing the amount of connections per socket didn't work well in standard SCTP. Plus the TLS story isn't as easy. QUIC makes that stuff easier to work with from an application perspective. Still a fascinating protocol, doomed to be used exclusively as a weird middle layer for websockets and as a carrier protocol for internal telco networks.
- alphazard 9mo ago
  Unfortunately most of the existing communication protocols that are standardized conform to a broken model of networking where security is not provided by the network layer. Cryptography can't be thought of as an optional layer that people might want to turn on. That bad idea shows up in many software systems. It needs to be thought of as a tool to ensure that a behavior is provided reliably. In this case, that the packets are really coming from who you think they are coming from. There is no reason to believe that they are without cryptography. It's not optional; it's required to provide the quality of service that the user is expecting. DTLS and QUIC both immediately secure the connection. QUIC then goes on to do its stream multiplexing. The important thing is that the connection is secured in (or just above) the network layer. Had OSI (or whoever else) gotten that part right, then all of these protocols, like SCTP, would actually be useful.
api 9mo ago
A number of existing P2P things already do this, though usually with UDP.
j4nek 9mo ago
to me this all seems heavy much vibed - take a look at the github repo
immibis 9mo ago
After closing three popups, I closed the page.
- wiredpancake 9mo ago
  [dead]
KolmogorovComp 9mo ago
Tangentially related, but any feedback from devs using P2P? Usable for consumers, or too many peers not able to connect? using WebRTC or something more high-level like peerjs? What's the landscape today?
mrbluecoat 9mo ago
> globally routable addresses ... simpler security I don't believe those are synonymous.
krautburglar 9mo ago
Easy & reliable p2p would upset so many apple carts. I get the feeling that if something really started taking root in that space, the big boys would push for a new obstruction--i.e. NATv6 or some such thing--to put the genie back in the bottle. And since so many people "fake it 'til they make it", they will swallow those worms like eager baby birds. Anyone who rejects the worms will be branded a heretic.
bawolff 9mo 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]
- TheusHen 9mo ago
  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”.
  - bawolff 9mo ago
    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.

64 points by TheusHen 9mo ago

deleted 9mo ago

[deleted]

Author here. This article focuses on the transport-layer design, not a torrent client replacement. The goal is to provide a reusable IPv6-native P2P connection layer (QUIC-based, NAT-free) that existing clients or new applications can integrate without touching their higher-level logic. Feedback on design trade-offs is very welcome.

bflesch 9mo ago
Thanks for sharing. I want to ask you something: I understand that with IPv6 the idea is that every household receives several of IPv6 addresses so that every single IoT device has their unique IPv6 address and there is no NAT needed. Would it be possible to use a dozen of IPv6 addresses at the same time? Like send one UDP packet over certain IPv6 interface, next packet over another IPv6 interface, and so on. If both sending and receiving end have access to multiple IPv6 addresses I can see how this significantly increases complexity for tracking. Could you split up the traffic across dozens or hundreds of IPv6 source addresses?
- neilalexander 9mo ago
  If you assign a subnet to a host, or allow the host to claim multiple addresses via ND from the link subnet, then you can use as many addresses as you want. You could give every process on your machine its own IPv6 address for example.
  - bflesch 9mo ago
    Yes, and if your host has access to several IPv6 addresses and maybe an IPv4 address it'd be nice to have something like wireguard actually utilize all of them in some random order. Same on the receiving end, wireguard server listenes both on IPv4 and IPv6 at same time and internally puts received packets in the proper order. I feel this would create significant struggles for any surveillance software because most firewalls I know are modeled on a source address / target address basis. If you have access to enough source IPv6 addresses you might even put your whole wireguard traffic into ICMP packet payload?
  - vaylian 9mo ago
    > via ND What is ND? Do you have a link with details?
    - immibis 9mo ago
      Neighbour discovery - IPv6 equivalent of ARP
- pastage 9mo ago
  It is quite easy todo 100 lines of Python, you can even send ip packets with faked source adress.
  - bflesch 9mo ago
    Packets with fake source address can easily be spotted, and will raise an alert. In terms of using multiple interfaces for a single service it might be easy to hack together in a python script, but last time I checked the linux kernel support for bundling multiple interfaces is limited to redundancy and failover. What I'd like to have is a single service dynamically using many network interfaces with randomized packet timings and randomized packet scheduling (5 packets on first interface, pause on 2nd, some on third interface, sometimes send traffic simultaneously).
    - pastage 9mo ago
      If you want to hide you need to be in a place where you can do these kinds of stuff. Getting a peering without source filtering is possible, but even getting the simple version might be too hard for most.
  - ale42 9mo ago
    Networks are supposed to do egress filtering to prevent any packets with fake IPs from ever leaving the network. In practice it's not always so, but it mostly is. So you'd be limited to fake IP addresses in your own network, and doing so might raise alerts depending on the network infrastructure you live in.
- krab 9mo ago
  > Could you split up the traffic across dozens or hundreds of IPv6 source addresses? Yes > I can see how this significantly increases complexity for tracking Not really. You just track at some prefix level. In general, the ISP will hand out a /64 per consumer so that's what you can track. From there, you can build more complex and more precise grouping rules for tracking.
  - bflesch 9mo ago
    I'd mix in some IPv4 of course, maybe pipe some of the connection via VPN interface so the physical route is not same for all packets.
- jasonjayr 9mo ago
  IIRC you could still track because all those mutiple IPv6 addresses will have the same prefix.
- jeroenhd 9mo ago
  The biggest tracking hurdle is to figure out if the ISP that handed out the block of addresses is handing out /64s, /56s, or /48s. The network provided to you is functionally the same as the IP address assigned to you with IPv4. In theory I could rent an IPv4 /29 (of which 6 addresses are usable) for like 20 euros a month from my home ISP to cause the same confusion but I doubt it'd confuse trackers to use those.
  - tucnak 9mo ago
    I thought most ISP's give out at least /64's for free these days? Telia gives out a /56, although unfortunately there's no way to migrate them. This was a big deal for my homelab when I was moving, as I had to manually update all prefixes everywhere. A pain in the ass.
    - fc417fc802 9mo ago
      By convention they're supposed to DHCP you at least a /64 if not something wider. I don't believe there's any expectation it be static (although it typically is AFAIK) and there are some providers that defy expectations by handing out narrower slices (up to and including /128).
      - tucnak 9mo ago
        There's totally expectation of it being static, because why wouldn't it? They cut the ranges up at distribution switches and that's it. We're talking about IPv6 after all. There's absolutely zero benefit to dynamically-allocating ranges for ISP's here, in fact that would make things more complicated, and only serve to add additional load to the routing tables.
    - jeroenhd 9mo ago
      ISPs do, cloud providers often give smaller ranges. Re: renaming all the prefixes, that's why I use a ULA within my home network. Not as useful if you want your services available from the outside if you move ISPs (NAT66 can help on the inside but you'd still need to update all DNS records to use the new prefix). I'll stick with my ULA + VPN fallback for now, I don't expect the prefix to change more than once every five or six years. If you want a static prefix with a changing prefix, you're probably better off with getting a Hurricane Electric tunnel. Or if you want to go hard on the IPv6 homelab hobby, get your personal IPv6 address space and a bring-your-own-IP business ISP.
- darkr 9mo ago
  yes - this is also part of the privacy extensions spec: https://datatracker.ietf.org/doc/html/rfc4941 https://datatracker.ietf.org/doc/html/rfc4941
- immibis 9mo ago
  Yes, but realistically the guy who is tracking you tracks the first 64 bits of the address, which identify the network.
  - fc417fc802 9mo ago
    That's merely convention. I've encountered at least one VPS provider handing out /128's.
    - craftkiller 9mo ago
      It is more than convention, the /64 is the minimum allocation to support SLAAC. If you're getting less than a /64 you're not getting full support for IPv6.
      - fc417fc802 9mo ago
        Well you're not getting support for SLAAC but I didn't understand that to be a core requirement to qualify as a functional IPv6 implementation. Regardless, my point is that allocations narrower than /64 exist in the wild for better or worse. So do IPv6 NAT implementations for that matter. If you assume either of those things don't exist then you might be in for a surprise.
    - Dylan16807 9mo ago
      While a situation like that is really annoying, I bet it's still generally following the rule of one /64 per network. What you're not getting is control over your IPs on that network.
    - immibis 9mo ago
      Whoever is tracking you is happy to block VPS providers so that's a win-win for them.
walkthisway 9mo ago
https://github.com/TheusHen https://github.com/TheusHen says you're 14 years old. The project is very impressive, as is https://github.com/TheusHen/ternary-ibex https://github.com/TheusHen/ternary-ibex and having papers: https://orcid.org/0009-0009-5055-5884 https://orcid.org/0009-0009-5055-5884 What's the education path for a 14 year old that does this stuff?
- TheusHen 9mo ago
  I don’t really follow a “standard” education path. I’ve been interested in technology for as long as I can remember and had early access to computers and the internet. I’m about to turn 15 in a few days, and I’ve been programming for almost 6 years now — I started when I was 9. Most of what I know comes from self-study, experimentation, reading documentation, breaking things, and rebuilding them. I usually learn by doing projects rather than following a fixed curriculum. As for papers, I mostly write by organizing ideas that come to my head and then grounding them with research and practical knowledge. Lately, I’ve been considering writing one about implantable RFID microchips, just to explore the topic more deeply.
fc417fc802 9mo ago
> QUIC-based, NAT-free I realize it's intended to be an unsupported edge case but I'm curious. What happens in the event a NAT is present along the IPv6 network path? Do you just forward a port the same as you would with the various IPv4 solutions and move on? Or does it break catastrophically? Something else?

lxgr 9mo ago

> IPv6 restores globally routable addresses to every node, letting peers connect without contortions. Global routeability doesn't automatically mean global reachability. Many consumer and professional routers will block inbound TCP connections, and incoming UDP traffic without at least similar outbound UDP traffic preceding it, so you will still need hole punching. Hole punching does get significantly more easy with v6, though, since there's really only one way to do "outbound connections only" firewalling (while there's several ways to port translate, some really hostile to hole punching). Arguably one thing that's missing is a very simple, implicit standard that allows signalling a willingness to accept an inbound TCP connection from a given IP/port that such stateful firewalls can honor, similar to how they already implicitly do it for UDP, but with HTTP 3 running over UDP, the point might well be moot soon.

Giefo6ah 9mo ago
That simple, implicit standard exists since RFC793: Simultaneous initiation is only slightly more complex, as is shown in figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to ESTABLISHED. TCP A TCP B 1. CLOSED CLOSED 2. SYN-SENT --> <SEQ=100><CTL=SYN> ... 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ... 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED Simultaneous Connection Synchronization Figure 8. Every stateful firewall supports this. All you need to communicate off-band is IP addresses and ports.
- lxgr 9mo ago
  Huh, TIL, thank you! Are you sure all firewalls support this? RFC 5382 seems to specify it, but then again, middleboxes aren't exactly known for strict RFC compliance...
the8472 9mo ago
At least there's an explicit standard for signalling: RFC 6887 Port Control Protocol. Many routers also support it. But it's often disabled for the same reason as having router-level firewalls in the first place.

egberts1 9mo ago

If it weren't for Internet infrastructure hobbling SCTP (via firewall), SCTP provides the same QUICC (session multiplexing) within same 5-tuple and with way much lower packet overhead and smaller code base too. As with any network protocol design, the tradeoff is slighty gained from versatility over loss of privacy. So it depends on your triage of needs: security, privacy, confidentiality. Now with the latest "quadage", unobservability (plausible deniability).

jeroenhd 9mo ago
From what I recall, one downside to SCTP is that things like resuming from different IP addresses and arbitrarily changing the amount of connections per socket didn't work well in standard SCTP. Plus the TLS story isn't as easy. QUIC makes that stuff easier to work with from an application perspective. Still a fascinating protocol, doomed to be used exclusively as a weird middle layer for websockets and as a carrier protocol for internal telco networks.
alphazard 9mo ago
Unfortunately most of the existing communication protocols that are standardized conform to a broken model of networking where security is not provided by the network layer. Cryptography can't be thought of as an optional layer that people might want to turn on. That bad idea shows up in many software systems. It needs to be thought of as a tool to ensure that a behavior is provided reliably. In this case, that the packets are really coming from who you think they are coming from. There is no reason to believe that they are without cryptography. It's not optional; it's required to provide the quality of service that the user is expecting. DTLS and QUIC both immediately secure the connection. QUIC then goes on to do its stream multiplexing. The important thing is that the connection is secured in (or just above) the network layer. Had OSI (or whoever else) gotten that part right, then all of these protocols, like SCTP, would actually be useful.

api 9mo ago

A number of existing P2P things already do this, though usually with UDP.

j4nek 9mo ago

to me this all seems heavy much vibed - take a look at the github repo

immibis 9mo ago

After closing three popups, I closed the page.

wiredpancake 9mo ago
[dead]

KolmogorovComp 9mo ago

Tangentially related, but any feedback from devs using P2P? Usable for consumers, or too many peers not able to connect? using WebRTC or something more high-level like peerjs? What's the landscape today?

mrbluecoat 9mo ago

> globally routable addresses ... simpler security I don't believe those are synonymous.

krautburglar 9mo ago

Easy & reliable p2p would upset so many apple carts. I get the feeling that if something really started taking root in that space, the big boys would push for a new obstruction--i.e. NATv6 or some such thing--to put the genie back in the bottle. And since so many people "fake it 'til they make it", they will swallow those worms like eager baby birds. Anyone who rejects the worms will be branded a heretic.

bawolff 9mo 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]

TheusHen 9mo ago
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”.
- bawolff 9mo ago
  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.