3 ms·

I don't understand the problem its trying to solve in the first place, IP works just fine, such as DNS. There is already IPv6 and quic, you need vendor and maj

by Thaxll 3mo ago

I don't understand the problem its trying to solve in the first place, IP works just fine, such as DNS. There is already IPv6 and quic, you need vendor and major software to have any traction in that field.

Arqu 3mo ago
Establishing direct connections on the other hand is a much harder problem with the current internet infrastructure.
huflungdung 3mo ago
[dead]
Kevcmk 3mo ago
I'm not affiliated with Iroh or even using it, but... "IP works just fine". What!? This is _not_ a solved problem
- PantaloonFlames 3mo ago
  I think that was the question: What is the problem it is solving ? You’ve asserted “THIS is not a solved problem,” which suggests everyone is clear on what THIS means. I think that is not a good assumption.
- shevy-java 3mo ago
  But what is the actual problem?
  - duped 3mo ago
    Establishing fast/secure P2P connections between computers.
    - khowells 3mo ago
      Establishing fast/secure P2P connections between ~computers~ *apps. If you want to connect 2 computers use Tailscale. If you want to write an app which offers peer to peer connection for some feature, then use iroh.
      - AndroidKitKat 3mo ago
        By far the most easy to understand explanation of iroh. I still kept thinking to myself "But why not just Tailscale?" when reading the other comments. For me, I find more value in connecting computers together than connecting applications together, but I'm not building P2P apps...
rklaehn 3mo ago
Iroh is QUIC. We are not trying to reinvent the wheel here, just combining existing IETF RFCs in a creative way. Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work. In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth and the lowest possible latency. This was not a solved problem until now.
- handoflixue 3mo ago
  Excuse my ignorance on the subject, but what does this solve that VPNs didn't already address?
  - milkshakes 3mo ago
    vpns typically add at least one hop. this has the possibility of connecting directly via hole punching
    - tux3 3mo ago
      Modern VPNs based on wireguard can do direct connections with hole punching. It's just a lot more work to setup on your own, or you have to sign-up to a SaaS like tailscale and use their relays, and they'll do the hole punching for you. Here this is a decentralized network with a lot of existing public relays. But in principle a VPN can solve a lot of the same problems. It's just that commercial VPNs are not decentralized, and doing your own wireguard setup is a pain.
    - kkapelon 3mo ago
      Already possible with taiscale, netmaker, zerotier etc. https://tailscale.com/blog/how-nat-traversal-works https://tailscale.com/blog/how-nat-traversal-works
      - danudey 3mo ago
        But only for devices already on that tailnet. This allows you to provide information to an arbitrary person (a friend/coworker/etc) to let them access the thing without them having to jump through all the extra hoops of joining your tailnet/them joining yours/adding a VPN/etc.
