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.
That amazement is due to one of our largest and least realized critical mistakes as a civilization: no where are people taught how to effectively communicate. We have entire Colleges of Communications at every university, and what do they teach? How to execute mass manipulation, not how to convey understanding, not how to manage disagreements. These are not "mistakes" either, this distinct lack of teaching real communications is how society is maintained manipulative. And the worst part, many of you will read this and not understand, because you've not been taught the communications insights to grasp this message.
I think my college technical writing course covered these things quite well. It's not that they're not taught, it's that communication skills are not rewarded the same way that marketing skills are. Generally speaking there's a lot of blame to be placed on the universities, but in this case it's an HR oversight.
A technical writing class is learning the alphabet, and does not really touch the nuance, the subtleties in certain topics that make them very difficult to communicate.
Any topic with unknown aspects (to the audience) or controversy require special handling because in that uncertainty people's personalities step in, and that is the seed of misunderstandings becoming institutionalized.
When an individual has gained group prestige from their "theory" being accepted, they then guard that prestige with omissions of information that counteract their position, and deferment of blame when proved incorrect. This is the ordinary human response, and will play out unless the participants have formal communications training that break this pedestrian cycle.
Communications is far more than just "communicating with another". Self communications is the gargantuan invisible elephant yet to be realized by larger society, and is the source of gullibility. Group communications has fractal complexities that play out depending on how many participants are trying to collaborate, and their relative hierarchical power verses one another. Entire careers are spent identifying the categories, and this area is largely unexplored, unexamined. It's too interpersonal and laced with extreme levels of power for honest analysis.
And then there is AI: a communications technology that people think is an automation technology, and our colossal communications tragedy is not going to correct this misunderstanding.
It is how I write. This is what happens when one gets 7 college degrees, people accuse you of writing with AI. I've even been accused of rehearsing AI for how I talk; no, that is how I talk.
>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 meme 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.
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.
> 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.
It's still about getting users even if you're not charging money for it. If you want to make an open source thing and don't care about getting users then that's great for you I guess? And there's a good chance it'll stay that way unless you put at least some effort into getting them (eg even putting effort into a readme counts).
Even if it isnt a product, it is still a tool/utility. Those srill have value propositions that need to be communicated for the tool to be used by the people who could utlize it
Imagine if had a nail to drive into a peice of wood, but the onky thing youd ever heard about hammers was either how critical they are in building construction, or about their weight balancing and how much grip the handle has. Youd never know that you could swing the hammer to hit the nail and drive it in
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.
Agreed, I went through the blog post and a few other pages trying to figure out what the benefit of Iroh is since I have never heard of it... was struggling lol.
Oh come on. I guess it can be abused that way but its so cynical. First, i heavily doubt thats the intention here, and secondly, mmost ads are blocked at the rendering stage, rather than DNS. Especially since youtube broke DNS adblocking by serving ads and contect from the same domain
No, it didn't. It shifted the burden of learning the value proposition to first knowing what Tailscale is exactly. And a response of "Duh, that's obvious", perhaps indicates being too deep in the guts of tailscale systems.
The target audience of this comment chain is exactly people who are familiar with Tailscale, aren't familiar with Iroh, and read the linked post.
Such a person (like me) reading that post will have an immediate reaction of "this sounds a lot like Tailscale", but the post doesn't provide a clear answer to "what problem does this solve that Tailscale doesn't?"
The people with that reaction are the target audience of this comment chain. The fact it is upvoted to the top of the comment section here is an indication that there are quite a few such people, and if this is your reaction you're presumably not one of them. (and that is perfectly fine!)
Tailscale is a very well established company in the field, and if you didn't hear tailscale before, perhaps this product would not be so interesting for you, so it makes sense here.
Otherwise, everything would end up being a "Thing Explainer"[0].
A big part of communication is knowing your audience. GP could have spent a bunch of time explaining what an "application" is, what a "network" is, etc. but he knew that most HN users are familiar with Tailscale, so leaning on that prior knowledge let him explain the concept in fewer words. That is effective communication.
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.
You only need to know the public key of the target endpoint.
It will work even on very restrictive firewalls. Even if they outright ban UDP packets, we will fall back to the relay connection which is https/websocket.
Note that here is not a single keypair per machine, but per endpoint. You can have multiple endpoints on one machine.
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.
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.
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.
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.
But headscale is a community project. The iroh relay code is by number0 just like iroh itself and lives in the same MIT and Apache2 licensed repository. You can even embed it into your webserver if you have a special use case - it is very modular.
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.
Say you want to build a Peer to Peer application; chat, file sharing, music sync or whatever, then something needs to be built to communicate between this application running in two different places. While you still need to build the actual protocol yourself ("Users can send messages" etc), how the two instances are connected is handled by Iroh mostly.
Not a stupid question - I was wondering about the same thing, and this gave me easy access to the answer because someone replied to your comment. Thank you for asking :)
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.
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.).
They host a relay server that is available to everyone, but you are expected/recommended to use your own for most use cases, so you will have only depend on open-source code and your own infra.
How do I add firewalls and proxies and logging to iroh connections? How do I revoke and re-issue iroh keys? Can I host iroh relays/gateways on my intranet?
Until these questions are answered iroh will remain blocked.
You don't have to use it. But here are some answers:
Re-issuing keys is as simple as generating a new Ed25519 keypair.
let secret_key = SecretKey::generate(); // takes less than a millisecond
Iroh as of now has no fleet management. So the concept of revoking a key is something you would have to add yourself.
We have extensive logging for iroh. You can enable trace logging and even enable qlog for detailed connection logs. You can view the logs in any qlog viewer. We have written one, but there are others. It is an open standard for QUIC logs.
The iroh relay library and binary are open source just like everything else in the core. You can of course run a relay in your intranet, but the exact details depend on the use case. Get in touch if you have a demanding use case and want us to help.
By logging I mean a gateway/proxy which logs connection metadata, not client side logging. Possibly this is something that could be added to a private relay. With a network of private relays you could form admission controlled virtual overlay networks for each application.
For key revocation, it is necessary to be able to invalidate a server accepting a key, without necessarily having the key. E.g. maybe you have a pre-generated proof enabling revocation.
Observability is super important for organisations. Especially with LLM servers and MCP interfaces popping up everywhere.
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.
OpenZiti has numerous SDKs. If you are a developer and you can integrate an SDK into your application, it 100% is application-embedded. It is incorrect stating that it can't be app-embedded... (i am a maintainer on the project). Perhaps I just don't understand the response?
Oh, hi :) Thanks for responding! This: https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... mentions a "controller url", I'm assuming it's just the particular example then and in reality you could build and ship one golang binary that doesn't require any other external processes to connect the two processes together via OpenZiti?
I’d separate “app-embedded” from “no external coordination.” OpenZiti SDKs are app-embedded: the app can directly dial/bind Ziti services without a local tunnel daemon. Ziti also supports tunnelers and non-embedded options where app modification is not practical. But yes, the app is still participating in a Ziti network with controllers, routers, services and policies.
Iroh is definitely lighter-weight and developer-first, but it is not always “two binaries and nothing else” either (at least from what I have read). Once you need arbitrary peers across NATs/firewalls, you may need relays, address lookup, relay URLs/tickets, and for production likely dedicated/authenticated relays.
So to me the distinction is not “embedded vs not embedded”; both can be embedded. It is “P2P connectivity substrate” vs “governed zero-trust service overlay.” Iroh optimises for low-friction key-based peer connectivity. OpenZiti optimises for centrally governed, least-privilege service reachability, including identity lifecycle, revocation and policy control at fleet scale.
Note, I also work for NetFoundry, which develops and maintains OpenZiti.
> Iroh is definitely lighter-weight and developer-first, but it is not always “two binaries and nothing else” either (at least from what I have read). Once you need arbitrary peers across NATs/firewalls, you may need relays, address lookup, relay URLs/tickets, and for production likely dedicated/authenticated relays.
Indeed, for hole-punching you need something external, I don't think anyone found an mechanism to do it without some "signaling" server or similar, if it's even possible at all.
> OpenZiti SDKs are app-embedded
I think this is a good clarification, the SDKs that communicate with OpenZiti are app-embedded, while the server/coordinator/whatever runs somewhere else. That's why the comparison with Iroh feels weird, as both the SDK+"server" runs embedded in the application (except if hole-punching is needed, then some external signalling server is needed, as mentioned earlier), so it is in practice, what the developer cares about, two binaries and not much else.
> So to me the distinction is not “embedded vs not embedded”; both can be embedded
This is where you lose me and others, as when they talk about Iroh being embedded, they do mean everything you need to say run a P2P chat application on two computers, there are usually no URLs/coordinators/whatnot involved there (again unless hole-punching is needed), while with OpenZiti you need that chat application + OpenZiti running. The distinction people are trying to understand is very much this, so it's confusing when you call it "embedded" while still having an external thing running alongside it.
I dont disagree with any of that. I am thus thinking, I think the cleanest distinction is probably not “embedded vs not embedded”, or even “relay vs no relay”.
It is: who is supposed to control admission to the service?
Iroh seems great when the app itself wants lightweight peer connectivity: keys, protocols, NAT traversal, optional relays, and the application decides what those peers are allowed to do. That is especially attractive for local-first, ad hoc, P2P, or cross-party cases where there may not be a shared operator or prior trust relationship.
OpenZiti starts from a different assumption: there is a service owner/operator who wants to define which identities may reach which services, under which policies, with central lifecycle/revocation/routing control. In that model the controller/router fabric is not accidental ceremony; it is where the zero-trust service network is governed.
So I’d say Iroh is closer to “embed P2P connectivity into the app.” OpenZiti is closer to “embed a zero-trust service edge into the app, while the app participates in a governed overlay.”
Both are useful; they just optimize for different trust and operating models.
That said, I also dont think its useful that many in this thread are saying, more or less, 'Iroh is Tailscale at the application layer instead of the network layer'... based on my understanding of Iroh, which you have helped with, its not that at all as Tailscale also aims to provide centralised governance and orchestration.
At this time OpenZiti still operates in relay pattern. All your traffic travels through an OpenZiti router. It's also a zero trust overlay so having an external server is important to make policy decisions about whether an identity is authorized to dial a service or not. OpenZiti also allows for bespoke pathing via OpenZiti routers so that path traversal over the overlay is also coordinated.
The project has been moving to supporting directly connecting to other identities but it hasn't been a priority yet.
The connections an OpenZiti identity makes to another OpenZiti identity are direct-over-OpenZiti (not direct over IP underlay) if that makes sense. I don't know if you'll ever be able to have two process communicate without that third 'arbiter' process (I'll call it). It might happen, but right now it seems less likely than the direct connect approach.
hope that helps. But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.
> But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.
Yes, but that's the thing, when people say "Iroh lives in the app" they mean the entire thing, the relays are optional hole-punching mechanisms, otherwise it is distributed P2P embedded in the app. It's slightly confusing when you claim OpenZiti to be the same, with "fully app embedded" but in reality there is a server/overlay/controller/coordinator running somewhere that isn't actually embedded in the app.
I'm not saying the idea is bad, I think both have their use cases, OpenZiti seems like a solid project otherwise, I'm not trying to say it's a bad choice. I'm merely trying to help you, as an outsider, to maybe use/don't use certain words/definitions when you talk about it as it gets confusing then once you actually start looking at the code and things look very different from the expectations you set.
I do wish you luck with the project, all sorts of P2P projects are needed and they all have their place, I don't think it's a "one eats them all" ecosystem, and the more the merrier :)
I appreciate your thoughtful reply and I didn't think you were tossing any shade for what it's worth. I was just arguing that to me, both are "app embedded". IMO, the fact that traffic relays or not to me is non-consequential, what's important is where the encryption starts and where it ends (and where authorization happens but that's also separate). If it starts the client and ends at the 'server' then it's fully e2ee -- it doesn't matter if traffic traverses only IP-based underlays or if it traverses over an overlay at that point.
I very much appreciate the "outsider" perspective though and thank you very much for sharing it. That perspective is impossible to obtain after you work on a project for long enough! :)
A much better answer to the question "why not just use Tailscale?" is that critical functionality only is available with cloud hosting, self-hosted headscale just doesn't offer a usable solution.
> 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.
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 a very different purpose.)
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.