6 ms·

Not sure what the difference is between this and any regular P2P network?

by astonex 3mo ago

rklaehn 3mo ago
A difference between iroh and many p2p networks is that we try to use existing IETF standards (QUIC, TLS) as much as possible instead of reinventing the wheel. An iroh connection is just a QUIC connection, using TLS and TLS ALPNs for protocol negotiation. If you look at an iroh connection using wireshark, it is just a QUIC connection. You can use all the existing tools, and a lot of things you learn when using iroh transfers to traditional QUIC connections and vice versa. Most iroh contributors come out of the p2p world, and you could say that we had a bit of abstraction fatigue after working on regular P2P networks for some years. We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery. Note that there are some "regular p2p networks" that use iroh under the hood, e.g. holochain https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-here-and-its-smooth-like-butter/ https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-... as well as various p2p chat apps. https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-here-and-its-smooth-like-butter/ https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-...
- weavejester 3mo ago
  Forgive me if this is an ignorant question, but does your use of the Mainline DHT mean that Bittorrent clients will be responding to P2P address lookups from Iroh?
  - rklaehn 3mo ago
    First of all: the p2p address lookup is an optional feature. You have to explicitly enable it. Mainline is incredibly frugal in terms of resource use, but we want it disabled by default so mobile apps don't look like bittorrent clients and get flagged by the OS. When we do a p2p address lookup, every mainline server node could possibly be responding. Any bep_0044 record gets stored on 20 random mainline server nodes. So a bittorrent client that participates in the DHT as a server and is long running enough to be included into the DHT routing tables will respond, yes.
- octoberfranklin 3mo ago
  > We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery. Bravo, because they always get it wrong. DHTs used for decentralized DNS-like naming purposes have truly unique scaling requirements; you have to use a connectionless protocol (like bittorrent does) but everybody seems to be fixated on connection-oriented protocols like TCP, HTTP, and QUIC. The latter just don't work for this extreme use case. No other use case on the entire internet requires such an extremely large out-degree for end-user nodes in the node connection graph. Allocating connection-state, even a very small amount, opens up the least-powerful nodes to easy DoS attacks. And from there it's easy for a motivated attacker to push the network away from decentralization and force it in to a highly-centralized state.
  - rklaehn 3mo ago
    I might be crazy, but I got a side project to write a DHT using iroh. The key is to use QUIC 0-rtt connections to keep the connection overhead minimal. But at this point it is just a toy project to push the limits of what is possible with iroh and 0-rtt. It is not used in prod and won't be any time soon :-) https://www.iroh.computer/blog/lets-write-a-dht-1 https://www.iroh.computer/blog/lets-write-a-dht-1
    - octoberfranklin 3mo ago
      Even 0-RTT connections still allocate connection state. IPFS learned this the hard way. The mental model you need is the attacks that cause the Linux kernel to send SYN cookies. Learn how that attack works and you'll understand why you can't have connection state here (and neither does the Linux kernel during a SYN flood). https://en.wikipedia.org/wiki/SYN_flood https://en.wikipedia.org/wiki/SYN_flood https://en.wikipedia.org/wiki/SYN_cookies https://en.wikipedia.org/wiki/SYN_cookies It's much worse for DNS-like services, which is why after all these years DNS still uses UDP. Imagine if the root zone servers had to allocate connection state! But it all depends on what you're using the DHT for. If you've decided "let's write a DHT that won't be used for naming or DNS-like purposes" then you'll probably get away with it.

Not sure what the difference is between this and any regular P2P network?

by astonex 3mo ago

Not sure what the difference is between this and any regular P2P network?

A difference between iroh and many p2p networks is that we try to use existing IETF standards (QUIC, TLS) as much as possible instead of reinventing the wheel. An iroh connection is just a QUIC connection, using TLS and TLS ALPNs for protocol negotiation. If you look at an iroh connection using wireshark, it is just a QUIC connection. You can use all the existing tools, and a lot of things you learn when using iroh transfers to traditional QUIC connections and vice versa. Most iroh contributors come out of the p2p world, and you could say that we had a bit of abstraction fatigue after working on regular P2P networks for some years. We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery. Note that there are some "regular p2p networks" that use iroh under the hood, e.g. holochain https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-here-and-its-smooth-like-butter/ https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-... as well as various p2p chat apps. https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-here-and-its-smooth-like-butter/ https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-...

weavejester 3mo ago
Forgive me if this is an ignorant question, but does your use of the Mainline DHT mean that Bittorrent clients will be responding to P2P address lookups from Iroh?
- rklaehn 3mo ago
  First of all: the p2p address lookup is an optional feature. You have to explicitly enable it. Mainline is incredibly frugal in terms of resource use, but we want it disabled by default so mobile apps don't look like bittorrent clients and get flagged by the OS. When we do a p2p address lookup, every mainline server node could possibly be responding. Any bep_0044 record gets stored on 20 random mainline server nodes. So a bittorrent client that participates in the DHT as a server and is long running enough to be included into the DHT routing tables will respond, yes.
octoberfranklin 3mo ago
> We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery. Bravo, because they always get it wrong. DHTs used for decentralized DNS-like naming purposes have truly unique scaling requirements; you have to use a connectionless protocol (like bittorrent does) but everybody seems to be fixated on connection-oriented protocols like TCP, HTTP, and QUIC. The latter just don't work for this extreme use case. No other use case on the entire internet requires such an extremely large out-degree for end-user nodes in the node connection graph. Allocating connection-state, even a very small amount, opens up the least-powerful nodes to easy DoS attacks. And from there it's easy for a motivated attacker to push the network away from decentralization and force it in to a highly-centralized state.
- rklaehn 3mo ago
  I might be crazy, but I got a side project to write a DHT using iroh. The key is to use QUIC 0-rtt connections to keep the connection overhead minimal. But at this point it is just a toy project to push the limits of what is possible with iroh and 0-rtt. It is not used in prod and won't be any time soon :-) https://www.iroh.computer/blog/lets-write-a-dht-1 https://www.iroh.computer/blog/lets-write-a-dht-1
  - octoberfranklin 3mo ago
    Even 0-RTT connections still allocate connection state. IPFS learned this the hard way. The mental model you need is the attacks that cause the Linux kernel to send SYN cookies. Learn how that attack works and you'll understand why you can't have connection state here (and neither does the Linux kernel during a SYN flood). https://en.wikipedia.org/wiki/SYN_flood https://en.wikipedia.org/wiki/SYN_flood https://en.wikipedia.org/wiki/SYN_cookies https://en.wikipedia.org/wiki/SYN_cookies It's much worse for DNS-like services, which is why after all these years DNS still uses UDP. Imagine if the root zone servers had to allocate connection state! But it all depends on what you're using the DHT for. If you've decided "let's write a DHT that won't be used for naming or DNS-like purposes" then you'll probably get away with it.