CommanderData 3mo ago
DNS isn't decentralised it's more federated. I believe Iroh has the option to use DHT here, last I looked at least.
- rklaehn 3mo ago
  Exactly. We use DNS TXT records for our default address lookup system. But we also support fully p2p address lookup via the mainline DHT. And if you have another suitable system, you can also plug it in. E.g. you might want to use another DHT that allows mapping from a key to some address data.
  - alterom 3mo ago
    Do I understand this correctly on a semantic level as "MAC address for the Internet"? (Or, in so many words: an alternative for dynamic DNS without a centralized/hierarchical lookup infrastructure that punches through NATs without all the associated hassle). I.e., the problem is "communicate directly with a node on the Internet by its unique ID". The big question is: what do you solve that Kademlia (BitTorrent) doesn't? Problem history goes like this: * MAC addresses were made to both identify and address nodes on the Ethernet. They're unique and tied to nodes on a hardware level. But they didn't facilitate routing between several Ethernet networks. Linking several Ethernet networks into one big net through an arbitrary topology of hierarchies of routers, with 1980s commodity hardware was a challenge. Without any structure in the MAC address itself, the address alone wasn't telling anything about where it's going to. It is, in fact, not an address at all, as much as it is an identifier . Side note: after writing this sentence, I double checked Wikipedia to make sure I'm not forgetting anything, and lo and behold, IEEE agrees with what I wrote! They're officially called EUIs now (extended unique identifiers), not addresses. Analogy: MAC is like a person's SSN. It doesn't tell anyone about where that person is. You can use it to give mail to the right person when you know the SSNs of everyone in the room. * IP addresses were made to address nodes on the Internet in a simple way. They are actual addresses, semantically, with different parts telling which sub-network to route to. It worked OK when the net was small and relatively static. As the net grew, the fact that IP addresses were not made to identify nodes became a problem. As in: nothing in IP tells you what is attached to that address. And if you are on the net, your IP address may (and often will) change after a reboot. As an analogy: IP is the street address. It's good enough to mail specific people only when everyone lives alone in their own house and doesn't travel. When they do, they have to give you the address of their hotel. If they don't do that, you can't reach them. * DNS was made, in part, to solve that problem (and allow human-readable addresses). But it introduced quite a few others. The list is pretty long, but a few are: * Reliance on the bureaucracy of registrars / centralization (and having to pay a fee for a domain name) * Complex setup * High propagation latency (hours to days) DNS was made to facilitate communication for the client reaching out to a server; centralization is inherent in design choices, as are some assumptions. Like the assumption that the server isn't changing IP addresses too much, and that the people running the server have some control over that. DNS propagation time being a quarter hour to several days long isn't a huge problem with that assumption. You paid for a static IP block anyway to run your site, right? DNS was a step back from the decentralized nature of the Internet, heavily discouraging hosting on your own machines. As an analogy: to make things simpler, you can now send mail to "Pepsico, Inc." without specifying an address at all, because the postal service maintains an address book where anyone can get listed, for a fee. You still have no way to reach your friend after they moved. * Dynamic DNS services only partially addressed this problem, being a bolt-on solution that puts you at the mercy of a dynamic DNS service. Which may or may not be free, and is outside your control. (Self hosting your own dynamic DNS infrastructure is not fun). Analogy: your friend goes out of the way to put "YourFriend, Inc" in the postal service's address book, and make sure to keep their address up to date. * IPv4 addresses eventually introduced another problem which DNS alone doesn't solve. There are too few of them. Hence, NAT. That's to say, an IPv4 failed in doing the one thing it was still doing: addressing. It only became a partial address. In practice, (IP + port number) would be a working address, so with Port Forwarding you could host things on your network-attached computing device. Analogy: the addresses are missing names of the people. As apartment complexes replace single-person homes, the best you can do is specify apartment number along with the address. The postal service ignores it, but the apartment complex management will (hopefully) put your letter into the right mailbox. * This, of course, breaks Dynamic DNS as a solution if the node moves between networks. You're generally not in control of port forwarding. And the port number is not a part of the IP address, so it isn't in DNS.² Analogy: your friend is again unreachable, because they can't include their room number in the address book. They stay in room #80, but it's reserved for the management in most hotels. * IPv6 solved the problem of "not enough IP addresses", but not really. IPv4 and NAT are still there; IPv6 adoption stalled at less than 50% worldwide². Habits die hard. NAT is the poor man's firewall (and some folks love NAT so much, they made NAT for IPv6³). Analogy: USPS rolls out a new address format, where each piece of furniture in each room in every apartment of every building is addressable. Your friend can get their address in that format from their hotel's management when they travel within the US. Usually. In China, they don't do that. * VPNs "solve" the problem by having everyone connect to a central node, at which point it's just like Ethernet. Aside from scale limitations, it's no different from any other client-server architecture; nodes need to communicate via a common third node on the Net. Analogy: the postal service has "return to sender" envelopes that don't require you to fill out the address at all. How it works (and why you can "return to sender", but not mail them directly) is beyond you⁴. You don't know, and you don't care. To communicate, you and your friends simply address all mail to Joe, your mutual friend. On the letter head, you specify the addressee by name. Joe sorts it all out, and puts all mail addressed to you into the "return to sender" envelope. * NAT hole punching is using an intermediary to which both nodes reach to exchange the "return to sender" infusion, then using it while it lasts. Analogy: instead of having Joe forward mail from friends, you all simply write Joe each day, and he sends copies of the other person's "return to sender" envelope in response. Now you have a "return to sender" which goes you your friend (and vice versa), so you can write to each other directly. * Peer-to-peer networks (Kademlia, Gnutella, etc) that emerged in the early 2000s have worked out an entirely different (to DNS) approach to identifying and addressing nodes, generally termed DHT (distributed hash table). Instead of using a centralized/hierarchical/federated lookup table to do (node name, DNS server address) → node address Kademlia introduced a much more sophisticated approach: peer address → peer ID (query ID, peer address) → list of [next peer address] Where d(query ID, next peer ID) < ½d(query ID, peer ID) in XOR metric. This enabled O(long n) lookup convergence. This solves many problems, but in particular, facilitated a distributed key-value store that doesn't rely on hierarchy/federation. The node ID in a Kademlia network stochastically encodes routing information. It's a key-value store where the node ID tells you something about the keys the node can provide value for. Where IP has a rigid structure and reliance on subnet mask hierarchy (the first X bits say something), each Kademlia node is a router which stores information in a flexible (X bits of the address may something, but not any specific ones). In short, Kademlia already solved the "MAC address on the Internet" problem in a decentralized way. * This alone may still leave the problem of NAT hole punching for legacy networks. Reminder, the entire problem amounts to having the nodes reach some other node (for the NAT router to open a port, i.e. create a valid "return to sender" address), and for that node to store/propagate that return address to other nodes. But any node in a decentralized peer-to-peer system can do that. NATs weren't obstacles to Kademlia more than a decade ago (see: libcage⁵). * Iroh offers Kademlia⁶ as an option to retrieve the (Node ID → address) mapping, similar to DNS, and then offers a relay system on top of that for NAT hole punching. QUESTION: What problem does Iroh solve that Kademlia (in particular, libcage implementation) doesn't? My current understanding is that Iroh is just Kademlia with extra steps. Help me out here :) ______ ¹https://www.infoblox.com/blog/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/ https://www.infoblox.com/blog/ipv6-coe/you-thought-there-was... ²https://dnsmadeeasy.com/resources/the-state-of-ipv6-adoption-in-2025-progress-pitfalls-and-pathways-forward https://dnsmadeeasy.com/resources/the-state-of-ipv6-adoption... ³https://serverfault.com/questions/940476/my-dns-record-can-only-point-to-an-ip-address-how-do-i-make-it-reach-for-a-port https://serverfault.com/questions/940476/my-dns-record-can-o... ⁴Turns out, it's simple: hotel management puts their a green sticker on the return address for the mail you send out, so when they get responses with a green sticker, they give them to you. They remove the sticker, so you never know it was there, and they pick colors at random each time — whatever is left in the pile. ⁵https://github.com/ytakano/libcage https://github.com/ytakano/libcage ⁶pkarr uses mainlineDHT, which is a flavor of Kademlia (also used in BitTorrent, among others).
