Iroh 1.0(iroh.computer) |
Iroh 1.0(iroh.computer) |
None of them require an API key.
https://datatracker.ietf.org/doc/draft-ietf-quic-load-balanc...
Get in touch if you have a demanding use case and want us to help.
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.
I've just learned about it, but my understanding is that Iroh is L7, compared to e.g. tailscale which is L3
From the OSI point of view, QUIC itself is a bit of a layering violation. It covers transport (L4, Reliable ordered delivery, stream multiplexing, congestion control, ...), session (L5, connection establishment and lifecycle, path migration, ...) and presentation (L6, encryption).
And of course below that we have the ability to provide custom transports.
This was done intentionally in QUIC to provide more control. The application layer doesn't have to care about what goes on below, but for some advanced use cases it can know what's going on and even influence which path is being used.
QUIC/TLS being such a comprehensive and well tested package allows us to delegate a lot of the work and just add a tiny bit of logic to make it peer to peer.
Although delegate is not exactly right, since we ended up having to write our own QUIC implementation, noq, to support QUIC multipath...
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.
is it like torrent
Also you can join our discord and there's #showcase https://iroh.computer/discord
But everything we do is open source as well. Everything in the core is MIT and Apache2 licensed, including the relay binary/library.
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.
pipe over network using Iroh
Also, for educational purposes, the first version was about 150 lines
https://github.com/n0-computer/dumbpipe/commit/f64d4c3e772a2...
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.
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.
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
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
Application 1 has a Ed25519 keypair
Secret key private 3085c7405a88a968133e813e9f638a7d9b2e8088fe717ca535cc24d90b59815d
EndpointID or public key, for connecting to you: 274d4c656f064d4c59fffe7db38d6bf90d63cb087d0b2afd2cfa534334f7071c
and for connecting to App 2 you need to know the other endpoint id, no friendly "dnsish" name involved.
https://en.wikipedia.org/wiki/Zooko%27s_triangle
A mapping from a scarce but human readable name to a non-scarce but not human readable name would't be that hard, but we haven't done this yet.
If we do it it will probably be an additional crate reusing some of our infrastructure, not built in to iroh itself. There are a lot of use cases where the non human readable names work perfectly fine.
We would implement two versions, one using DNS and one using an appropriate decentralized system like ENS.
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.
Is there an android SDK available?
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
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;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.
Again, the difference is: tailscale/easytier/wireguard creates a VPN network on your computer/phone/whatever. So all apps can benefit of it
iroh is a library . This is for developers who want to integrate this P2P routing logic inside their app. It is closer to bittorrent than it is to tailscale.
Both approaches are great but fulfill completely different needs.
I think you should highlight more the IoT use case, It's a really great solution for devices that need to talk over multiple transports (Lora + IP) and to avoid the need for a VPN.
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:
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.
We don't have a comparison benchmark, but we are fast enough that we are not the limiting factor for many use cases.
In many cases the performance bottleneck is the interface to the kernel to send and receive UDP packets. Our QUIC implementation is using all available tricks to make this as fast as possible. For example on OSX we use the sendmsg_x syscall to send multiple UDP packets in one syscall. On Linux we use GRO/GSO and recvmmsg to send/receive as many packets as possible.
But to be completely honest, in some cases TCP is still faster for raw throughput on server class hardware. Decades of optimisation have gone into TCP. But QUIC/UDP is quickly catching up. All the major cloud vendors bet heavily on QUIC/UDP and are optimizing it.
Since we just do p2p QUIC we benefit directly from all improvements in this area.
I might have assumed io_uring would be the high throughput kernel interface for Linux.
Can iroh run on a proxy server which forwards requests to backends that don't integrate with iroh directly?
What is the CPU overhead at link saturating speeds?
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.
We might do an io_uring based linux only implementation at some point. For now we do care about performance very much, but also want to have a single code base for all supported architectures and platforms.
We do support a lot out of the box, which is hard enough as is with a small team. And while io_uring is a bit better than the current sendmsg with GSO / recvmmsg with GRO setup, it isn't orders of magnitude.
> Can iroh run on a proxy server which forwards requests to backends that don't integrate with iroh directly?
We have a tool called dumbpipe that has options to forward local tcp services over an iroh pipe. Something like global netcat.
And there are plenty of tools that do something similar for specific services, e.g. there is iroh-ssh.
> What is the CPU overhead at link saturating speeds?
We don't have exact measurements, but CPU is not the bottleneck usually.
Congrats iroh team!
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.
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.
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-...
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.
The fundamental component of Iroh is p2p routing by key, and the main utility provided by Zenoh is message semantics. The two seem complementary.
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.
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?
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 iroh endpoint will determine its location in the world by probing the configured relays using QAD (similar to STUN). It will then choose a home relay and establish a https connection to it.
When another iroh endpoint wants to talk they first briefly talk via that relay, then hole punch and establish a direct connection.
All of this happens in the background without the user even noticing. It’s also very lightweight - runs on an embedded computer with 2 megabytes of RAM.
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.
So we got into the sad situation that people associate peer to peer connectivity systems with having to frequently debug the entire stack and having recurrent performance or connectivity issues.
A part of the motivation for the iroh team is to change this notion by being very pragmatic and minimalistic. E.g. the use of relays vs. enlisting other peers to help with hole punching.
Originally, every machine was a directly reachable peer, but a finite supply of addresses (IPv4) forced most devices behind translation boxes (NAT) that let them dial out without ever being dialable. Once traffic had to route through the few hosts that stayed reachable, those hosts became toll booths, which is partially where the more centralized internet we actually got came from.
iroh basically patches the internet
A wonderful chain to link to the CBDC shackle.
Wouldn't that an obvious use case? or am I missing a technical limitation?
- [0] https://github.com/n0-computer/awesome-iroh#file-sharing
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.
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?
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.
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.
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.
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.
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!
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/ .
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.
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 :-)
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
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.
If my understanding is right, content discovery can't happen on the existing mainline DHT which is a shame. Maybe once you have enough traction you can propose a standards change? DHT mainline today is amazing because of its network size.
We would love this to gain more traction so we can use mainline also for content discovery. But we have to be realistic: mainline moves slowly, and for good reasons.
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".
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.
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.
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.).
Until these questions are answered iroh will remain blocked.
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.
https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-main-s... https://github.com/n0-computer/qlog-viewer
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.
+ 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?
> 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.
Just use Wireguard directly like everyone else.
If anyone really wants to use Tailscale (or I think Headscale should work too) at application layer, you can use tsnet [0]
--
0: https://tailscale.com/docs/features/tsnetA 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...
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.
There is already IPv6 and quic, you need vendor and major software to have any traction in that field.
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.
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.
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 love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.
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.
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.
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
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 think that with Kotlin support, the creation of some android/multi-platform gui apps can be made easier if they want to use Iroh.
> 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.
Nothing about Iroh usage as operator or end-user entails billable metering of keys, clients, QUIC endpoints, bytes transferred etc and to be honest you could deploy pretty extensive Iroh-based software without ever having a financial relationship with number0.
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.
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.
The current stuff about dialling is pretty incomprehensible, as shown by the many confused comments here. No one "dials" IP addresses (or keys), and no one wants to, so the word "dial" shouldn't be part of the title or description. The word "key" would be better not mentioned until you start talking about implementation, and the brief high level "what it is" and "what it is for" stuff should come before implementation.
Iroh seems quite relevant to some projects of mine, but after reading the blog post and the main page, I still had no idea of that relevance until I had read over a hundred comments here (many of them confused about what Iroh was).
You can omit the "written in Rust" part, but then you'd lose street cred.
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.
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.
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!
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.
> Tor
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.
How current is the PyPI package? https://pypi.org/project/iroh/
Strategy patterns and code-centralised feature management ftw :)
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.
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.
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.
127.0.0.1 -> 'key' > 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.
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...
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 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.
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.
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.
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.
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.
> 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)?
"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.
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.
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!)
Otherwise, everything would end up being a "Thing Explainer"[0].
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.
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.
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.
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.
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.
Peers _always_ connected directly to transfer files
A third party server kept an index and provided search, it did not forward traffic between peers
https://docs.iroh.computer/concepts/nat-traversal.md
"If NAT traversal fails, iroh automtically falls back to routing traffic through the relay server"
It has not "solved" the hole punching problem any better than anyone in the past
Alas, it does worse than predecessors by adding a non-P2P default (cf. option)
I don't use Iroh so I could be wrong, but the goal is definitely a paid service.
As for anything being a "goal"? They do have dev salaries to pay and they offer managed control planes with SLAs or consultations with the core devs to accomplish that.
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.
The "what is iroh" quesition is answered well in the docs: https://docs.iroh.computer/what-is-iroh
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.
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
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.
They really need to dumb this down to make it accessible if it's going to spread.
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.
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
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.
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.
Check out Jürgen Habermas's Theory of Communicative Action (1981).
It's less that "not all apps need that" and more that "openziti can be app-embedded" is actually completely false.
For this simple scenario (just exposing your laptop to a public IP) there are already a gazillion alternatives (e.g. ngrok)
No, this does not do the same thing as iroh. Not even close.
p2p apps need direct connections.
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?
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.
For me, I find more value in connecting computers together than connecting applications together, but I'm not building P2P apps...
With the relay daemon being self-hostable and OSS any use-case that needs to be more censorship-resistant than that has the option to run their own relays as needed.
(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
peer address → peer ID
(query ID, peer address) → list of [next peer address]
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)
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).
Took a few hours while I was trying to understand what exactly iroh is doing.
It was good to refresh some things in memory along the way, and learn some too :)
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.
But in the long term you probably don't want two fully featured p2p networking stacks in your dependencies.
First iroh was marketed as "solves communication behind NAT". Then we went to application level NAT busting vs node level NAT busting. Then we went to distributed vs client-server, then we went to stable IPs for non-server devices (your original comment). Now we moved to "true peer to peer" and "public keys".
This just tells me that the marketing site doesn't explain what Iroh actually does.
The fact that so many other people (apart from me) asked about the connection to Tailscale is also interesting.
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.
> 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.
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.
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.
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.
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.
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.
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 :)
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.
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! :)
Cheers!
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.