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.
> 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.
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 :-)
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).
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.
I love mainline and also really appreciate how lightweight it is by just using UDP packets. But UDP packets have their limits. With the maximum MTU you can expect to work, the payload can't be more than about 1000 bytes, which is the limit of bep_0044.
But there are some use cases where you want to store a bit more than 1000 bytes. Not giant amounts, but maybe 4 KiB. Mainline won't ever be able to do this.
Iroh 0-rtt is very lightweight. On the network level you see one or two UDP packets flying in one direction, one or two UDP packets flying back, and that's the end of the interaction. You close the connection, and all state you have to retain is a session cookie on the client side.
It is still much heavier than bare UDP packets, but much lighter than a normal 1-rtt QUIC connection, which is already pretty lightweight.
Here are some details about 0-rtt. The API has changed slightly since then, but the basics remain the same of course: https://www.iroh.computer/blog/0rtt-api
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?
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.
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-... as well as various p2p chat apps.
https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-...