UltraSane 3mo ago
From what I can tell Iroh seems to be trying to create the missing Session layer from the OSI model. Another example of trying to do this is Cisco's Location-Identity Separation Protocol. Lack of a true session layer in TCP/IP is why vmotion is normally only possible in a single broadcast domain because in this situation you only really use mac addresses for addressing and can thus use the IP as a stable identifier when the MAC address changes after a vmotion. And the switch mac address table handles the mapping.
octoberfranklin 3mo ago
DNS is highly centralized. Iroh isn't.
- otabdeveloper4 3mo ago
  DNS isn't centralized at all. The top-level domain registrars are centralized. But you don't need to use them - you're free to use your own TLD's instead of, or even in parallel to, the official ones.
40four 3mo ago
I’ve recently been building some hobby projects that focus on local first, decentralized architecture and that’s how I discovered Iroh. In my apps, I want the user data to be stored local only, no server, and have p2p sync ability. So for something like that, Iroh appears to be the state of the art.
- keepupnow 3mo ago
  local-first, offline-first, no server holding the data and simply p2p sync is a great shout for projects. Have you thought any further about it?

by Thaxll 3mo ago

Arqu 3mo ago

Establishing direct connections on the other hand is a much harder problem with the current internet infrastructure.

huflungdung 3mo ago

