Rendered at 08:50:29 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
apitman 12 hours ago [-]
If you're new to Iroh, my mental model is roughly "Tailscale at the application layer instead of the network layer".
If your question is, "why not just use Tailscale?", look at it from an app developer's perspective. If you want to release an app and have instances of your app be able to easily connect to each other, you could theoretically embeded Tailscale functionality into your app, but then the users of your app need Tailscale accounts, and your app is dependent on Tailscale.
Iroh lets you embed this functionality directly, and provides public fallback relays. If your app gets too big for the public relays, using your own relays is the flip of a switch.
samrus 3 hours ago [-]
Its amazing to me how people can make a great a product. And then completely bury the lead because they are so deep into the guts of the system
You explained the value proposition so well. The website just didnt get to the "why?" At all
nicce 57 minutes ago [-]
On the other hand, parent commenter's comparison is based on another product. How good it is if people don't know what Tailscale is? There was a time I did not understand Tailscale and its value.
colinmarc 2 hours ago [-]
It's primarily an open source library, not a product.
I don't understand why HN seems so concerned about nailing down its "value proposition".
jasode 27 minutes ago [-]
>I don't understand why HN seems so concerned about nailing down its "value proposition".
You're getting sidetracked because of the particular phrase "value proposition" but a lot of people just use it as a stock phrase to simply understand something even without any commercial product perspective.
You can read through this entire thread where people are having a hard time wrapping their head around what _it_ _is_ because the blog article doesn't explain it well.
The following various stock phrases use different words but are basically asking the same thing:
- "This is the solution to what problem?"
- "How's this different from Tailscale/Wireguard/QUIC/etc?"
- "What is the raison d'être ?"
- "ELI5?"
- "What's the value proposition?"
- "Why should I care about this?"
- "What's the use case for this?"
- "What's the motivation / rationale for this?"
- "What does this do?"
And then different commenters try different explanations and hopefully one will finally click for readers.
meowkit 1 hours ago [-]
I mean this kindly, but this is so “engineer brained”
Maybe the game has changed with LLMs, but its been a running joke that engineers will build a startup/product/library/thing only to then realize they can’t get any users and that marketing and sales are hard.
Attention and mind share are more valuable than ever. If you can’t answer “Why should I care about X?” then you are fighting an uphill battle.
colinmarc 1 hours ago [-]
> Maybe the game has changed with LLMs, but its been a running joke that engineers will build a startup/product/library/thing only to then realize they can’t get any users and that marketing and sales are hard.
I agree with your premise, but you're still viewing this technology through the lens of "a successful product" versus "a successful piece of technology".
Plenty of open source projects stay open source and are popular without ever making any sales whatsoever. I'm not trying to project my own motivations on the Iroh team; they may want to build a product out of it. For me, though, the project has a lot of appeal already, because it exactly and excellently fulfills a technological need, not because they brought me in with a "it's x but for y" narrative.
waynesonfire 3 hours ago [-]
Why? Because if you need to serve ads that are being blacklisted by DNS, you need something like this.
grumbel 2 hours ago [-]
That explanation still seems overly complicated. Iroh isn't a VPN. Iroh just lets apps connect to each other, just like plain old TCP, but without the shackles of NAT, DNS and dynamic IP addresses that made that impossible. It's restoring simple P2P connectivity to the Internet.
worldsayshi 2 hours ago [-]
Also, all connections in iroh are end-to-end encrypted.
evnc 9 hours ago [-]
Oh, okay, I get the value prop now. Thank you. They should hire you to write their marketing copy, you did a better job than the landing page.
bicepjai 12 hours ago [-]
I understood more about what iroh does with this post then the video :) thanks for the mental model. Now how does iroh accomplish this. Great idea by the way.
I think it's more similar to the idea of IPFS than Tailscale. It's excellent for example for decentralized networks where there is missing trust; file sharing, bittorrent, blockchain networks etc, where you don't want to manage the complexity of dropping IP addresses at the application layer. I initially found it for parture.org for example.
michaelsalim 10 hours ago [-]
This is exactly it. I'm pretty sure I found Iroh after thinking: can we ship Tailscale with our app?
For environments where you want people to access your local instance, I believe Iroh will be a game changer. For us, it's to allow control over our software through phones and other devices easily.
Previously, you might have to make sure they're in the same LAN network. But with Iroh, anything works.
evilturnip 4 hours ago [-]
Ok, stupid question, but what applications is something like tailscale/iroh used for? I've never worked with this type of tech so curious where it is valuable.
inapis 3 hours ago [-]
With tailscale, you can establish a private LAN over the internet. Iroh embeds this directly into the app itself.
thejazzman 9 hours ago [-]
also to follow on the "why not use tailscale" should be because they're a business who seeks to make money and we are fools to keep concentrating distributed technology to a handful of centralized owners (!)
especially when iroh makes it so easy and awesome to do it right.
rmunn 6 hours ago [-]
So instead of paying a subscription fee to Tailscale to support your distributed application, you pay a subscription fee to Iroh to support your distributed application. (https://www.iroh.computer/pricing says $19/month for what most people will want to use it for).
Either one will allow you to stop "concentrating distributed technology to a handful of centralized owners", but the "why not use tailscale" part of what you're trying to say is not at all evident from your comment.
flub 1 hours ago [-]
iroh is fully open source though, you can run your own relay server and not have any dependencies on number0
5 hours ago [-]
gz5 11 hours ago [-]
the closest comparison is openziti:
+ iroh and openziti can both be app-embedded
+ so the app developer embedding in their service is a good use case for both
+ openziti is used for services in which scale and security are critical
+ whereas iroh allows participation from parties which don't have any prior relationships - which can be very convenient
embedding-shape 11 hours ago [-]
> the closest comparison is openziti:
Except without all the ceremony about setting up daemons, servers, controllers, "networks" and what not that openziti seems to have. Iroh is more "define protocol and hook two clients together" with everything in one binary.
yes, openziti includes a full mesh, programmable overlay. agree not all apps need that.
piokoch 1 hours ago [-]
Still I am not sure why I should use their paid service instead of using publicly available infrastructure. If they go out of business, get sold what's then? DNS and friends are not going to disappear and send me "it was great journey" e-mail. Maybe for some specific applications, like P2P chats, this makes sens, but how many of such applications are needed?
I've looked at the usecases page, obviously there is an AI stunt (which I don't buy at all), for POS applications, well, there are better and less risky (see above) ways to do this, so the only thing that seems to make sense is this real-time sync, if someone is in the restricted environment (but, the point is, that in the restricted environment iroh is going to be blocked anyway by firewalls, z-scaler, etc.).
Bnjoroge 6 hours ago [-]
They should basically replace any Why Iroh vs Tailscale with this. Thank you
waynesonfire 4 hours ago [-]
why isn't your mental model to use DNS?
mkl 15 minutes ago [-]
How will that help your computer behind your NAT communicate with my computer behind my NAT? (I think you're still stuck on the blog post's very confusing opening, which does indeed make it sound like a terrible alternative to DNS, but it's actually something entirely different, for an entirely different purpose.)
cwillu 4 hours ago [-]
DNS is piece of the required kit, and not the only hard part of the task.
sethops1 8 hours ago [-]
that landing page is confusing, they should delete their text and replace it with yours
holmesworcester 10 hours ago [-]
[dead]
rklaehn 17 hours ago [-]
I am one of the iroh developers.
A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ...
Iroh as of now supports only IPv4, IPv6 and relay transports out of the box. There is such a large variety of potentially interesting transports out there that we can't support all of them without turning the codebase into an unmaintainable maze of feature flags.
But we have added the ability to implement custom transports. That way your transport implementation can live in a completely separate crate.
Hey, just reading through the docs, this looks like a pretty cool project and I found your p2p chat example[0]
I'm trying to understand it's limitations, if I used this to build a p2p client / server setup or even two peer machines, what else do I need to setup to be able to have connections between the two applications?
For example, could I create an application that runs on my phone and another that runs on my laptop and finally get a direct secured working connection between the two of them? Or is this solving a different problem? =)
Yes, you will get secure direct connections. This matters for privacy in case of an encrypted chat, but also has a lot of benefits for more demanding use cases such as video streaming.
If you use the default setup you are still depending on a tiny bit of cloud infrastructure such as our public relays to faciliate the hole punching. However, we also have optional local discovery using e.g. mDNS.
apitman 12 hours ago [-]
You'll get a direct connection in most cases, but sometimes it will need to fall back to relays. n0 provides free relays, but ultimately that can get rather expensive. You can also run your own relays for your app.
syllogistic 8 hours ago [-]
> when will iroh support webrtc...
This would give you a native iroh node that also speaks webrtc but I find that what folks want is for browsers to participate as peers.
I build p2claw, p2p for self-hosted web apps, and ended up doing both halves separately. Box to box is iroh, although I use my own coordinator service and run my own iroh relay. Browser to box is webrtc with a service worker that makes the browser act like a peer. The worker grabs fetches and sends them as HTTP frames over the data channel, the box answers on localhost. The browser bit has to be webrtc because it's the only browser api does ICE.
Wiring up the iroh half went smoothly, very much enjoying working with the library. Congrats on 1.0!
samantp 7 hours ago [-]
Yes, seems that browser support for services running on P2P boxes behind NATs cannot leverage iroh. Need the service worker hijacking the browser’s fetches as well as monkey patching the browser’s websocket SDK and sending all that traffic over webrtc data channels.
apitman 4 hours ago [-]
I discovered p2claw the other day and it's really cool. I'm a little surprised you're running Iroh as well. Why not just use WebRTC for everything once you're forced to for the browser anyway?
syllogistic 4 hours ago [-]
[dead]
mhluongo 15 hours ago [-]
Hi! As someone who has historically built on libp2p, I'd love to see an updated comparison focused on app developers!
Last year, I was trying to choose between the two and went with that I know... but it feels like there's real momentum on Iroh's side.
Bender 17 hours ago [-]
What are the risks if any of running public relays? Is this similar in concept to running Tor Guard Nodes / Relays?
rklaehn 17 hours ago [-]
If you run a public unauthenticated relay you act as a home relay for whoever has your relay configured in their relay map and is close in terms of latency.
So you might get a lot of traffic. You can configure rate limiting, as we do on our public relays.
The traffic is fully encrypted and can not be decrypted by the relay. The only information the relay has is what is necessary for it to function - the endpoint id and ip addresses of the endpoints that are connected to it at any given time, as well as endpoint pairings.
You relay encrypted traffic with no egress to the open internet. So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
Bender 17 hours ago [-]
So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
Nice. I already do rate limiting, traffic balancing using sch cake. This looks like an interesting project. I could envision open source NVR's implementing this. I also like the name of the project.
Arqu 17 hours ago [-]
All the data is e2e encrypted and nothing is stored. The usual self hosting public things rules apply.
Yes, I wrote the current tor transport as a quick demo/testground for custom transports.
Arguably directly embedding the rust tor implementation would be more useful for the typical iroh user that wants an embeddable library. I just did not get to it yet.
Nice. How easily is the protocol categorized by an external observer? I'm noticing protocols like wireguard more commonly hitting problems as websites rely on third party systems to protect them from non-human interactions.
matheus23 51 minutes ago [-]
Somewhat easy, unfortunately.
If you look at Wireguard traffic, you'll see a <EndpointID>.iroh.invalid SNI in the QUIC Initial packet.
Encrypted ClientHello can fix that, but support hasn't shipped into rustls yet. So it's definitely fixable.
The interesting thing is that the ClientHello is undetectable when it's sent via the relay transport (sent inside a WSS connection). And in that case, any traffic that happens on IP is fully encrypted and can't be categorized.
refulgentis 17 hours ago [-]
FWIW I think for “new user” audiences you’re better off describing why we’d use this instead of IP, than why you haven’t gotten it everywhere yet: there’s a certain sort of “complaint I see the most from current users” myopia that sets in, at least for me, over the years. :)
Can the relay servers, when used as fallback, read the data between two parties by providing its own public key to both of the peers?
matheus23 27 minutes ago [-]
You need to know the public key you communicate with ahead of connecting to the correct relay. It needs to be shared securely out-of-band, relays don't help with that.
khowells 6 hours ago [-]
As I understand it the “peer ID” you dial acts like the public key, of the public/private key pair. So the public key doesn’t come from the relay. You need to do the initial public key/ID exchange out of band, and then dial the connection to each other via the relay.
So the relay is never in a position to send you the wrong public key, because it doesn’t give it to you in the first place.
flub 54 minutes ago [-]
Iroh uses QUIC connections and uses the EndpointId, the public ed25519 key, in the TLS handshake for authentication. This makes it impossible for a server to try and machine-in-the-middle the connection.
rklaehn 14 hours ago [-]
No. The data in each direction is encrypted by TLS, using ephemeral keys.
Only the owner of the corresponding private key can initiate a connection from their public key, or receive a connection attempt to their public key.
Let's say you have alice and bob talking via a relay. Even if you have the private key of alice, you can impersonate alice to bob, but not vice versa. So you can't initiate a connection between the two.
To really intercept data you would need the private keys of both participants.
SillyUsername 15 hours ago [-]
You may want to consider using a feature flag API if you think it will be unmaintainable.
Strategy patterns and code-centralised feature management ftw :)
I am not aware of a LoRa custom transport yet, but that is not unexpected given that the custom transport API is relatively new, and our main focus has been on getting iroh 1.0 out of the door.
larodi 15 hours ago [-]
Definitely interesting in having lots of things running lora AND meshes. Thanks.
ascii0eks84 16 hours ago [-]
If you don't mind, what are other low-effort but high signal forums other than HN, Perplexity and X for accurate news that skip the annoying part?
andrewflnr 13 hours ago [-]
> Dial keys
Maybe it's in the video I didn't watch, but I really think paragraph one should make clear what kind of keys and why. Cryptographic? Asymmetric? How do they do the job, at even the most basic level? It never explains, just dives into abstract claims of superiority and usage stats. I gather relays are involved; this would be a good thing to mention right away instead of making me sift it from the HN discussion.
morphism 13 hours ago [-]
While the frontpage doesn't go in depth, the docs quickly do:
First with https://docs.iroh.computer/what-is-iroh and then following up with the how it works section. The docs are actually good from what I can see so far. From what questions you brought up so for it seems to answer them pretty quickly.
sva_ 12 hours ago [-]
The doc still doesn't show what such a 'key' looks like? Why can't there be a simple infographic that goes like
It seems to use DHT under the hood whether directly or through a relay. https://pkdns.net/ .
andrewflnr 10 hours ago [-]
They mention later on it's an Ed25519 key.
12 hours ago [-]
12 hours ago [-]
andrewflnr 10 hours ago [-]
I'd quibble with "quickly", but sure, this seems like the starting point for figuring out how it works: https://docs.iroh.computer/concepts/endpoints From a marketing standpoint, for a technical audience, I think it should be quicker.
isodev 12 hours ago [-]
I saw the video and still have no idea what they are. Also, “never locked in” but then “pricing” and why is one paying for “apps” but self hosting relays?
spencerflem 12 hours ago [-]
As I understand it- you can use free community provided relays, self-host your own, or pay for their managed services with an SLA and monitoring built in
dotancohen 12 hours ago [-]
> Dial keys. Not IPs.
> It's a simple idea really, and it's the right abstraction for the future of the internet. IP addresses can break, without warning, and it's outside of your device's control. Keys, however, are created & controlled by you. They stay the same as your device moves, and are yours to throw away, or not. IP addresses can be private and inaccessible behind firewalls, but with iroh your device can be securely addressable no matter where it is.
To me that just sounds like a reimplementation of DNS. Maybe decentralised and maybe free and maybe not monomeric, but broadly the same.
Folcon 12 hours ago [-]
The biggest difference that I can see is that keys are not making any claims about ownership, there's no global registry and it's p2p, which is a big upside
ben-schaaf 4 hours ago [-]
DNS doesn't work with constantly changing IPs, like you have on mobile networks. DNS also doesn't help when the IP is behind a NAT. So I really don't see how the two are similar at all.
4 hours ago [-]
bellowsgulch 9 hours ago [-]
No idea why this is downvoted, it's exactly the pitch for DNS. Others and I are asking the same question. There's no value proposition here.
comboy 6 hours ago [-]
Different network layer, no centralization, no authorities, DNS has nothing to do with making p2p connections, it's like the ballpark is not even in the same country
taf2 13 hours ago [-]
when i read "keys" i figured "names" like in my .ssh/config a named host that i access with a key... but listening more it sounds like a new way to do networking over QUIC...
rklaehn 1 hours ago [-]
At the lowest level it is a creative way to leverage all the work the major cloud vendors have poured into QUIC for p2p connections.
If you look at an iroh connection in wireshark it is just a QUIC connection. If you configure a SSLKEYLOGFILE so wireshark can actually look into the packets, you will see a few TLS extensions and somewhat unusual packets flying by during the handshake, but once established it is a completely normal QUIC connection.
That is also why we are relatively confident regarding encryption security. It is just TLS. And we can also leverage new encryption like post quantum key exchange with just a few config changes, without any code changes.
One thing that is genuinely novel is that we use QUIC multipath to keep the different paths (relay, various direct IP paths) separate. This has some technical benefits because the congestion controller does not get irritated when the underlying transport changes. Each transport has its own congestion controller.
spencerflem 12 hours ago [-]
Having spent a while trying to understand it, I believe the keys are serving a dual purpose as an encryption key and as a stable identifier along the lines of a session cookie that might be used for a WebRTC video call.
Here's my summary from Lobste.rs, keeping in mind I'm not an expert and only found this project today:
> [..] this is closer to an opinionated WebRTC setup that handles assigning a persistent ID to clients. All the work of making a signaling server is taken care of and the solution is generic enough and cheap enough to run that you can get away with using a community hosted one. Kinda similar to what you get with Steam’s proprietary p2p gamenetworkingsocket infrastructure
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.
rklaehn 16 hours 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.
kkapelon 16 hours ago [-]
isn't this exactly what tailscale (and also zerotier, netmaker) do?
That only works for the infrastructure of one entity. It doesn't establish direct connection to my friend's device by a key pair if he is outside of the particular organisation tailscale VPN.
p2p apps need direct connections.
moritzruth 16 hours ago [-]
Those are intended to solve the problem at the OS layer, while Iroh (being a library) does it at the application layer.
From reading that, it lets you establish connections within your tailscale vpn. Iroh let's you establish connections between devices regardless of their network.
9dev 14 hours ago [-]
There might be a misunderstanding of what Tailscale offers here. There is no "VPN" in the classic "virtual network" way. With Tailscale, you can - as with Iroh, IIUC - connect arbitrary nodes to each other, where a node can be a device or an application (via tsnet). All nodes get CGNAT IPs and an addressable hostname, so there is one giant "network" of all your nodes with automatic DNS resolution baked in.
kbenson 14 hours ago [-]
Doesn't tailscale require those all be administered and approved by one account?
> there is one giant "network" of all your nodes
From what I understand they're saying, the point is that you get easy connections to things that aren't "your" nodes, sort of like allowing me to connect one of my tailscale nodes ad-hoc to one of your tailscale nodes, when our accounts are not related in any way prior to us doing that, and without me having to allow your node onto my network or you allow one of mine onto your network and have to deal with the specialized ACLs for that, since it's just a direct connection between two nodes.
9dev 13 hours ago [-]
Yeah, I figured that in the mean time. It just didn’t occur to me because my use case is literally the opposite—having a secure company network where strict ACLs are the core value, not a nuisance. But if easy ad-hoc connections are your goal, Iroh sure looks like the better choice then.
__float 15 hours ago [-]
I think everyone in this thread agrees on that part already.
The similarities are in an application lib to connect, and that tail net IPs correspond to device keys like in Iroh. The service using the Go library has its own Tailscale identity.
apitman 12 hours ago [-]
Similar on the technical level (though QUIC vs WireGuard), but that would make your app dependent on Tailscale, and require your users to have Tailscale accounts. You'd also be limited to Golang currently.
In theory you could run Headscale, but you're really working against Tailscale's intended design at that point, and Iroh was built for this from the ground up, so what is Tailscale buying you?
szmarczak 12 hours ago [-]
You don't need tailscale accounts to access tsnet (via funnel).
handoflixue 16 hours ago [-]
Excuse my ignorance on the subject, but what does this solve that VPNs didn't already address?
gslepak 16 hours ago [-]
VPNs do not allow you to connect two devices directly, they have to go through the VPN. They also do not allow you to connect devices that are not on the VPN. Iroh does P2P connections and punches holes through NATs when needed, so you can connect directly to devices on different networks that are behind firewalls.
combyn8tor 11 hours ago [-]
> VPNs do not allow you to connect two devices directly, they have to go through the VPN
Not true. Depends on the VPN protocol.
TalkingCodeMonk 8 hours ago [-]
It sounds like the key difference people are missing is that VPN's operate at the network layer, so they require separate integrations for every device os/arch and network stack, where Iroh is embedded at the application layer, so any app can be a P2P VPN client without worrying about device network integrations.
Sounds great to me, and would be a boon for self-hosting and decentralization in general, which is sorely needed considering how captured, authoritarian, and anti civil liberties every democracy is becoming. If I'm not mistaken, I believe I read a tailscale blog about them envisioning application layer embedding at some point as well.
pkulak 16 hours ago [-]
From my VERY brief understanding: this is like if you want the hole-punching of a VPN, but your stuff is public, so not only do you not want all the security of a VPN, but it works against you. But I'm happy to be corrected!
Arqu 14 hours ago [-]
You don't have to have it public. You can have your app gate against any auth method you like to implement on top. And you can have private relays to segregate your traffic and discovery depending on setup.
milkshakes 16 hours ago [-]
vpns typically add at least one hop. this has the possibility of connecting directly via hole punching
tux3 16 hours 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 16 hours ago [-]
Already possible with taiscale, netmaker, zerotier etc.
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.
9dev 14 hours ago [-]
With Tailscale at least, you can pretty easily share a node with someone else. If your target audience are solo developers or hobbyists, making it even easier to share access is surely nice; from the perspective of someone in charge of making sure our company IT is balancing security and ease of networking, the literal last thing I want is making it easier to grant someone access.
There are policies defining who can talk to what; they are deployed from a GitHub repository with defined rules on who can modify them and who has to review them; there are zero scenarios where I want an alternative way of granting access to any device or service under our control.
kkapelon 15 hours ago [-]
but what exactly is the use case? I was responding to the nat traversal topic..
If I wanted to share something internal with a friend I would use ngrok or any of the million alternatives.
Anyway, this is exactly why my top-level comment says that this project needs a "versus" page in the docs.
UltraSane 15 hours ago [-]
Cisco Dynamic Multipoint VPN will start by connecting to a central VPN server and then learn the public IPs of endpoints and automatically create VPN tunnels to them. It can scale to thousands of endpoints.
opem 14 hours ago [-]
So iroh is basically WebRTC, except it works in and outside of a browser. Relays seems quite similar to TURN/STUN servers except they also handle fallback traffic much like TOR guard/relay nodes
syllogistic 7 hours ago [-]
It's backwards! Unlike webrtc, iroh doesn't work inside a browser. It's for the case where you have two native apps that need to talk to each other p2p.
For browser / webapps you want webrtc.
ben-schaaf 4 hours ago [-]
> We built & continually check that iroh can compile to WASM & run in the browser
Sean-Der 14 hours ago [-]
Does WebRTC not work inside/outside of the browser anywhere?
nunobrito 13 hours ago [-]
It works outside the browser too, I've been using it that way.
opem 13 hours ago [-]
Yes it does! I was trying to draw an analogy there, I think it would be better to state as - iroh is similar to WebRTC + PeerJS[1] which only works on browsers, generally[2].
[1]: PeerJS(https://peerjs.com/) is a library to use WebRTC w/o any boilerplate code.
[2]: WebRTC functionality can be enabled in non-browser envs like Node.js by using third-party native addons (like node-webrtc) that provide bindings to the underlying C++ WebRTC library.
aliasxneo 16 hours ago [-]
Is that not what libp2p already offers? Not sure if it has QUIC out of the box, but hole-punching to UDP connectivity and then running QUIC over it isn't that hard.
karissa 16 hours ago [-]
The folks who made iroh worked on libp2p first, but found many limitations in libp2p's design. iroh is a better more flexible and powerful version of libp2p
orthecreedence 16 hours ago [-]
Libp2p does have quic, at least the rust implementation.
rklaehn 16 hours ago [-]
libp2p does have QUIC, but it is one of many possible transports.
So libp2p builds many things on top of the underlying transport where we use QUIC directly and use existing mechanisms such as TLS ALPNs for protocol negotiation.
We also use the stream multiplexing that is built into QUIC instead of putting a stream multiplexer on top of QUIC.
You can think about it like this: libp2p abstracts transports as streams, and then puts many required features on top (protocol negotiation, stream multiplexing)
Iroh uses QUIC and abstracts transports below QUIC. We can work with any unreliable datagram transport that has (or can be hacked to have) a minimum MTU of 1200 bytes (needed to be QUIC compliant).
ianopolous 15 hours ago [-]
Minor clarifications, but libp2p also uses TLS ALPN for protocol negotiation, and also uses native quic streams - there is no additional muxer layer when using quic.
Iroh is still awesome.
dignifiedquire 16 hours ago [-]
Yes, but libp2p was mainly designed around the limitations of tcp, as quic simply wasn't there yet when the design started. Iroh gets the benefit of having been designed and built from the ground up, based on quic.
dannyobrien 14 hours ago [-]
would it possible to have iroh as a libp2p pluggable transport? So you could dial a iroh node with /iroh/proxy/ed25519key?
It doesn't seem to do anything when you click Run Live, besides updating the status to "Connecting to DERP relay, exchanging endpoint info..."
johndevor 8 hours ago [-]
You can get it to run by hitting "Edit" at the top - needs a real dev container to run, not a web worker.
bicepjai 12 hours ago [-]
So iroh.network is something that they maintain like tor or vpn ?
kfarr 14 hours ago [-]
Classic... want to cast to the chromecast but I'm on the wifi
ElijahLynn 9 hours ago [-]
This might be the ~next~ best example, and the one that Iroh should lead with in all of their marketing materials and videos!
They really need to dumb this down to make it accessible if it's going to spread.
BetterThanSober 3 hours ago [-]
The chromecast should be running iroh, no?
1vuio0pswjnm7 5 hours ago [-]
"This was not a solved problem until now."
system2 16 hours ago [-]
Is bypassing the router a good idea?
Arqu 15 hours ago [-]
Yes if you want to. Routers are a necessary abstraction from the IPv4 days and seems it will stick around for a long time, and we need solutions sometimes around those topologies.
rpcope1 15 hours ago [-]
Are you conflating a router with SNAT? Routers as in L3 routing are not an "IPv4 only abstraction."
Arqu 15 hours ago [-]
Yes I used it in place of NAT for most casual users at home, which is presumably what the user above originally meant.
Kevcmk 17 hours ago [-]
I'm not affiliated with Iroh or even using it, but... "IP works just fine". What!? This is _not_ a solved problem
PantaloonFlames 16 hours 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 15 hours ago [-]
But what is the actual problem?
duped 14 hours ago [-]
Establishing fast/secure P2P connections between computers.
khowells 6 hours 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.
Arqu 17 hours ago [-]
Establishing direct connections on the other hand is a much harder problem with the current internet infrastructure.
CommanderData 16 hours 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 16 hours 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 9 hours 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.
⁴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.
⁶pkarr uses mainlineDHT, which is a flavor of Kademlia (also used in BitTorrent, among others).
metaketa 2 hours ago [-]
this is a VERY good writeup of all problems in the stack chronologically that must have cost you time. Thank you for this!
hamjamnam 7 hours ago [-]
[dead]
octoberfranklin 14 hours ago [-]
DNS is highly centralized. Iroh isn't.
otabdeveloper4 2 hours 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.
UltraSane 15 hours 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.
huflungdung 17 hours ago [-]
[dead]
coldblues 14 hours ago [-]
The future of networking is decentralization. I'm a huge fan of Yggdrasil and I2P. We should just be able to buy a mini PC to run 24/7 and host whatever it is that we need on it and seamlessly connect to others. A lot of techies already have older spare machines laying around collecting dust that can become servers. It is far cheaper in the long run and easier to maintain than having to deal with domains and server hosting. I truly appreciate the work that the Iroh team puts out.
tootie 13 hours ago [-]
It's been the future for at least 20 years now.
coldblues 12 hours ago [-]
This post may be sarcastic, but some of us really have been living in the future so to speak, more than others. It's the nature of novel, groundbreaking tech. Adoption is not immediate.
z3ratul163071 4 hours ago [-]
[dead]
logankeenan 17 hours ago [-]
Iroh has been amazing to work with and the engineers are so nice in the discord channel. The pragmatic approach to making p2p just work has been easy to understand. Their YouTube channel has great content too. Congrats on v1!
Doesn't it seem odd to have "Pricing" for a protocol that's meant to serve a similar function to IP addresses? Maybe I'm misunderstanding something.
dignifiedquire 17 hours ago [-]
As others have already mentioned, iroh the core library and protocol is fully open source. But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.
embedding-shape 17 hours ago [-]
Congrats for the launch, seems to have matured a bunch and Iroh gotten a bunch of neat additions since I last looked! You even managed to get 1.0 out the door before go-ipfs / Kubo ;)
> But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.
Interesting (and somewhat proven) idea to finance it, smart :)
Did you guys started doing this already on a case-by-case basis and have some experience of it already, and if so what are the common things you typically help out with exactly? I'm just curious what sort of things a company who'd use a protocol like that might need help with, that they wouldn't have experience with in-house, since they're going down a P2P road already (assuming that, maybe maybe need help with greenfield projects)?
I think it would be clearer if you put the "Pricing" navbar link under "Services."
noworriesnate 16 hours ago [-]
I don't mind paying for a subscription, as long as I'm not also paying for the privilege of being locked in to a specific vendor. If I pay for a subscription and then your prices quadruple or something, what are my options? Can I self-host a relay? Do I lose features if I do so?
moritzruth 16 hours ago [-]
I'm not affiliated. From what I understand, they provide an open-source implementation of the relay server: https://github.com/n0-computer/iroh/tree/main/iroh-relay (which may or may not be what they actually run as part of their hosted offering).
If you use their offering, you probably get some kind of web interface for metrics that isn't open-source.
karissa 16 hours ago [-]
Correct
karissa 16 hours ago [-]
Yes you can self-host your relays. Forever! Please check out the docs & hosting pages more information:
"we want to be infrastructure for people, and a business towards professionals."
stuck between "we need cash to operate" and "we want to be a public good infrastructural system." , with the negative parts of a for-profit whisked away with "Well it's open source."
it's a business concept i'm okayish with as long as the "Well it's open source." caveat doesn't come with a total bespoke and unusable code base to figure out.
rklaehn 16 hours ago [-]
Take a look yourself.
Our code is as good as we can make it, and everything is modular and well documented. For example our QUIC implementation noq which underlies every iroh connection can also be used as a standalone QUIC impl that implements QUIC multipath.
If we wanted to have "total bespoke and unusable code" we would have inlined all of this into the iroh repo to make it unusable.
colinmarc 16 hours ago [-]
Not affiliated, but I am a very happy user of Tailscale and a very happy user of Iroh; we use the latter in production at work.
Tailscale is a great service that happens to be open source, but Iroh is clearly structured as a library that you can build into whatever you want.
PLG88 16 hours ago [-]
fwiw, Tailscale happens to be mostly open source, not completely. Yes, I know Headscale exists, it does not implement all the Tailscale functions (not non-functional production type capabilities)
w4der 15 hours ago [-]
RustDesk has a similar business model and works fine for what it is, is there something particular about TailScale and Iroh that makes you think it will not work?
Kinrany 17 hours ago [-]
From the same pricing page, it's all additional services: observability, relay hosting, support engineers.
TheDong 17 hours ago [-]
The equivalent for IP addresses to what they offer would be closer to running a BGP router or ISP, or generally contracting with network engineers for your data-center's networking.
If you want to run an ISP or AS, believe me it will cost you a decent chunk of money.
icedchai 15 hours ago [-]
I've been running my own AS for years. You can get an ASN and IPv6 from a RIPE LIR for $200/year or less. Then you need a couple of VPSes that are BGP capable. You can get those for $20 month. Then you can tunnel traffic back to your location with a Wireguard tunnel or whatever you prefer. It's relatively cheap! I also have a legacy IPv4 block I'm routing, which doesn't cost me anything.
apitman 4 hours ago [-]
Is there no annual fee on all IPv4 blocks, or just legacy ones, which I'm assuming means blocks that haven't changed hands in a very long time?
adammarples 17 hours ago [-]
Maybe. It's offering "Customized hosting and monitoring for Iroh apps".
wngr 2 hours ago [-]
Kudos to the n0 team shipping 1.0! Truly exciting, stellar technical approach and execution; I hope you guys will get sufficient commercial traction to keep going!
arilotter 15 hours ago [-]
My company was using Iroh for a production distributed ML training system & we LOVED it. The team was incredibly responsive even before we hooked up with an enterprise support contract, they're incredibly knowledgeable and the library itself worked amazingly. ++ to this lib. would use again over libp2p anytime.
rklaehn 15 hours ago [-]
thank you!
colinmarc 16 hours ago [-]
We use Iroh in production at work, and I'm absolutely in love with it. I'd describe it primarily as "Tailscale-style hole punching as a rust crate", but of course you can sprinkle a lot of cool p2p stuff on top of the basic QUIC connections.
16 hours ago [-]
dignifiedquire 15 hours ago [-]
thank you!
miki123211 14 hours ago [-]
I like the idea. A couple of questions:
1. How does Iroh handle key rotation / leakage? Could you build some kind of hot/cold system on top of it, where you'd have a cold "identity key" in airgapped, secure storage, used only to issue certificates for your hot "traffic acceptance" key?
2. Is there any kind of peer discovery / DHT, either built-in directly or through some semi-official higher-level protocol, like DNS for IP?
3. What about human-friendly peer names? Those are almost required for end-user friendly applications. Most solutions of that problem either assume that every single user is willing to dedicate their life to configuring DNS, rely on a trusted third party, or delegate the responsibility to a blockchain.
4. What are the channel reliability properties, and are they configurable? Can you decide how to handle out-of-order or lost packets, or does the protocol enforce a decision? If you're willing to tolerate loss, duplication and reordering, can you avoid head-of-line blocking?
5. Is peer anonymity a goal?
6. What about two mostly-offline peers who wish to communicate (think smartphone apps that can't be connected 24/7 due to battery concerns)?
Overall, cool project.
rklaehn 13 hours ago [-]
1. Currently we are using Ed25519 keys. You could use our existing discovery services to add a level of indirection from a root key to the currently active key. It wouldn't be that much code, since the discovery services are pretty generic. But we haven't done so yet.
2. We have a centralized DNS based discovery mechanism enabled by default, and an optional bittorrent mainline DHT based discovery mechanism. We also have mDNS for local networks, and you can plug in your own.
3. Our current keys are non scarce but also not human readable. You can use another level of indirection via DNS or some blockchain based naming system like ENS to assign a human readable alias, but that is not built in.
4. Iroh streams are just QUIC streams, and reliable and ordered by default. There are APIs to receive data as it arrives, but this for really advanced users. Most users are best served by just using the streams as-is.
There is also an escape hatch if you don't want streams at all, e.g. if you have a consumer like a video codec that can deal with data loss themselves. We support QUIC unreliable datagrams ( https://datatracker.ietf.org/doc/html/rfc9221 ).
5. Peer anonymity as in hiding the ip addr of a endpoint id can be achieved, but not with the default config. The default config is tuned for performance. You can hide your ip address by using one of the mixnet custom transports and disabling the ip transport.
6. Iroh is just connections. If a and b are never online at the same time they won't be able to communicate. You would have to write an iroh protocol that talks to some always online node. We do have some protocols that can be used to implement this, such as iroh docs, but that is not the main product.
kkapelon 16 hours ago [-]
Congrats on shipping
You need urgently a "versus" page that talks about tailscale/netbird/netmaker/zerotier/twingate/openziti
Looking at the use cases, right now I don't see anything that cannot be done with Tailscale...
MayeulC 1 hours ago [-]
Should I consider using Iroh for intranet communucation ? Is it a viable use-cases? The use-cases I have in mind is an app being deployed on a HPC cluster, onto many nodes, cut off from the internet.
I had been looking at zeromq, but I very much agree with using keys rather than IPs where possible (after years of using yggdrasil, wireguard, tailscale, tor), so I am tempted to try Iroh.
OTOH, this seems overkill if I'm using a client-server approach where the server IP is known.
rklaehn 1 hours ago [-]
We have some customers that do use iroh inside data centers.
You get the simplicity of being able to freely move nodes within the data center or even across data centers without having to reconfigure ip addresses. And once a connection is established the performance is comparable to a normal QUIC connection.
Regarding client server architectures: I frequently build systems where you use p2p connections but have clearly defined client and server roles at the application level. Absolutely nothing wrong with that, in fact I think a big problem with existing p2p projects is that they try to be p2p at application level and overcomplicate things.
terabytest 39 minutes ago [-]
Are there any good end-user apps that are supported on a broad set of platforms and use Iroh to support file transfers between e.g. Windows and iOS seamlessly?
rklaehn 26 minutes ago [-]
We wrote a small demo app called sendme to show off iroh. It is cli only, works on all operating systems that we use internally, and we frequently use it to send around qlog files:
That to me looks like Reticulums [1] adressing ("Destinations") with transport done via QUIC. Does it add anything what Reticulum didn't already solve, other than using slightly different protocols - do they have an advantage?
Besides the novel/different form of addressing Reticulum pretty much imposes its Zen on users. So in a lot of things where Reticulum is quite dogmatic, something like Iroh I'd assume (if it's reaching corporates) would provide more flexibility. I haven't checked out the source though.
As an example, AFAIK, Reticulum encrypts packet origin, so only recipient can see them. I don't think this is admissible in a corporate network.
giloux314 14 hours ago [-]
This is the comment I was about to make. Reticulum is already a very complete network stack.
I've been drawing a lot of inspiration from Iroh, while working on my own https://github.com/connet-dev/connet. While peers in connet communicate peer to peer, I have a long way to cover peer discovery and transparent connection migration.
"Tailscale at the application layer, instead of the network layer" (as sibling comment describes it) is a great way of thinking about it. In my mind, with the right apps, Iroh (and connet) could really democratize secure self-hosting.
kamranjon 17 hours ago [-]
To me this sounds like tailscale - does anyone have any insight into how what this is doing is similar or different?
forsalebypwner 17 hours ago [-]
Their use of addressing by keys instead of by IPs seems to be the main differentiator. Also the support for custom transports (BLE, LoRa, Tor) which appears to be in progress and not yet fully implemented.
I love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.
RationPhantoms 16 hours ago [-]
Tailscale uses MagicDNS which allows one to auto-generate a semi-memorable private hostname as well. I'm in the networking industry so I'm not seeing anything truly groundbreaking or that isn't offered elsewhere.
rklaehn 3 hours ago [-]
It isn't meant to be groundbreaking. It is meant to be a rock solid building block that you can put into your application.
That being said, I think our use of QUIC multipath is pretty novel. If you use tailscale or a VPN, your connection (TCP or QUIC or whatever) won't immediately notice when the underlying transport changes (e.g. relay to direct or vice versa). So there will be some delays as the congestion controller learns about the underlying transport.
With the latest iroh using QUIC multipath, each path gets its own congestion controller, so switches of the underlying transport are more smooth.
Also, multipath allows us to treat custom transports as just additional paths.
danudey 16 hours ago [-]
The pitch here appears to be that this can allow communication between services without having to add them to a tailnet or such; e.g. if you wanted to let a friend or coworker access some service on your local network without making them join a tailnet, add a public external endpoint to forward traffic, set up a VPN, etc.
IIUC you just send someone 'here is the connection information' and it just works automatically.
forsalebypwner 16 hours ago [-]
Yeah and my understanding of Iroh wasn't quite right either, it sounds like it's positioned to be more of a library to use in code, rather than a VPN solution like Tailscale.
I love MagicDNS - A long time ago I wrote a stupid Python script to have it continually generate MagicDNS names until one of them contained a word I was looking for.
rklaehn 4 hours ago [-]
I work on iroh.
On the technical level, the biggest difference is probably that we build on QUIC whereas tailscale builds on wireguard. Iroh is a library that is made to embed into your application, whereas the tailscale offering started as a daemon. It allows embedding, but you are still carrying the baggage of a go runtime. Iroh is written in rust. Rust compiles to a native library and is therefore easier and more lightweight to embed in compiled programs (C, C++) and languages such as js and python.
Another big internal difference is that we use relay URLs whereas tailscale is using relay IDs. The consequence is that every iroh endpoint, no matter if using self-hosted relays, the n0 public relays, or the n0 paid relays, can reach any other. In tailscale two nodes will only be able to talk if they use the same mapping from relay id to relay ip address, which usually means that they use the same coordination server.
Last but not least, while we do have a commercial offering, everything you need to run iroh is open source, licensed MIT and Apache2. With tailscale the coordination server is closed source and operated by tailscale, and the only way to run your own tailnet is to use the headscale community project.
hazkoulia 17 hours ago [-]
My 5 second summary: Tailscale connects devices and Iroh connects applications.
dignifiedquire 16 hours ago [-]
Tailscale is built to be global to your device, while iroh is built to be embedded into each application. This allows application developers and users a much more fine grained and bespoke setup, than having a single global bridge.
This isn't the same functionality - if I'm shipping a video conferencing application, tsnet would require all my customers be in my tailnet.
kkapelon 15 hours ago [-]
but if I am shipping a video conferencing application (where I control both the client and the server) I don't need nat traversal anymore. My clients will have outgoing connections to whichever co-ordination server I choose.
Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.
nemothekid 12 hours ago [-]
>My clients will have outgoing connections to whichever co-ordination server I choose.
Then it's no longer p2p? If I wanted to avoid paying cloud egress costs, then I would need a p2p solution.
>Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.
Naturally, but this thread isn't about Tailscale, its about Iroh. You were the one that claimed Tailscale can already do what Iroh can. But I've pointed out a usecase where Tailscale wouldn't suffice that Iroh can accomplish.
ranguna 15 hours ago [-]
What if you build a p2p video conferencing app with user controlled co-ordinator "server". Server in quotes, because maybe iroh works through the browser?
ramoz 15 hours ago [-]
Ive been prototyping with Iroh for awhile.
I think this tech (modern p2p) represents what agent-to-agent (a2a) should be built on.
Every agent should be reachable to each other without hosting itself as an http server.
_Every_ agent? I surely hope not. But it would be an interesting... artisocial experiment?
ramoz 4 hours ago [-]
I mean, I didn't mean specifically every agent, and I also did not mean as a experiment. I see real at scale uses for this. Agents operating on their own networks, cross-team agents, my own agents on my own laptop, etc. Sharing context only gets more important the better these things get.
> IP addresses can break, without warning, and it's outside of your device's control. Keys, however, are created & controlled by you.
This doesn't really make a lot of sense. Assuming this is true, its equally likely to be my gateway, or BGP peer IP that breaks. How Iroh offers anything in this scenario is beyond me.
>The power of that key can't be overstated. We use it to secure the connection. And because all data that comes from the connection is secured by that key, we can build up from that same key into identity, permissions, and attribution. We can also use that same key as an address we can dial, no matter where it is in the world. It turns the internet into a secure localhost.
This is a way better use case. This should be the headline.
Kazik24 13 hours ago [-]
I've been using iroh for a while now for personal projects. I wrote an utility for sharing locally running services with others: https://github.com/Kazik24/server_share
Glad I can finally update to 1.0. It's a great library.
AgharaShyam 17 hours ago [-]
LM studio recently released a mobile app powered by Tailscale -- https://lmstudio.ai/link . Iroh seems like a perfect OSS alternative for implementing similar p2p features.
forsalebypwner 17 hours ago [-]
Tailscale is OSS AFAIK. Not their backend of course, but if you use Headscale then I believe every part is OSS.
dignifiedquire 15 hours ago [-]
tailscale also is written in go, making the integration on mobile especially, often times a lot harder and more expensive
BetterThanSober 3 hours ago [-]
Correct me if I'm wrong but assuming there is only Alice and Bob in the network, each with their key-as-address, and they are both behind a CGNAT, Iroh will still need a third party to host the relay?
rklaehn 56 minutes ago [-]
If they are both behind the same CGNat, you can use mDNS to help them find each other.
If they are behind different CGNat, you need a party that is reachable by both to help with hole punching and/or relay traffic. This is fundamental, there is nothing you can do about this.
Some p2p protocols try to enlist other peers to be that third party. E.g. holepunch.to . Iroh uses dedicated relays for this.
The relays can either be the n0 public relays, a n0 paid relay network, or self-hosted relays. No matter which option you choose, every iroh endpoint is able to talk to every other iroh endpoint unless they are fully airgapped from the internet.
Landing7610 1 hours ago [-]
not in this case, they have optional mDNS discovery
2 hours ago [-]
bear330 9 hours ago [-]
It's very cool! I am planning add Iroh into my daily used https P2P tool (https://github.com/nuwainfo/ffl) which currently using WebRTC. It's very cool to support both protocols, but it seems like Iroh python support is via FFI which can't be used in my APE (Actual Portable Executable) build...thinking...
basro 16 hours ago [-]
I wish it had support for a system similar to webrtc's offer and answer SDP messages.
From what I see, relay servers are doing a job that is equivalent to Stun + Turn + SignalingServer in WebRTC.
This is great for simplicity, but having Stun Turn and Signaling live in the same server would make it harder to secure.
For example, since in webrtc signaling is up to the user, it is most common to have signaling implemented as a web server, this allows you to have it behind cloudflare with the signaling server ip never exposed to the internet. If you are not interested in supporting turn, there is plenty of public Stun servers that can be used and Stun itself is a really cheap server to run.
For iroh, it seems if I wanted to self host relay servers I'd be forced to expose their IP to the web which would make them really expensive to run if one wanted to make them DDoS proof.
aag 6 hours ago [-]
For a side project, I used Iroh to give my web server in the cloud the ability to print directly to my label printer at home. The API is simple and easy to use. It took no time to write a reliable system on top of Iroh.
rklaehn 2 hours ago [-]
Very cool project. I seriously wish one of the printer vendors would use iroh to come up with a network printing standard that just works.
We constantly have issues with our printer. I have fewer issues with my bambu 3d printer than with my (also very expensive) epson inkjet.
These people need to get their shit together, seriously. The way things are going we will have full AGI before we have working printers.
If somebody want to do this, please reach out to us. We are eager to help. But this is one of the most annoying things ever with computers.
himata4113 14 hours ago [-]
Hmm, this really looks more of a relay network for sale, kinda like steam p2p. The only real use-case I see for this is for exactly that, connecting two or more players where one of the players is the host.
Seems like it'll be a hard sell since steam is already so dominant and enterprise is dominated by tailscale... I see the proposal for being able to work with many different networks from different companies at the same time, but it's a pretty rare usecase and nothing some iptables can't solve.
I can see the argument for chat in heavily censored regions of the world, but not sure if there's any advantages that iroh can offer over other solutions.
Market fit will be hard to find, but best of luck.
int0x29 14 hours ago [-]
Steam sockets and CloudFlare's UDP forwarding really are different though. They provide ddos protection as well as route optimization due to lots of points of presence.
Here there seems to be no mention of ddos mitigation or shorter routes due to infrastructure. Yes you need a key to connect but your iroh relay server can still be attacked. I suppose you could roll your own distributed anycast system for this.
himata4113 14 hours ago [-]
I assume that the 'enterprise' relays have ddos protection. DDoS protection also comes standard these days, but we've seen attacks go from 20gbps to 20tbps so if uptime is required then tough luck.
Not an expert but this is how I understand it. Yggdrasil is a P2P mesh network. You configure peers to join the network and your computer becomes a relay node for everyone else to use. It doesn't work behind a NAT without port forwarding.
Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.
_carbyau_ 9 hours ago [-]
So, is there an open source variant of Signal using Iroh?
IE could I get an app on my phone, to talk to anyone on the planet with that app directly without having to trust any middlemen like Apple, Google, WhatsApp etc?
Could people have something like original facebook, but without Meta because of actual p2p?
salgorithm 11 hours ago [-]
I setup a TypeScript SDK with some examples to test in the browser.
I made this a while back because I want an easy way to throw together games for family game nights.
akavel 13 hours ago [-]
Huge congrats on the release!
I'm slowly trying to build an app on Iroh; it's progressing tiny bit by tiny bit, but I must admit I'm struggling a lot all the time, both with various low-level details, as well as with understanding many high-level aspects, concepts, and approaches. Oftentimes I have to resort to some LLM-generated "wiki" websites to help me progress. I really hope you'll manage one day to allocate some more resources to improve the docs. That said, when I manage to muster enough strength, I do manage to grind some progress, and also it's good to know the underlying tech seems robust, given how many real-world solutions you've built on it!
At this moment, if I can try to ask one question: AFAIU Iroh emerged from an attempt at fixing IPFS. I also understand you've since focused more on providing the lower-level building blocks that would allow this and other solutions. Understanding some basics, but still having hard time to get a really solid grasp of the whole of Iroh, I wonder: between Iroh, p2panda, and Willow, what's available and what's missing / needs to be added if one wanted to try and build an "IPFS-like" with those technologies? I'm especially interested in an idea of a "new web" that would defuse DDoS of static websites in a Torrent-like way, forcing the downloading peers to also share their upstream bandwidth while doing this. I'm also thinking of e.g. a "globally-distributed Internet Archive", where I can easily download part of the Archive to my computer, and this automatically improves its availability on such "new web" for subsequent downloaders and browsers. Would you care to give a newbie something of a high-level overview of how one could try to do it over maybe some appropriate combination of Iroh+p2panda+Willow+DHT?
rklaehn 13 hours ago [-]
We started as an IPFS implementation, but since then the scope of iroh has been reduced. Iroh is not IPFS, but more like libp2p.
If you want something like a globally distributed internet archive you would have to use protocols on top of iroh. For example iroh-blobs provides verified streaming of content-addressed data using the BLAKE3 tree hash function. It is very close to itself being 1.0 (probably Q3), but for now it requires you to know from where to stream the data.
What is missing to fully replace IPFS is a global distributed content discovery system. This is a really hard problem that IPFS itself never solved reliably in my opinion.
I also still want this to happen eventually, but the first step is to get the connection layer super reliable and fast, which we have done.
I wish you could also delegate this problem to the mainline DHT, but alas that is not possible because of some mainline limitiations. So I am working on the side on a new DHT, see https://www.iroh.computer/blog/lets-write-a-dht-1
teohhanhui 5 minutes ago [-]
> I wish you could also delegate this problem to the mainline DHT, but alas that is not possible because of some mainline limitiations.
Thank you very much for the response! I'm definitely going to read the blogpost, thanks as well for sharing it!
CommanderData 12 hours ago [-]
Is content discovery on the official roadmap? If the original peer say peer A goes offline but B downloaded $X, can see find B and download, validate the content today?
Sorry if this has been answered or covered on the web I'm currently travelling.
Edit: I managed to read the linked page, thank you for working on such an amazing project!
rklaehn 52 minutes ago [-]
We don't have the post 1.0 roadmap very fleshed out at this point. The team has been extremely focused on getting 1.0 out of the door for the last year. This took longer than expected, as expected :-)
But I can say that some form of global content discovery is in my personal definition of done for the project. I'm the BLAKE3 guy at n0, and I don't consider blobs done without global content discovery.
But it is a hard problem, and our standards for "it just works" are pretty high.
wiremine 14 hours ago [-]
This looks really interesting... I think I grok the basic value prop.
However, I'm confused on the open source vs. commercial offerings. How do they differ? How do they work together?
rklaehn 13 hours ago [-]
The core is open source and always will be. Crates are licensed the usual for rust: Apache2 and MIT. This also includes the relay servers.
In addition we provide services that any commercial deployment using iroh will probably find essential: observability and a custom non rate limited relay network, as well as priority access to the engineering team.
flub 13 hours ago [-]
iroh is an open source library. The relay servers are open source too but number0 runs public, rate limited, relay servers that can be used by everyone. The commercial offerings are for dedicated relay servers and more insight into your network.
jmward01 15 hours ago [-]
I think I see the value prop here. Beyond its intended use, what about creating a full VPN out of it? This takes care of the hard part for a lot of home users, opening your vpn up in a safe way. I know this is solved by many other tools so this isn't a new thing but it may increase adoption. Is there already something like that? I imagine you have considered this and if it doesn't already exist have a good reason for not including it. If so, what is that reason?
astonex 17 hours ago [-]
Not sure what the difference is between this and any regular P2P network?
rklaehn 16 hours 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.
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 16 hours 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 14 hours 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 13 hours 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 :-)
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.
rklaehn 38 minutes ago [-]
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
virtualbluesky 13 hours ago [-]
This might sound pointed, but it truly isn't - why is this approach not already commonplace? As a concept, looking up a verifiable identity makes sense, but often ideas that made sense were looked into and discarded for valid reasons. Would be good to understand those to better understand when/when not to use the project?
13 hours ago [-]
openscript 14 hours ago [-]
What about censorship circumvention? Is there specialized DERP to DERP communication, that bridge over internet edge nodes doing DPI on QUIC?
rklaehn 13 hours ago [-]
We do not use DERP. But yes, relay to relay communication is something we want to look into in the future for some use cases.
As of now relays are completely self contained and pretty dumb. The protocol does not require relay to relay communication, which means that the relay code can be relatively simple.
Kinrany 17 hours ago [-]
I wonder if Iroh and Zenoh could/should be used together.
The fundamental component of Iroh is p2p routing by key, and the main utility provided by Zenoh is message semantics. The two seem complementary.
Imustaskforhelp 17 hours ago [-]
Zenoh seems interesting but can you please give me some use case where both Iroh + zenoh can be combined to achieve something more trivially (ie. without hassle) or the use-cases of this combination. I'd be curious to know more about their combined use-cases!
Kinrany 16 hours ago [-]
...that's what I'm asking :)
dangoodmanUT 15 hours ago [-]
iroh is consistently one of the most delightful projects i've ever worked with. The people reflect that too.
Congrats iroh team!
w10-1 15 hours ago [-]
I definitely see the value! But I'm not confident I can tell whether there are e.g., security implications, and I couldn't find anything on point in the docs or on github (other than one discussion on authentication that mentions the information disclosed). Would love a whitepaper on that and any other issues adopters should consider.
rklaehn 15 hours ago [-]
We should definitely do a better job explaining this.
Regarding security, one thing to be aware of is that iroh connections are just standard QUIC connections secured using standard TLS with the (also standard) raw public keys in TLS extension.
We don't roll our own crypto. What little non-standard crypto we had previously was removed on the path to iroh 1.0.
So iroh connections are just as secure as the QUIC/TLS connections your browser makes to your banking app. Whenever there are some new concerns like for example post quantum security, we can benefit from industry standards.
E.g. we do already support optional post quantum key exchange to secure connections.
Which I just finished updating to 1.0. But it is currently lacking in breadth of API, so if you start using it let us know what you are missing. In the meantime https://github.com/n0-computer/iroh-ffi has the other language bindings with a more comprehensive API
Hoping to use this to reboot an ancient abandoned project. At the time there wasn't a mature P2P connection layer that took care of all the realities of the modern Internet out of the box. Now there is, and it's great to see.
This isn't Tailscale because it does secure P2P connections between any pair of devices, whether or not they have Tailscale. This enables real end-user P2P for, e.g., local-first apps with no server infrastructure except relays for resilience. And even if you lose the relay servers, things keep on working the same for any hosts that don't need them.
geoctl 16 hours ago [-]
Honestly I am happy that more remote access products are using QUIC, not WireGuard, for tunneling and realizing its technical benefits (e.g. AES hardware acceleration, dynamic endpoints, custom auth with JWT or mTLS, FIPS compliance, traffic masquerading as HTTP/3, etc.). I am a big fan of QUIC myself and I implemented it long ago in Octelium, which is a similar remote access product that's more centered around access control and zero trust rather than P2P connectivity. I believe QUIC should be the future of tunneling, especially when it comes to business and enterprise remote access use cases. Congrats on launching an I wish you the best of luck.
dignifiedquire 17 hours ago [-]
hey, I helped make this :) will try to answer questions where I can
piskov 17 hours ago [-]
Does this solve the problem of internet segmentation due to politcs?
For example: dns control, tls certification bans (just this month both let’s encrypt and globalsign started revoking Russian certificates), once google starts really complaining about https it gets ugly.
Russia aside, anyone else is closely watching (europe, brics, what have you)
rklaehn 16 hours ago [-]
I would say it is an excellent building block for application developers to route around the segmentation. There are several projects that work well in restricted enviroments that use iroh for some features. E.g. https://delta.chat/en/
E.g. you could write an excellent encrypted chat app using iroh, the Tor or Nym custom transport, and BLE or direct wifi for local connections.
You have to be careful though to make sure you configure the transports correctly in order not to expose data you don't want exposed. Iroh can be used in highly restricted environments, but the defaults favour performance over complete metadata privacy.
dignifiedquire 17 hours ago [-]
While it doesn't solve all the issues that come up through the current segmentation, it is very much possible today to assemble components that let you forget about segmentation while you use it.
And it is designed from the ground up, to use existing internet technologies, while avoiding the lock in and dependencies on browser vendors or other large players.
zelias 17 hours ago [-]
how can i make it give me zen-inspired life advice?
Hugsbox 17 hours ago [-]
I'd also like for it to prepare tea
BetterThanSober 3 hours ago [-]
418 I'm a teapot
projektfu 17 hours ago [-]
Jasmine tea and a game of Pai Sho.
dignifiedquire 16 hours ago [-]
the zen life advice will come if you use it long enough :)
tmzt 16 hours ago [-]
I've been working on a mesh network for private AI models running remotely, controlled by mobile devices (smartphones, tablets, etc.). The mesh is constructed like a piconet, a few devices controlled by a single individual, layered on top of the internet.
How does it support semi-connected devices, intermittent connection failures, etc?
karissa 16 hours ago [-]
Hi, I also work on iroh.
Iroh is built for environments where connectivity is unreliable or intermittent, so it can be a good fit for use cases involving connection failures, offline periods, or semi-connected devices.
We provide a range of peer-to-peer protocols that don't require a central server, including key-value stores, blob transfer, collaborative documents, and streaming audio/video. These protocols are designed to synchronize devices back to a consistent state, even after long disconnections or network interruptions.
If you'd like to explore whether iroh could work for your use case, we're happy to chat. Feel free to email us at support@iroh.computer, and we can set up a call.
amatheus 17 hours ago [-]
This looks very interesting. I’m not sure I understand this, but it seems to me like it competes (or is in the same space as) both Tailscale and zeromq/nanomsg via the protocols? I think it would be nice to have a comparison page to make it easier to position it (I didn’t find one).
rklaehn 17 hours ago [-]
A key distinguishing factor is that iroh is meant to be used as a library that you can embed into your desktop, mobile or embedded apps.
Up to now our users are mostly teams that have a rust or C/C++ core, such as https://delta.chat/ . But now that we have bindings teams who use other languages should be able to use iroh.
So you can write e.g. an android and ios app that uses iroh direct connections under the hood, and the app user does not have to know or care about this at all.
matheus23 17 hours ago [-]
We keep thinking about ways to combine iroh + zeroMQ! I think these two could compose. (Not familiar with nanomsg myself)
About tailscale: It's similar, but iroh is not a VPN, so it doesn't add a TUN interface. Instead, you'd build iroh directly into your application. Using iroh you can build a VPN, and there are projects that do so (iroh-lan/iroh-vpn are some hobbyist projects). The upside of building it into your application is that it doesn't need special permissions and is easy to ship to the user.
eikenberry 14 hours ago [-]
Why a library and not a service/daemon? Or are you planning to write a server based on the library and just haven't got to that yet?
rklaehn 14 hours ago [-]
We think a library is more useful for widespread adoption. I can't get my mother to install a daemon, but I can get her to download an app that uses iroh under the hood.
Besides, as a lot of people have mentioned already, if you want a dedicated server there are a lot of existing options.
How soon till govporations require that people dial their services by key, issue and treat the keys like passports, and block those who say something against the grain, acess a forbidden site, read a forbidden book, happen to be of wrong nation or otherwise violate ToSes of said govporations?
A wonderful chain to link to the CBDC shackle.
overgard 15 hours ago [-]
This sounds useful, but isn't this the problem that ipv6 is supposed to solve with 128bit addresses? (I'm not really familiar with why IPv6 never really seemed to take off -- does NAT block incoming IPv6 traffic? (I guess that's the other thing -- even though my devices all seem to have IPv6 addresses I can't recall ever using them))
rklaehn 14 hours ago [-]
IPV6 addresses are still addresses. They get assigned to your device, and change as you change networks.
Iroh addresses are (currently Ed25519) keys. They are not scarce, so you can create them on demand and keep them as you move from one network to another.
If IPv6 was everywhere I guess the hole punching feature of iroh would become less important, but the dial by key feature would remain just as important.
apitman 12 hours ago [-]
IPv6 solves a lot of it, and maybe in another 20 years we can rely on it.
tancop 14 hours ago [-]
[dead]
0x59 16 hours ago [-]
So this could be used as a streamlined way for client devices (mobile phones for example) to phone home to servers (google.com for example) with user data and bypass some local network controls? (DNS block lists, for example)
I’m thinking similarly. Seems delightful for malware development and exfil. But I haven’t confirmed how the actual connections are made.
MostlyStable 17 hours ago [-]
I'm out of my technical depth here, but out of curiosity: is this meant to be a full replacement for the current IP address paradigm, or is this meant to be a specific tool on top of/alongside IP addresses that solves particular problems/frictions?
rklaehn 16 hours ago [-]
I would say it is not a replacement but an addition.
IP isn't going anywhere any time soon, but we add two capabilities on top. The ability to dial an endpoint by key, and the ability to get direct connections whenever possible.
That being said, if some other technology becomes popular that actually replaces the IP address paradigm, iroh is well positioned to make use of it. From the point of view of an iroh application developer nothing would change. You still dial by key, and iroh will just make sure under the hood to get you the best possible connection, IP or otherwise.
Arqu 17 hours ago [-]
A little bit of both. Natively it relies on QUIC and leverages existing IP infrastructure, however it also works with custom transports just as fine so you can interact via bluetooth for example.
bicepjai 12 hours ago [-]
So each app can be its own tailnet, and let devices talk to each other on its network using api keys. Like home appliances in HomeKit network ?
yapancha 12 hours ago [-]
Maybe it's just me but it's not clear immediately what this is about. I did get a sense after spending enough time. Just feedback.
I've just learned about it, but my understanding is that Iroh is L7, compared to e.g. tailscale which is L3
Imustaskforhelp 17 hours ago [-]
Good for Iroh to have libraries within different languages.
I think that with Kotlin support, the creation of some android/multi-platform gui apps can be made easier if they want to use Iroh.
Arqu 17 hours ago [-]
Thanks, we agree! We used to have bindings for while but the maintenance burden at that point was too high. Now that 1.0 guarantees everyone some stability and we feel confident in the library, we have enough room to properly support it.
mnot 11 hours ago [-]
The site mentions preferring open standards in the IETF - where is it being discussed there?
sgsvnk 8 hours ago [-]
This is great work, but the blog is too esoteric, likely written by the developers. You should revamp the website to appeal to more general software engineers with more easy to understand terminology to get better traction.
jbverschoor 15 hours ago [-]
Nice video production, but as you can see on this thread of nerds, the messaging is not clear.. Content first, presentation later.
rklaehn 15 hours ago [-]
We have plenty of very deep technical content on our blog, explaining features of QUIC such as 0-rtt, post-quantum key exchange, address validation tokens, embedded devices.
A great thing about iroh is that due to it being just QUIC, when you learn about iroh you also learn about details of QUIC that are useful and transferrable for traditional p2p QUIC connections.
MoonWalk 15 hours ago [-]
Not to mention that the title of the post doesn't even say what it is.
Pbhaskal 6 hours ago [-]
but does not quic internally needs an IP address to route , who maintain device vs ip address map.
Holepunch, formerly hypercore, formerly dat, is a great project. Their main language is js, which makes it difficult to embed into anything but js/ts applications.
Also, they are very principled when it comes to peer to peer purity, whereas iroh is a bit more pragmatic. We use dedicated relays to faciliate hole punching, whereas holepunch tries to use other peers as a temporary relay for hole punching messages.
Another difference is that holepunch have their own DHT, where we have a less decentralised address lookup service by default and use the mainline DHT as a fully p2p alternative.
So TLDR if you are doing js in the browser, holepunch.to might be a good fit. If you work on native mobile apps or embedded devices, iroh will be better since it is pretty frugal. If you work with node.js, both will work. Just evaluate them both and use what works better for you.
Thank you so much for the great reply! Answered all my questions - will definitely look closer!
mrbluecoat 13 hours ago [-]
Surprising you don't support golang
rklaehn 3 hours ago [-]
We did have golang bindings in the past, but had to pause all bindings because keeping them up to date was not viable. Now that we have a stable API, we will revisit this.
If there is enough serious demand we could publish go bindings. Iroh is a rust library that is very easy and efficient to embed into golang binaries.
13 hours ago [-]
born-jre 13 hours ago [-]
As a person which tried to love libp2p so much this look. Great will definitely take deeper look
janandonly 15 hours ago [-]
This is big
> We built & continually check that iroh can compile to WASM & run in the browser
mcdermott 13 hours ago [-]
"If the implementation is hard to explain, it's a bad idea." --Zen of Python
13 hours ago [-]
arianvanp 12 hours ago [-]
Are you able to do any form of highly available loadbalancing with this?
28304283409234 17 hours ago [-]
I love it. I think. But I find it hard to parse tech videos with music in the background.
nicebyte 15 hours ago [-]
I am confused why this is needed.
> IP addresses can break, without warning, and it's outside of your device's control.
We have DNS?
> Keys, however, are created & controlled by you. They stay the same as your device moves, and are yours to throw away, or not.
So are domain names? This page does not do a good job of helping me find what it is that I'm missing.
ben-schaaf 15 hours ago [-]
Your phone and laptop don't have stable IPs, let alone DNS entries pointing to them.
kkapelon 15 hours ago [-]
They do if you use tailscale and friends
ben-schaaf 15 hours ago [-]
Everyone I'd like to connect to isn't on my tailscale, nor do I want them to be.
nicebyte 12 hours ago [-]
but dynamic DNS is a thing. I've had setups for it since god knows how long, though admittedly not on my phone.
rklaehn 3 hours ago [-]
DynDNS does not work for devices behind a NAT unless you manually set up port forwarding.
Iroh gives you the connectivity of DynDNS without any manual configuration.
ben-schaaf 4 hours ago [-]
Dynamic DNS takes setup for every single device, and obviously doesn't work for devices that switch networks frequently. It also doesn't help you if the IP is behind a NAT.
guywithahat 13 hours ago [-]
What you're missing is that they can't charge you for IP's, and someone else already charges you for DNS/domains. They would like to replace your IP's with keys they lookup. It's a cool idea and I would expect that they'll find a market, but I'm not sure this would be a breakthrough product for me
nicebyte 12 hours ago [-]
that just sounds like DNS but more centralized and not super human-friendly...
rklaehn 2 hours ago [-]
Iroh endpoint ids are just Ed25519 keypairs. We don't want you to charge per id, and even if we wanted there is no way we could.
We charge you for hosted relays and additional insights into your deployment, but the core is and will always remain free. Everything is licensed MIT and Apache2.
suwapat 16 hours ago [-]
Missing a native go version
rklaehn 16 hours ago [-]
Iroh is just a clever combination of existing standards such as QUIC with some draft RFCs and a tiny bit of clever custom logic added via TLS extensions.
So in theory a go implementation is possible using a go QUIC implementation that supports the multipath extension.
Our focus is the rust implementation, since it is very easy to use from compiled languages such as rust, C and C++ and to embed into languages such as js and python.
Edit: since iroh is just a library, it is also possible to link iroh into a go program. Linking a go program from other native languages is a bit of a pain, but linking a C or rust library into a go program is relatively straightforward and high performance.
karissa 16 hours ago [-]
Would you use it if there was a go version?
sunshine-o 10 hours ago [-]
I am looking at the awesome page [0] and was surprise not to see a syncthing equivalent.
Wouldn't that an obvious use case? or am I missing a technical limitation?
No. IP isn't going anywhere. The intent is to provide additional capabilities on top of IP.
That being said, if IP ever gets replaced, your iroh based app will continue to work pretty much unchanged. Iroh will just get you the best possible connection (IP or whatever) under the hood.
commandersaki 17 hours ago [-]
So what has the reception been like with IETF?
rklaehn 17 hours ago [-]
Iroh is a project that combines existing IETF standards in an interesting way. For example we use raw public keys in TLS for the key exchange https://datatracker.ietf.org/doc/html/rfc7250 instead of coming up with our own key exchange scheme.
Our QUIC implementation noq is a standards compliant QUIC implementation that in addition to RFC9000 also implements the QUIC multipath draft RFC.
We try very hard not to invent new things unless absolutely necessary. In a few places we had to implement draft RFCs, QUIC multipath and QUIC NAT traversal. And there are some corners where we had to add our own extensions. But we try very hard to keep this to an absolute minimum.
Arqu 17 hours ago [-]
Were interacting with IETF on a number of projects and so far it's been going well :)
I have been playing around with building an Iroh Tunnel Sandstorm app that can connect two Sandstorm instances, and share some capabilities exposed from one Sandstorm instance to the other, as if the capabilities were local. Iroh has been very reliable throughout the process.
const ALPN: &[u8] = b"iroh-example/echo/0";
let endpoint = Endpoint::bind().await?;
// Open a connection to the accepting endpoint
let conn = endpoint.connect(addr, ALPN).await?;
// Open a bidirectional QUIC stream
let (mut send, mut recv) = conn.open_bi().await?;
// Send some data to be echoed
send.write_all(b"Hello, world!").await?;
send.finish()?;
// Receive the echo
let response = recv.read_to_end(1000).await?;
assert_eq!(&response, b"Hello, world!");
// As the side receiving the last application data - say goodbye
conn.close(0u32.into(), b"bye!");
// Close the endpoint and all its connections
endpoint.close().await;
dignifiedquire 16 hours ago [-]
I would love to see that P2P DNS you are talking about
bel8 14 hours ago [-]
Perhaps it doesn't exist because there's no real need.
embedding-shape 17 hours ago [-]
Such is life when you choose to be introduced to something by a version update blogpost, instead of clicking in the top-left corner and reading the landing page.
SubiculumCode 16 hours ago [-]
Did we choose, or was that the link we were given that introduced us to it.
embedding-shape 16 hours ago [-]
The whole experience is fully interactive and you get to chose your own adventure! If you get lost, top-left corner is a safe bet to go to the initial page. Welcome to the internet and enjoy :)
pseudalopex 17 hours ago [-]
This is true. But you could click the name in the top left. Or Docs.
IP addresses break, dial keys instead
Modular networking stack for direct, peer-to-peer connections between devices
iroh establishes direct connections whenever possible, falling back to relay servers if necessary. Get fast, efficient, reliable connections that are authenticated and encrypted end-to-end using QUIC.
superkuh 9 hours ago [-]
I am happy to see that Iroh says they'll support the 1.0 protocol for the entire life of the project even if they make a new version. If they can stay true to this it'll be a useful alternative domain system. But using QUIC means it's CA TLS only. As we've seen with the US government pressure on Lets Encrypt recently this CA TLS requirement allows the US (or other nation's) feds to shut down your 'key' no matter where you are. If they allowed self signed or even plain text this would not be a serious issue. But QUIC libs generally can't do this or at best offer a 'scary' build flag for self-signed that is never enabled on any dev's machine during compiling for distribution.
rklaehn 5 hours ago [-]
We are using QUIC, but using a QUIC/TLS extension called raw public keys in TLS. The DNS is not involved in any way, and there is no way anybody can shut down your usage of iroh.
In the beginning of the project we did use self-signed certs, but due to raw public keys that is no longer necessary. And in any case scary build flags aren't an issue since we control our own rust QUIC implementation, noq.
r0l1 16 hours ago [-]
Netbird offers the same. Just based on wireguard and everything is open source.
convolvatron 17 hours ago [-]
I should read the specs, but since it's such a foundational issue maybe someone who knows could respond briefly? the problem with a flat addressing space is that it requires every intermediate node to have state about every address, or perform a costly discovery mechanism for those it doesn't know about. is there a clever answer to this?
rklaehn 17 hours ago [-]
We have an answer, but it isn't really clever. We do have both built in and pluggable address lookup services.
Our default enabled address lookup service is using DNS in a creative way, but we also have a service that is fully peer to peer and is using the mainline DHT, specifically the bep_0044 extension that allows you to store a tiny bit of arbitrary data for an Ed keypair that you control.
The secret is that iroh still uses IPs under the hood :)
But with QUIC, your connections aren't bound to your four-tuple, your connection can migrate from e.g. WiFi to Cellular with only a small blip/hiccup.
And with QUIC multipath, you can have multiple four-tuples "active" at the same time. iroh uses e.g. a "real" IP path mainly, with a websocket-based HTTPS path via relay servers as the backup (e.g. in case UDP is blocked).
MoonWalk 15 hours ago [-]
Is what?
shevy-java 15 hours ago [-]
> And because all data that comes from the connection is secured by that key, we can build up from that same key into identity, permissions, and attribution.
So basically they want to find out who is who. In other words: sniffing.
It's interesting how the discussion is currently shifting to meta-explain why sniffing is necessary. I noticed this at universities in the last years; people now either have a tablet or a smartphone or a yubico key. This will be extended in the future, there is no doubt about that. And they are selling it with fancy words, just as Iroh showed.
gamegod 16 hours ago [-]
Sounds good, but the first step in your quickstart is getting an API key, and I'm oh, so I guess your sales pitch was a lie and this is really just another Cloudflare-like play to build another intermediary in the internet. If that's not the case, then I shouldn't need an API key for hello world...
rklaehn 16 hours ago [-]
If you are a rust developer, you can just take a look at the examples in the iroh repo itself or in our iroh-examples repo.
So is this like an unfree CJDNS? What are the main differences?
rklaehn 15 hours ago [-]
There is nothing unfree about iroh. All core crates are published with the standard MIT and Apache2 licenses.
jMyles 14 hours ago [-]
Oh gotcha - the 'pricing' page initially gave me the impression that routing was closed/paid. But I guess it's just hosted deployment?
rklaehn 3 hours ago [-]
Yes, exactly.
Our commercial offering provides more insight into your iroh deployment as well as a hosted relay network. At the enterprise tier you can also get priority access to our engineering team.
Obviously we want to make people aware of these services. But we also have projects that use iroh at large scale without using iroh services.
ssx-x1 16 hours ago [-]
reticullum is better, and faster
konart 12 hours ago [-]
better and faster how?
schlap 17 hours ago [-]
Were all building the exact same shit.
dignifiedquire 16 hours ago [-]
are we?
yusefnapora 15 hours ago [-]
[dead]
abricq 16 hours ago [-]
[dead]
snowflaxxx 13 hours ago [-]
[dead]
YuanJiwei 12 hours ago [-]
[dead]
Lapsa 14 hours ago [-]
[dead]
WhereIsTheTruth 17 hours ago [-]
Looking at the pricing page, how can this be the future, maybe the post was written in 1998
If your question is, "why not just use Tailscale?", look at it from an app developer's perspective. If you want to release an app and have instances of your app be able to easily connect to each other, you could theoretically embeded Tailscale functionality into your app, but then the users of your app need Tailscale accounts, and your app is dependent on Tailscale.
Iroh lets you embed this functionality directly, and provides public fallback relays. If your app gets too big for the public relays, using your own relays is the flip of a switch.
You explained the value proposition so well. The website just didnt get to the "why?" At all
I don't understand why HN seems so concerned about nailing down its "value proposition".
You're getting sidetracked because of the particular phrase "value proposition" but a lot of people just use it as a stock phrase to simply understand something even without any commercial product perspective.
You can read through this entire thread where people are having a hard time wrapping their head around what _it_ _is_ because the blog article doesn't explain it well.
The following various stock phrases use different words but are basically asking the same thing:
- "This is the solution to what problem?"
- "How's this different from Tailscale/Wireguard/QUIC/etc?"
- "What is the raison d'être ?"
- "ELI5?"
- "What's the value proposition?"
- "Why should I care about this?"
- "What's the use case for this?"
- "What's the motivation / rationale for this?"
- "What does this do?"
And then different commenters try different explanations and hopefully one will finally click for readers.
Maybe the game has changed with LLMs, but its been a running joke that engineers will build a startup/product/library/thing only to then realize they can’t get any users and that marketing and sales are hard.
Attention and mind share are more valuable than ever. If you can’t answer “Why should I care about X?” then you are fighting an uphill battle.
I agree with your premise, but you're still viewing this technology through the lens of "a successful product" versus "a successful piece of technology".
Plenty of open source projects stay open source and are popular without ever making any sales whatsoever. I'm not trying to project my own motivations on the Iroh team; they may want to build a product out of it. For me, though, the project has a lot of appeal already, because it exactly and excellently fulfills a technological need, not because they brought me in with a "it's x but for y" narrative.
For environments where you want people to access your local instance, I believe Iroh will be a game changer. For us, it's to allow control over our software through phones and other devices easily.
Previously, you might have to make sure they're in the same LAN network. But with Iroh, anything works.
especially when iroh makes it so easy and awesome to do it right.
Either one will allow you to stop "concentrating distributed technology to a handful of centralized owners", but the "why not use tailscale" part of what you're trying to say is not at all evident from your comment.
+ iroh and openziti can both be app-embedded
+ so the app developer embedding in their service is a good use case for both
+ openziti is used for services in which scale and security are critical
+ whereas iroh allows participation from parties which don't have any prior relationships - which can be very convenient
Except without all the ceremony about setting up daemons, servers, controllers, "networks" and what not that openziti seems to have. Iroh is more "define protocol and hook two clients together" with everything in one binary.
Unless I understand https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... wrong, it seems to require a "controller-url", is that controller embeddable as well?
I've looked at the usecases page, obviously there is an AI stunt (which I don't buy at all), for POS applications, well, there are better and less risky (see above) ways to do this, so the only thing that seems to make sense is this real-time sync, if someone is in the restricted environment (but, the point is, that in the restricted environment iroh is going to be blocked anyway by firewalls, z-scaler, etc.).
A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ...
Iroh as of now supports only IPv4, IPv6 and relay transports out of the box. There is such a large variety of potentially interesting transports out there that we can't support all of them without turning the codebase into an unmaintainable maze of feature flags.
But we have added the ability to implement custom transports. That way your transport implementation can live in a completely separate crate.
Existing experimental custom transports include Tor, Nym and BLE. https://github.com/mcginty/iroh-ble-transport
Here is how custom transports work under the hood: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...
I'm trying to understand it's limitations, if I used this to build a p2p client / server setup or even two peer machines, what else do I need to setup to be able to have connections between the two applications?
For example, could I create an application that runs on my phone and another that runs on my laptop and finally get a direct secured working connection between the two of them? Or is this solving a different problem? =)
-[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
Here is a video of frando from our team demoing media over QUIC: https://www.youtube.com/watch?v=K3qqyu1mmGQ
If you use the default setup you are still depending on a tiny bit of cloud infrastructure such as our public relays to faciliate the hole punching. However, we also have optional local discovery using e.g. mDNS.
This would give you a native iroh node that also speaks webrtc but I find that what folks want is for browsers to participate as peers.
I build p2claw, p2p for self-hosted web apps, and ended up doing both halves separately. Box to box is iroh, although I use my own coordinator service and run my own iroh relay. Browser to box is webrtc with a service worker that makes the browser act like a peer. The worker grabs fetches and sends them as HTTP frames over the data channel, the box answers on localhost. The browser bit has to be webrtc because it's the only browser api does ICE.
Wiring up the iroh half went smoothly, very much enjoying working with the library. Congrats on 1.0!
Last year, I was trying to choose between the two and went with that I know... but it feels like there's real momentum on Iroh's side.
So you might get a lot of traffic. You can configure rate limiting, as we do on our public relays.
The traffic is fully encrypted and can not be decrypted by the relay. The only information the relay has is what is necessary for it to function - the endpoint id and ip addresses of the endpoints that are connected to it at any given time, as well as endpoint pairings.
You relay encrypted traffic with no egress to the open internet. So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
Nice. I already do rate limiting, traffic balancing using sch cake. This looks like an interesting project. I could envision open source NVR's implementing this. I also like the name of the project.
you are using a Tor daemon in it. tor has a rust implementation and when used with rust has stream objects etc.
an example of how it's used can be found in https://gitlab.torproject.org/tpo/core/oniux
Arguably directly embedding the rust tor implementation would be more useful for the typical iroh user that wants an embeddable library. I just did not get to it yet.
But thanks for the link.
If you look at Wireguard traffic, you'll see a <EndpointID>.iroh.invalid SNI in the QUIC Initial packet.
Encrypted ClientHello can fix that, but support hasn't shipped into rustls yet. So it's definitely fixable.
The interesting thing is that the ClientHello is undetectable when it's sent via the relay transport (sent inside a WSS connection). And in that case, any traffic that happens on IP is fully encrypted and can't be categorized.
How current is the PyPI package? https://pypi.org/project/iroh/
So the relay is never in a position to send you the wrong public key, because it doesn’t give it to you in the first place.
Only the owner of the corresponding private key can initiate a connection from their public key, or receive a connection attempt to their public key.
Let's say you have alice and bob talking via a relay. Even if you have the private key of alice, you can impersonate alice to bob, but not vice versa. So you can't initiate a connection between the two.
To really intercept data you would need the private keys of both participants.
Strategy patterns and code-centralised feature management ftw :)
I am not aware of a LoRa custom transport yet, but that is not unexpected given that the custom transport API is relatively new, and our main focus has been on getting iroh 1.0 out of the door.
Maybe it's in the video I didn't watch, but I really think paragraph one should make clear what kind of keys and why. Cryptographic? Asymmetric? How do they do the job, at even the most basic level? It never explains, just dives into abstract claims of superiority and usage stats. I gather relays are involved; this would be a good thing to mention right away instead of making me sift it from the HN discussion.
It might be the docs just mesh with how I think about things. The creators should expand on this, since people seem to not mesh with the current info.
If you look at an iroh connection in wireshark it is just a QUIC connection. If you configure a SSLKEYLOGFILE so wireshark can actually look into the packets, you will see a few TLS extensions and somewhat unusual packets flying by during the handshake, but once established it is a completely normal QUIC connection.
That is also why we are relatively confident regarding encryption security. It is just TLS. And we can also leverage new encryption like post quantum key exchange with just a few config changes, without any code changes.
See https://www.iroh.computer/blog/iroh-post-quantum-handshakes
One thing that is genuinely novel is that we use QUIC multipath to keep the different paths (relay, various direct IP paths) separate. This has some technical benefits because the congestion controller does not get irritated when the underlying transport changes. Each transport has its own congestion controller.
Here's my summary from Lobste.rs, keeping in mind I'm not an expert and only found this project today:
> [..] this is closer to an opinionated WebRTC setup that handles assigning a persistent ID to clients. All the work of making a signaling server is taken care of and the solution is generic enough and cheap enough to run that you can get away with using a community hosted one. Kinda similar to what you get with Steam’s proprietary p2p gamenetworkingsocket infrastructure
https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...
There is already IPv6 and quic, you need vendor and major software to have any traction in that field.
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.
https://tailscale.com/blog/how-nat-traversal-works
p2p apps need direct connections.
> there is one giant "network" of all your nodes
From what I understand they're saying, the point is that you get easy connections to things that aren't "your" nodes, sort of like allowing me to connect one of my tailscale nodes ad-hoc to one of your tailscale nodes, when our accounts are not related in any way prior to us doing that, and without me having to allow your node onto my network or you allow one of mine onto your network and have to deal with the specialized ACLs for that, since it's just a direct connection between two nodes.
The similarities are in an application lib to connect, and that tail net IPs correspond to device keys like in Iroh. The service using the Go library has its own Tailscale identity.
In theory you could run Headscale, but you're really working against Tailscale's intended design at that point, and Iroh was built for this from the ground up, so what is Tailscale buying you?
Not true. Depends on the VPN protocol.
Sounds great to me, and would be a boon for self-hosting and decentralization in general, which is sorely needed considering how captured, authoritarian, and anti civil liberties every democracy is becoming. If I'm not mistaken, I believe I read a tailscale blog about them envisioning application layer embedding at some point as well.
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.
https://tailscale.com/blog/how-nat-traversal-works
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.
There are policies defining who can talk to what; they are deployed from a GitHub repository with defined rules on who can modify them and who has to review them; there are zero scenarios where I want an alternative way of granting access to any device or service under our control.
If I wanted to share something internal with a friend I would use ngrok or any of the million alternatives.
Anyway, this is exactly why my top-level comment says that this project needs a "versus" page in the docs.
For browser / webapps you want webrtc.
[1]: PeerJS(https://peerjs.com/) is a library to use WebRTC w/o any boilerplate code. [2]: WebRTC functionality can be enabled in non-browser envs like Node.js by using third-party native addons (like node-webrtc) that provide bindings to the underlying C++ WebRTC library.
So libp2p builds many things on top of the underlying transport where we use QUIC directly and use existing mechanisms such as TLS ALPNs for protocol negotiation.
We also use the stream multiplexing that is built into QUIC instead of putting a stream multiplexer on top of QUIC.
You can think about it like this: libp2p abstracts transports as streams, and then puts many required features on top (protocol negotiation, stream multiplexing)
Iroh uses QUIC and abstracts transports below QUIC. We can work with any unreliable datagram transport that has (or can be hacked to have) a minimum MTU of 1200 bytes (needed to be QUIC compliant).
Iroh is still awesome.
They really need to dumb this down to make it accessible if it's going to spread.
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.
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.
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.
(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
Kademlia introduced a much more sophisticated approach: 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
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...
²https://dnsmadeeasy.com/resources/the-state-of-ipv6-adoption...
³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
⁶pkarr uses mainlineDHT, which is a flavor of Kademlia (also used in BitTorrent, among others).
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.
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.
https://youtube.com/@n0computer
> But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.
Interesting (and somewhat proven) idea to finance it, smart :)
Did you guys started doing this already on a case-by-case basis and have some experience of it already, and if so what are the common things you typically help out with exactly? I'm just curious what sort of things a company who'd use a protocol like that might need help with, that they wouldn't have experience with in-house, since they're going down a P2P road already (assuming that, maybe maybe need help with greenfield projects)?
If you use their offering, you probably get some kind of web interface for metrics that isn't open-source.
https://docs.iroh.computer/concepts/relays https://www.iroh.computer/services/hosting
"we want to be infrastructure for people, and a business towards professionals."
stuck between "we need cash to operate" and "we want to be a public good infrastructural system." , with the negative parts of a for-profit whisked away with "Well it's open source."
it's a business concept i'm okayish with as long as the "Well it's open source." caveat doesn't come with a total bespoke and unusable code base to figure out.
Our code is as good as we can make it, and everything is modular and well documented. For example our QUIC implementation noq which underlies every iroh connection can also be used as a standalone QUIC impl that implements QUIC multipath.
https://docs.rs/noq/latest/noq/
If we wanted to have "total bespoke and unusable code" we would have inlined all of this into the iroh repo to make it unusable.
Tailscale is a great service that happens to be open source, but Iroh is clearly structured as a library that you can build into whatever you want.
If you want to run an ISP or AS, believe me it will cost you a decent chunk of money.
1. How does Iroh handle key rotation / leakage? Could you build some kind of hot/cold system on top of it, where you'd have a cold "identity key" in airgapped, secure storage, used only to issue certificates for your hot "traffic acceptance" key?
2. Is there any kind of peer discovery / DHT, either built-in directly or through some semi-official higher-level protocol, like DNS for IP?
3. What about human-friendly peer names? Those are almost required for end-user friendly applications. Most solutions of that problem either assume that every single user is willing to dedicate their life to configuring DNS, rely on a trusted third party, or delegate the responsibility to a blockchain.
4. What are the channel reliability properties, and are they configurable? Can you decide how to handle out-of-order or lost packets, or does the protocol enforce a decision? If you're willing to tolerate loss, duplication and reordering, can you avoid head-of-line blocking?
5. Is peer anonymity a goal?
6. What about two mostly-offline peers who wish to communicate (think smartphone apps that can't be connected 24/7 due to battery concerns)?
Overall, cool project.
2. We have a centralized DNS based discovery mechanism enabled by default, and an optional bittorrent mainline DHT based discovery mechanism. We also have mDNS for local networks, and you can plug in your own.
3. Our current keys are non scarce but also not human readable. You can use another level of indirection via DNS or some blockchain based naming system like ENS to assign a human readable alias, but that is not built in.
4. Iroh streams are just QUIC streams, and reliable and ordered by default. There are APIs to receive data as it arrives, but this for really advanced users. Most users are best served by just using the streams as-is.
https://docs.rs/noq/latest/noq/struct.RecvStream.html#method...
There is also an escape hatch if you don't want streams at all, e.g. if you have a consumer like a video codec that can deal with data loss themselves. We support QUIC unreliable datagrams ( https://datatracker.ietf.org/doc/html/rfc9221 ).
https://docs.rs/noq/latest/noq/struct.Connection.html#method...
5. Peer anonymity as in hiding the ip addr of a endpoint id can be achieved, but not with the default config. The default config is tuned for performance. You can hide your ip address by using one of the mixnet custom transports and disabling the ip transport.
6. Iroh is just connections. If a and b are never online at the same time they won't be able to communicate. You would have to write an iroh protocol that talks to some always online node. We do have some protocols that can be used to implement this, such as iroh docs, but that is not the main product.
You need urgently a "versus" page that talks about tailscale/netbird/netmaker/zerotier/twingate/openziti
Looking at the use cases, right now I don't see anything that cannot be done with Tailscale...
I had been looking at zeromq, but I very much agree with using keys rather than IPs where possible (after years of using yggdrasil, wireguard, tailscale, tor), so I am tempted to try Iroh. OTOH, this seems overkill if I'm using a client-server approach where the server IP is known.
You get the simplicity of being able to freely move nodes within the data center or even across data centers without having to reconfigure ip addresses. And once a connection is established the performance is comparable to a normal QUIC connection.
Regarding client server architectures: I frequently build systems where you use p2p connections but have clearly defined client and server roles at the application level. Absolutely nothing wrong with that, in fact I think a big problem with existing p2p projects is that they try to be p2p at application level and overcomplicate things.
https://www.iroh.computer/sendme
There are several projects inspired by sendme that use the same protocol but add mobile device support and a GUI:
https://www.altsendme.com/en
https://github.com/ARK-Builders/Drop-Desktop
https://github.com/zignig/sendme-egui
[1] https://reticulum.network/
As an example, AFAIK, Reticulum encrypts packet origin, so only recipient can see them. I don't think this is admissible in a corporate network.
I've been drawing a lot of inspiration from Iroh, while working on my own https://github.com/connet-dev/connet. While peers in connet communicate peer to peer, I have a long way to cover peer discovery and transparent connection migration.
"Tailscale at the application layer, instead of the network layer" (as sibling comment describes it) is a great way of thinking about it. In my mind, with the right apps, Iroh (and connet) could really democratize secure self-hosting.
I love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.
That being said, I think our use of QUIC multipath is pretty novel. If you use tailscale or a VPN, your connection (TCP or QUIC or whatever) won't immediately notice when the underlying transport changes (e.g. relay to direct or vice versa). So there will be some delays as the congestion controller learns about the underlying transport.
With the latest iroh using QUIC multipath, each path gets its own congestion controller, so switches of the underlying transport are more smooth.
Also, multipath allows us to treat custom transports as just additional paths.
IIUC you just send someone 'here is the connection information' and it just works automatically.
I love MagicDNS - A long time ago I wrote a stupid Python script to have it continually generate MagicDNS names until one of them contained a word I was looking for.
On the technical level, the biggest difference is probably that we build on QUIC whereas tailscale builds on wireguard. Iroh is a library that is made to embed into your application, whereas the tailscale offering started as a daemon. It allows embedding, but you are still carrying the baggage of a go runtime. Iroh is written in rust. Rust compiles to a native library and is therefore easier and more lightweight to embed in compiled programs (C, C++) and languages such as js and python.
Another big internal difference is that we use relay URLs whereas tailscale is using relay IDs. The consequence is that every iroh endpoint, no matter if using self-hosted relays, the n0 public relays, or the n0 paid relays, can reach any other. In tailscale two nodes will only be able to talk if they use the same mapping from relay id to relay ip address, which usually means that they use the same coordination server.
Last but not least, while we do have a commercial offering, everything you need to run iroh is open source, licensed MIT and Apache2. With tailscale the coordination server is closed source and operated by tailscale, and the only way to run your own tailnet is to use the headscale community project.
Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.
Then it's no longer p2p? If I wanted to avoid paying cloud egress costs, then I would need a p2p solution.
>Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.
Naturally, but this thread isn't about Tailscale, its about Iroh. You were the one that claimed Tailscale can already do what Iroh can. But I've pointed out a usecase where Tailscale wouldn't suffice that Iroh can accomplish.
I think this tech (modern p2p) represents what agent-to-agent (a2a) should be built on.
Every agent should be reachable to each other without hosting itself as an http server.
related prototypes
https://github.com/eqtylab/agentbeam
https://github.com/eqtylab/real-a2a
https://github.com/Nuhvi/pkarr/
This doesn't really make a lot of sense. Assuming this is true, its equally likely to be my gateway, or BGP peer IP that breaks. How Iroh offers anything in this scenario is beyond me.
>The power of that key can't be overstated. We use it to secure the connection. And because all data that comes from the connection is secured by that key, we can build up from that same key into identity, permissions, and attribution. We can also use that same key as an address we can dial, no matter where it is in the world. It turns the internet into a secure localhost.
This is a way better use case. This should be the headline.
If they are behind different CGNat, you need a party that is reachable by both to help with hole punching and/or relay traffic. This is fundamental, there is nothing you can do about this.
Some p2p protocols try to enlist other peers to be that third party. E.g. holepunch.to . Iroh uses dedicated relays for this.
The relays can either be the n0 public relays, a n0 paid relay network, or self-hosted relays. No matter which option you choose, every iroh endpoint is able to talk to every other iroh endpoint unless they are fully airgapped from the internet.
From what I see, relay servers are doing a job that is equivalent to Stun + Turn + SignalingServer in WebRTC.
This is great for simplicity, but having Stun Turn and Signaling live in the same server would make it harder to secure. For example, since in webrtc signaling is up to the user, it is most common to have signaling implemented as a web server, this allows you to have it behind cloudflare with the signaling server ip never exposed to the internet. If you are not interested in supporting turn, there is plenty of public Stun servers that can be used and Stun itself is a really cheap server to run.
For iroh, it seems if I wanted to self host relay servers I'd be forced to expose their IP to the web which would make them really expensive to run if one wanted to make them DDoS proof.
We constantly have issues with our printer. I have fewer issues with my bambu 3d printer than with my (also very expensive) epson inkjet.
These people need to get their shit together, seriously. The way things are going we will have full AGI before we have working printers.
If somebody want to do this, please reach out to us. We are eager to help. But this is one of the most annoying things ever with computers.
Seems like it'll be a hard sell since steam is already so dominant and enterprise is dominated by tailscale... I see the proposal for being able to work with many different networks from different companies at the same time, but it's a pretty rare usecase and nothing some iptables can't solve.
I can see the argument for chat in heavily censored regions of the world, but not sure if there's any advantages that iroh can offer over other solutions.
Market fit will be hard to find, but best of luck.
Here there seems to be no mention of ddos mitigation or shorter routes due to infrastructure. Yes you need a key to connect but your iroh relay server can still be attacked. I suppose you could roll your own distributed anycast system for this.
Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.
IE could I get an app on my phone, to talk to anyone on the planet with that app directly without having to trust any middlemen like Apple, Google, WhatsApp etc?
Could people have something like original facebook, but without Meta because of actual p2p?
SDK https://github.com/SalvatoreT/iroh-ts
Examples
- https://salvatoret.github.io/iroh-ts/examples/chat/
- https://salvatoret.github.io/iroh-ts/examples/debug/
- https://salvatoret.github.io/iroh-ts/examples/poker/
I made this a while back because I want an easy way to throw together games for family game nights.
I'm slowly trying to build an app on Iroh; it's progressing tiny bit by tiny bit, but I must admit I'm struggling a lot all the time, both with various low-level details, as well as with understanding many high-level aspects, concepts, and approaches. Oftentimes I have to resort to some LLM-generated "wiki" websites to help me progress. I really hope you'll manage one day to allocate some more resources to improve the docs. That said, when I manage to muster enough strength, I do manage to grind some progress, and also it's good to know the underlying tech seems robust, given how many real-world solutions you've built on it!
At this moment, if I can try to ask one question: AFAIU Iroh emerged from an attempt at fixing IPFS. I also understand you've since focused more on providing the lower-level building blocks that would allow this and other solutions. Understanding some basics, but still having hard time to get a really solid grasp of the whole of Iroh, I wonder: between Iroh, p2panda, and Willow, what's available and what's missing / needs to be added if one wanted to try and build an "IPFS-like" with those technologies? I'm especially interested in an idea of a "new web" that would defuse DDoS of static websites in a Torrent-like way, forcing the downloading peers to also share their upstream bandwidth while doing this. I'm also thinking of e.g. a "globally-distributed Internet Archive", where I can easily download part of the Archive to my computer, and this automatically improves its availability on such "new web" for subsequent downloaders and browsers. Would you care to give a newbie something of a high-level overview of how one could try to do it over maybe some appropriate combination of Iroh+p2panda+Willow+DHT?
If you want something like a globally distributed internet archive you would have to use protocols on top of iroh. For example iroh-blobs provides verified streaming of content-addressed data using the BLAKE3 tree hash function. It is very close to itself being 1.0 (probably Q3), but for now it requires you to know from where to stream the data.
What is missing to fully replace IPFS is a global distributed content discovery system. This is a really hard problem that IPFS itself never solved reliably in my opinion.
I also still want this to happen eventually, but the first step is to get the connection layer super reliable and fast, which we have done.
I wish you could also delegate this problem to the mainline DHT, but alas that is not possible because of some mainline limitiations. So I am working on the side on a new DHT, see https://www.iroh.computer/blog/lets-write-a-dht-1
Have you seen https://github.com/bittorrent/bittorrent.org/pull/174 - does that address the main issue?
Sorry if this has been answered or covered on the web I'm currently travelling.
Edit: I managed to read the linked page, thank you for working on such an amazing project!
But I can say that some form of global content discovery is in my personal definition of done for the project. I'm the BLAKE3 guy at n0, and I don't consider blobs done without global content discovery.
But it is a hard problem, and our standards for "it just works" are pretty high.
However, I'm confused on the open source vs. commercial offerings. How do they differ? How do they work together?
In addition we provide services that any commercial deployment using iroh will probably find essential: observability and a custom non rate limited relay network, as well as priority access to the engineering team.
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-...
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.
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.
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
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_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.
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
As of now relays are completely self contained and pretty dumb. The protocol does not require relay to relay communication, which means that the relay code can be relatively simple.
The fundamental component of Iroh is p2p routing by key, and the main utility provided by Zenoh is message semantics. The two seem complementary.
Congrats iroh team!
Regarding security, one thing to be aware of is that iroh connections are just standard QUIC connections secured using standard TLS with the (also standard) raw public keys in TLS extension.
We don't roll our own crypto. What little non-standard crypto we had previously was removed on the path to iroh 1.0.
So iroh connections are just as secure as the QUIC/TLS connections your browser makes to your banking app. Whenever there are some new concerns like for example post quantum security, we can benefit from industry standards.
E.g. we do already support optional post quantum key exchange to secure connections.
https://www.iroh.computer/blog/iroh-post-quantum-handshakes
[0]: https://github.com/n0-computer/iroh-c-ffi
pipe over network using Iroh
Also, for educational purposes, the first version was about 150 lines
https://github.com/n0-computer/dumbpipe/commit/f64d4c3e772a2...
This isn't Tailscale because it does secure P2P connections between any pair of devices, whether or not they have Tailscale. This enables real end-user P2P for, e.g., local-first apps with no server infrastructure except relays for resilience. And even if you lose the relay servers, things keep on working the same for any hosts that don't need them.
For example: dns control, tls certification bans (just this month both let’s encrypt and globalsign started revoking Russian certificates), once google starts really complaining about https it gets ugly.
Russia aside, anyone else is closely watching (europe, brics, what have you)
E.g. you could write an excellent encrypted chat app using iroh, the Tor or Nym custom transport, and BLE or direct wifi for local connections.
You have to be careful though to make sure you configure the transports correctly in order not to expose data you don't want exposed. Iroh can be used in highly restricted environments, but the defaults favour performance over complete metadata privacy.
How does it support semi-connected devices, intermittent connection failures, etc?
Iroh is built for environments where connectivity is unreliable or intermittent, so it can be a good fit for use cases involving connection failures, offline periods, or semi-connected devices.
We provide a range of peer-to-peer protocols that don't require a central server, including key-value stores, blob transfer, collaborative documents, and streaming audio/video. These protocols are designed to synchronize devices back to a consistent state, even after long disconnections or network interruptions.
If you'd like to explore whether iroh could work for your use case, we're happy to chat. Feel free to email us at support@iroh.computer, and we can set up a call.
Up to now our users are mostly teams that have a rust or C/C++ core, such as https://delta.chat/ . But now that we have bindings teams who use other languages should be able to use iroh.
So you can write e.g. an android and ios app that uses iroh direct connections under the hood, and the app user does not have to know or care about this at all.
About tailscale: It's similar, but iroh is not a VPN, so it doesn't add a TUN interface. Instead, you'd build iroh directly into your application. Using iroh you can build a VPN, and there are projects that do so (iroh-lan/iroh-vpn are some hobbyist projects). The upside of building it into your application is that it doesn't need special permissions and is easy to ship to the user.
Besides, as a lot of people have mentioned already, if you want a dedicated server there are a lot of existing options.
We did write a few small dedicated applications to show off iroh, sendme https://www.iroh.computer/sendme and dumbpipe https://www.dumbpipe.dev/ .
A wonderful chain to link to the CBDC shackle.
Iroh addresses are (currently Ed25519) keys. They are not scarce, so you can create them on demand and keep them as you move from one network to another.
If IPv6 was everywhere I guess the hole punching feature of iroh would become less important, but the dial by key feature would remain just as important.
Is there an android SDK available?
IP isn't going anywhere any time soon, but we add two capabilities on top. The ability to dial an endpoint by key, and the ability to get direct connections whenever possible.
That being said, if some other technology becomes popular that actually replaces the IP address paradigm, iroh is well positioned to make use of it. From the point of view of an iroh application developer nothing would change. You still dial by key, and iroh will just make sure under the hood to get you the best possible connection, IP or otherwise.
I've just learned about it, but my understanding is that Iroh is L7, compared to e.g. tailscale which is L3
I think that with Kotlin support, the creation of some android/multi-platform gui apps can be made easier if they want to use Iroh.
A great thing about iroh is that due to it being just QUIC, when you learn about iroh you also learn about details of QUIC that are useful and transferrable for traditional p2p QUIC connections.
is it like torrent
Also, they are very principled when it comes to peer to peer purity, whereas iroh is a bit more pragmatic. We use dedicated relays to faciliate hole punching, whereas holepunch tries to use other peers as a temporary relay for hole punching messages.
Another difference is that holepunch have their own DHT, where we have a less decentralised address lookup service by default and use the mainline DHT as a fully p2p alternative.
So TLDR if you are doing js in the browser, holepunch.to might be a good fit. If you work on native mobile apps or embedded devices, iroh will be better since it is pretty frugal. If you work with node.js, both will work. Just evaluate them both and use what works better for you.
E.g. we support tiny embedded devices such as esp32. https://www.iroh.computer/blog/iroh-on-esp32
If there is enough serious demand we could publish go bindings. Iroh is a rust library that is very easy and efficient to embed into golang binaries.
> IP addresses can break, without warning, and it's outside of your device's control.
We have DNS?
> Keys, however, are created & controlled by you. They stay the same as your device moves, and are yours to throw away, or not.
So are domain names? This page does not do a good job of helping me find what it is that I'm missing.
Iroh gives you the connectivity of DynDNS without any manual configuration.
We charge you for hosted relays and additional insights into your deployment, but the core is and will always remain free. Everything is licensed MIT and Apache2.
So in theory a go implementation is possible using a go QUIC implementation that supports the multipath extension.
Our focus is the rust implementation, since it is very easy to use from compiled languages such as rust, C and C++ and to embed into languages such as js and python.
But there are some other projects that attempt to provide a native go implementation: https://github.com/tmc/go-iroh
Edit: since iroh is just a library, it is also possible to link iroh into a go program. Linking a go program from other native languages is a bit of a pain, but linking a C or rust library into a go program is relatively straightforward and high performance.
Wouldn't that an obvious use case? or am I missing a technical limitation?
- [0] https://github.com/n0-computer/awesome-iroh#file-sharing
That being said, if IP ever gets replaced, your iroh based app will continue to work pretty much unchanged. Iroh will just get you the best possible connection (IP or whatever) under the hood.
Our QUIC implementation noq is a standards compliant QUIC implementation that in addition to RFC9000 also implements the QUIC multipath draft RFC.
We try very hard not to invent new things unless absolutely necessary. In a few places we had to implement draft RFCs, QUIC multipath and QUIC NAT traversal. And there are some corners where we had to add our own extensions. But we try very hard to keep this to an absolute minimum.
Also you can join our discord and there's #showcase https://iroh.computer/discord
But as someone who's not a network specialist, I fail to see how this is not a glorified P2P DNS.
Maybe this example helps:
https://github.com/n0-computer/iroh#rust-library
IP addresses break, dial keys instead
Modular networking stack for direct, peer-to-peer connections between devices
iroh establishes direct connections whenever possible, falling back to relay servers if necessary. Get fast, efficient, reliable connections that are authenticated and encrypted end-to-end using QUIC.
https://datatracker.ietf.org/doc/html/rfc7250
In the beginning of the project we did use self-signed certs, but due to raw public keys that is no longer necessary. And in any case scary build flags aren't an issue since we control our own rust QUIC implementation, noq.
Our default enabled address lookup service is using DNS in a creative way, but we also have a service that is fully peer to peer and is using the mainline DHT, specifically the bep_0044 extension that allows you to store a tiny bit of arbitrary data for an Ed keypair that you control.
https://www.bittorrent.org/beps/bep_0044.html
https://pkarr.org
Some custom transports such as TOR hidden services have a discovery system built in. In these cases we can just use the existing discovery system.
See for example https://github.com/n0-computer/iroh-tor-transport
So basically they want to find out who is who. In other words: sniffing.
It's interesting how the discussion is currently shifting to meta-explain why sniffing is necessary. I noticed this at universities in the last years; people now either have a tablet or a smartphone or a yubico key. This will be extended in the future, there is no doubt about that. And they are selling it with fancy words, just as Iroh showed.
None of them require an API key.
https://github.com/n0-computer/iroh/tree/main/iroh/examples
https://github.com/n0-computer/iroh-examples
Our commercial offering provides more insight into your iroh deployment as well as a hosted relay network. At the enterprise tier you can also get priority access to our engineering team.
Obviously we want to make people aware of these services. But we also have projects that use iroh at large scale without using iroh services.