[dead]

Kevcmk 3mo ago

I'm not affiliated with Iroh or even using it, but... "IP works just fine". What!? This is _not_ a solved problem

PantaloonFlames 3mo ago
I think that was the question: What is the problem it is solving ? You’ve asserted “THIS is not a solved problem,” which suggests everyone is clear on what THIS means. I think that is not a good assumption.
shevy-java 3mo ago
But what is the actual problem?
- duped 3mo ago
  Establishing fast/secure P2P connections between computers.
  - khowells 3mo ago
    Establishing fast/secure P2P connections between ~computers~ *apps. If you want to connect 2 computers use Tailscale. If you want to write an app which offers peer to peer connection for some feature, then use iroh.
    - AndroidKitKat 3mo ago
      By far the most easy to understand explanation of iroh. I still kept thinking to myself "But why not just Tailscale?" when reading the other comments. For me, I find more value in connecting computers together than connecting applications together, but I'm not building P2P apps...

rklaehn 3mo ago

Iroh is QUIC. We are not trying to reinvent the wheel here, just combining existing IETF RFCs in a creative way. Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work. In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth and the lowest possible latency. This was not a solved problem until now.

handoflixue 3mo ago
Excuse my ignorance on the subject, but what does this solve that VPNs didn't already address?
- milkshakes 3mo ago
  vpns typically add at least one hop. this has the possibility of connecting directly via hole punching
  - tux3 3mo ago
    Modern VPNs based on wireguard can do direct connections with hole punching. It's just a lot more work to setup on your own, or you have to sign-up to a SaaS like tailscale and use their relays, and they'll do the hole punching for you. Here this is a decentralized network with a lot of existing public relays. But in principle a VPN can solve a lot of the same problems. It's just that commercial VPNs are not decentralized, and doing your own wireguard setup is a pain.
  - kkapelon 3mo ago
    Already possible with taiscale, netmaker, zerotier etc. https://tailscale.com/blog/how-nat-traversal-works https://tailscale.com/blog/how-nat-traversal-works
    - danudey 3mo ago
      But only for devices already on that tailnet. This allows you to provide information to an arbitrary person (a friend/coworker/etc) to let them access the thing without them having to jump through all the extra hoops of joining your tailnet/them joining yours/adding a VPN/etc.

CommanderData 3mo ago

DNS isn't decentralised it's more federated. I believe Iroh has the option to use DHT here, last I looked at least.

rklaehn 3mo ago
Exactly. We use DNS TXT records for our default address lookup system. But we also support fully p2p address lookup via the mainline DHT. And if you have another suitable system, you can also plug it in. E.g. you might want to use another DHT that allows mapping from a key to some address data.
- alterom 3mo ago
  Do I understand this correctly on a semantic level as "MAC address for the Internet"? (Or, in so many words: an alternative for dynamic DNS without a centralized/hierarchical lookup infrastructure that punches through NATs without all the associated hassle). I.e., the problem is "communicate directly with a node on the Internet by its unique ID". The big question is: what do you solve that Kademlia (BitTorrent) doesn't? Problem history goes like this: * MAC addresses were made to both identify and address nodes on the Ethernet. They're unique and tied to nodes on a hardware level. But they didn't facilitate routing between several Ethernet networks. Linking several Ethernet networks into one big net through an arbitrary topology of hierarchies of routers, with 1980s commodity hardware was a challenge. Without any structure in the MAC address itself, the address alone wasn't telling anything about where it's going to. It is, in fact, not an address at all, as much as it is an identifier . Side note: after writing this sentence, I double checked Wikipedia to make sure I'm not forgetting anything, and lo and behold, IEEE agrees with what I wrote! They're officially called EUIs now (extended unique identifiers), not addresses. Analogy: MAC is like a person's SSN. It doesn't tell anyone about where that person is. You can use it to give mail to the right person when you know the SSNs of everyone in the room. * IP addresses were made to address nodes on the Internet in a simple way. They are actual addresses, semantically, with different parts telling which sub-network to route to. It worked OK when the net was small and relatively static. As the net grew, the fact that IP addresses were not made to identify nodes became a problem. As in: nothing in IP tells you what is attached to that address. And if you are on the net, your IP address may (and often will) change after a reboot. As an analogy: IP is the street address. It's good enough to mail specific people only when everyone lives alone in their own house and doesn't travel. When they do, they have to give you the address of their hotel. If they don't do that, you can't reach them. * DNS was made, in part, to solve that problem (and allow human-readable addresses). But it introduced quite a few others. The list is pretty long, but a few are: * Reliance on the bureaucracy of registrars / centralization (and having to pay a fee for a domain name) * Complex setup * High propagation latency (hours to days) DNS was made to facilitate communication for the client reaching out to a server; centralization is inherent in design choices, as are some assumptions. Like the assumption that the server isn't changing IP addresses too much, and that the people running the server have some control over that. DNS propagation time being a quarter hour to several days long isn't a huge problem with that assumption. You paid for a static IP block anyway to run your site, right? DNS was a step back from the decentralized nature of the Internet, heavily discouraging hosting on your own machines. As an analogy: to make things simpler, you can now send mail to "Pepsico, Inc." without specifying an address at all, because the postal service maintains an address book where anyone can get listed, for a fee. You still have no way to reach your friend after they moved. * Dynamic DNS services only partially addressed this problem, being a bolt-on solution that puts you at the mercy of a dynamic DNS service. Which may or may not be free, and is outside your control. (Self hosting your own dynamic DNS infrastructure is not fun). Analogy: your friend goes out of the way to put "YourFriend, Inc" in the postal service's address book, and make sure to keep their address up to date. * IPv4 addresses eventually introduced another problem which DNS alone doesn't solve. There are too few of them. Hence, NAT. That's to say, an IPv4 failed in doing the one thing it was still doing: addressing. It only became a partial address. In practice, (IP + port number) would be a working address, so with Port Forwarding you could host things on your network-attached computing device. Analogy: the addresses are missing names of the people. As apartment complexes replace single-person homes, the best you can do is specify apartment number along with the address. The postal service ignores it, but the apartment complex management will (hopefully) put your letter into the right mailbox. * This, of course, breaks Dynamic DNS as a solution if the node moves between networks. You're generally not in control of port forwarding. And the port number is not a part of the IP address, so it isn't in DNS.² Analogy: your friend is again unreachable, because they can't include their room number in the address book. They stay in room #80, but it's reserved for the management in most hotels. * IPv6 solved the problem of "not enough IP addresses", but not really. IPv4 and NAT are still there; IPv6 adoption stalled at less than 50% worldwide². Habits die hard. NAT is the poor man's firewall (and some folks love NAT so much, they made NAT for IPv6³). Analogy: USPS rolls out a new address format, where each piece of furniture in each room in every apartment of every building is addressable. Your friend can get their address in that format from their hotel's management when they travel within the US. Usually. In China, they don't do that. * VPNs "solve" the problem by having everyone connect to a central node, at which point it's just like Ethernet. Aside from scale limitations, it's no different from any other client-server architecture; nodes need to communicate via a common third node on the Net. Analogy: the postal service has "return to sender" envelopes that don't require you to fill out the address at all. How it works (and why you can "return to sender", but not mail them directly) is beyond you⁴. You don't know, and you don't care. To communicate, you and your friends simply address all mail to Joe, your mutual friend. On the letter head, you specify the addressee by name. Joe sorts it all out, and puts all mail addressed to you into the "return to sender" envelope. * NAT hole punching is using an intermediary to which both nodes reach to exchange the "return to sender" infusion, then using it while it lasts. Analogy: instead of having Joe forward mail from friends, you all simply write Joe each day, and he sends copies of the other person's "return to sender" envelope in response. Now you have a "return to sender" which goes you your friend (and vice versa), so you can write to each other directly. * Peer-to-peer networks (Kademlia, Gnutella, etc) that emerged in the early 2000s have worked out an entirely different (to DNS) approach to identifying and addressing nodes, generally termed DHT (distributed hash table). Instead of using a centralized/hierarchical/federated lookup table to do (node name, DNS server address) → node address Kademlia introduced a much more sophisticated approach: peer address → peer ID (query ID, peer address) → list of [next peer address] Where d(query ID, next peer ID) < ½d(query ID, peer ID) in XOR metric. This enabled O(long n) lookup convergence. This solves many problems, but in particular, facilitated a distributed key-value store that doesn't rely on hierarchy/federation. The node ID in a Kademlia network stochastically encodes routing information. It's a key-value store where the node ID tells you something about the keys the node can provide value for. Where IP has a rigid structure and reliance on subnet mask hierarchy (the first X bits say something), each Kademlia node is a router which stores information in a flexible (X bits of the address may something, but not any specific ones). In short, Kademlia already solved the "MAC address on the Internet" problem in a decentralized way. * This alone may still leave the problem of NAT hole punching for legacy networks. Reminder, the entire problem amounts to having the nodes reach some other node (for the NAT router to open a port, i.e. create a valid "return to sender" address), and for that node to store/propagate that return address to other nodes. But any node in a decentralized peer-to-peer system can do that. NATs weren't obstacles to Kademlia more than a decade ago (see: libcage⁵). * Iroh offers Kademlia⁶ as an option to retrieve the (Node ID → address) mapping, similar to DNS, and then offers a relay system on top of that for NAT hole punching. QUESTION: What problem does Iroh solve that Kademlia (in particular, libcage implementation) doesn't? My current understanding is that Iroh is just Kademlia with extra steps. Help me out here :) ______ ¹https://www.infoblox.com/blog/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/ https://www.infoblox.com/blog/ipv6-coe/you-thought-there-was... ²https://dnsmadeeasy.com/resources/the-state-of-ipv6-adoption-in-2025-progress-pitfalls-and-pathways-forward https://dnsmadeeasy.com/resources/the-state-of-ipv6-adoption... ³https://serverfault.com/questions/940476/my-dns-record-can-only-point-to-an-ip-address-how-do-i-make-it-reach-for-a-port https://serverfault.com/questions/940476/my-dns-record-can-o... ⁴Turns out, it's simple: hotel management puts their a green sticker on the return address for the mail you send out, so when they get responses with a green sticker, they give them to you. They remove the sticker, so you never know it was there, and they pick colors at random each time — whatever is left in the pile. ⁵https://github.com/ytakano/libcage https://github.com/ytakano/libcage ⁶pkarr uses mainlineDHT, which is a flavor of Kademlia (also used in BitTorrent, among others).

UltraSane 3mo ago

From what I can tell Iroh seems to be trying to create the missing Session layer from the OSI model. Another example of trying to do this is Cisco's Location-Identity Separation Protocol. Lack of a true session layer in TCP/IP is why vmotion is normally only possible in a single broadcast domain because in this situation you only really use mac addresses for addressing and can thus use the IP as a stable identifier when the MAC address changes after a vmotion. And the switch mac address table handles the mapping.

octoberfranklin 3mo ago

DNS is highly centralized. Iroh isn't.

otabdeveloper4 3mo ago
DNS isn't centralized at all. The top-level domain registrars are centralized. But you don't need to use them - you're free to use your own TLD's instead of, or even in parallel to, the official ones.

40four 3mo ago

I’ve recently been building some hobby projects that focus on local first, decentralized architecture and that’s how I discovered Iroh. In my apps, I want the user data to be stored local only, no server, and have p2p sync ability. So for something like that, Iroh appears to be the state of the art.

keepupnow 3mo ago
local-first, offline-first, no server holding the data and simply p2p sync is a great shout for projects. Have you thought any further about it?