I am one of the iroh developers.

A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ...

Iroh as of now supports only IPv4, IPv6 and relay transports out of the box. There is such a large variety of potentially interesting transports out there that we can't support all of them without turning the codebase into an unmaintainable maze of feature flags.

But we have added the ability to implement custom transports. That way your transport implementation can live in a completely separate crate.

Existing experimental custom transports include Tor, Nym and BLE. https://github.com/mcginty/iroh-ble-transport

Here is how custom transports work under the hood: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

I like the idea. A couple of questions:

1. How does Iroh handle key rotation / leakage? Could you build some kind of hot/cold system on top of it, where you'd have a cold "identity key" in airgapped, secure storage, used only to issue certificates for your hot "traffic acceptance" key?

2. Is there any kind of peer discovery / DHT, either built-in directly or through some semi-official higher-level protocol, like DNS for IP?

3. What about human-friendly peer names? Those are almost required for end-user friendly applications. Most solutions of that problem either assume that every single user is willing to dedicate their life to configuring DNS, rely on a trusted third party, or delegate the responsibility to a blockchain.

4. What are the channel reliability properties, and are they configurable? Can you decide how to handle out-of-order or lost packets, or does the protocol enforce a decision? If you're willing to tolerate loss, duplication and reordering, can you avoid head-of-line blocking?

5. Is peer anonymity a goal?

6. What about two mostly-offline peers who wish to communicate (think smartphone apps that can't be connected 24/7 due to battery concerns)?

Overall, cool project.

The future of networking is decentralization. I'm a huge fan of Yggdrasil and I2P. We should just be able to buy a mini PC to run 24/7 and host whatever it is that we need on it and seamlessly connect to others. A lot of techies already have older spare machines laying around collecting dust that can become servers. It is far cheaper in the long run and easier to maintain than having to deal with domains and server hosting. I truly appreciate the work that the Iroh team puts out.

Hoping to use this to reboot an ancient abandoned project. At the time there wasn't a mature P2P connection layer that took care of all the realities of the modern Internet out of the box. Now there is, and it's great to see.

This isn't Tailscale because it does secure P2P connections between any pair of devices, whether or not they have Tailscale. This enables real end-user P2P for, e.g., local-first apps with no server infrastructure except relays for resilience. And even if you lose the relay servers, things keep on working the same for any hosts that don't need them.

I don't understand the problem its trying to solve in the first place, IP works just fine, such as DNS.

There is already IPv6 and quic, you need vendor and major software to have any traction in that field.

Iroh has been amazing to work with and the engineers are so nice in the discord channel. The pragmatic approach to making p2p just work has been easy to understand. Their YouTube channel has great content too. Congrats on v1!

https://youtube.com/@n0computer

Doesn't it seem odd to have "Pricing" for a protocol that's meant to serve a similar function to IP addresses? Maybe I'm misunderstanding something.

Hmm, this really looks more of a relay network for sale, kinda like steam p2p. The only real use-case I see for this is for exactly that, connecting two or more players where one of the players is the host.

Seems like it'll be a hard sell since steam is already so dominant and enterprise is dominated by tailscale... I see the proposal for being able to work with many different networks from different companies at the same time, but it's a pretty rare usecase and nothing some iptables can't solve.

I can see the argument for chat in heavily censored regions of the world, but not sure if there's any advantages that iroh can offer over other solutions.

Market fit will be hard to find, but best of luck.

What about censorship circumvention? Is there specialized DERP to DERP communication, that bridge over internet edge nodes doing DPI on QUIC?

We use Iroh in production at work, and I'm absolutely in love with it. I'd describe it primarily as "Tailscale-style hole punching as a rust crate", but of course you can sprinkle a lot of cool p2p stuff on top of the basic QUIC connections.

To me this sounds like tailscale - does anyone have any insight into how what this is doing is similar or different?

My company was using Iroh for a production distributed ML training system & we LOVED it. The team was incredibly responsive even before we hooked up with an enterprise support contract, they're incredibly knowledgeable and the library itself worked amazingly. ++ to this lib. would use again over libp2p anytime.

Congrats on shipping

You need urgently a "versus" page that talks about tailscale/netbird/netmaker/zerotier/twingate/openziti

Looking at the use cases, right now I don't see anything that cannot be done with Tailscale...

Ive been prototyping with Iroh for awhile.

I think this tech (modern p2p) represents what agent-to-agent (a2a) should be built on.

Every agent should be reachable to each other without hosting itself as an http server.

related prototypes

https://github.com/eqtylab/agentbeam

https://github.com/eqtylab/real-a2a

The "address lookup" strategy is really interesting, especially how it uses actual DNS: https://docs.iroh.computer/concepts/address-lookup

https://github.com/Nuhvi/pkarr/

I wish it had support for a system similar to webrtc's offer and answer SDP messages.

From what I see, relay servers are doing a job that is equivalent to Stun + Turn + SignalingServer in WebRTC.

This is great for simplicity, but having Stun Turn and Signaling live in the same server would make it harder to secure. For example, since in webrtc signaling is up to the user, it is most common to have signaling implemented as a web server, this allows you to have it behind cloudflare with the signaling server ip never exposed to the internet. If you are not interested in supporting turn, there is plenty of public Stun servers that can be used and Stun itself is a really cheap server to run.

For iroh, it seems if I wanted to self host relay servers I'd be forced to expose their IP to the web which would make them really expensive to run if one wanted to make them DDoS proof.

LM studio recently released a mobile app powered by Tailscale -- https://lmstudio.ai/link . Iroh seems like a perfect OSS alternative for implementing similar p2p features.

That to me looks like Reticulums [1] adressing ("Destinations") with transport done via QUIC. Does it add anything what Reticulum didn't already solve, other than using slightly different protocols - do they have an advantage?

[1] https://reticulum.network/

Not sure what the difference is between this and any regular P2P network?

I think I see the value prop here. Beyond its intended use, what about creating a full VPN out of it? This takes care of the hard part for a lot of home users, opening your vpn up in a safe way. I know this is solved by many other tools so this isn't a new thing but it may increase adoption. Is there already something like that? I imagine you have considered this and if it doesn't already exist have a good reason for not including it. If so, what is that reason?

This sounds useful, but isn't this the problem that ipv6 is supposed to solve with 128bit addresses? (I'm not really familiar with why IPv6 never really seemed to take off -- does NAT block incoming IPv6 traffic? (I guess that's the other thing -- even though my devices all seem to have IPv6 addresses I can't recall ever using them))

I definitely see the value! But I'm not confident I can tell whether there are e.g., security implications, and I couldn't find anything on point in the docs or on github (other than one discussion on authentication that mentions the information disclosed). Would love a whitepaper on that and any other issues adopters should consider.

This looks really interesting... I think I grok the basic value prop.

However, I'm confused on the open source vs. commercial offerings. How do they differ? How do they work together?

How is that different from https://yggdrasil-network.github.io ?

I wonder if Iroh and Zenoh could/should be used together.

The fundamental component of Iroh is p2p routing by key, and the main utility provided by Zenoh is message semantics. The two seem complementary.

C binding: [0]

[0]: https://github.com/n0-computer/iroh-c-ffi

iroh is consistently one of the most delightful projects i've ever worked with. The people reflect that too.

Congrats iroh team!

This is big > We built & continually check that iroh can compile to WASM & run in the browser

hey, I helped make this :) will try to answer questions where I can

Nice video production, but as you can see on this thread of nerds, the messaging is not clear.. Content first, presentation later.

So this could be used as a streamlined way for client devices (mobile phones for example) to phone home to servers (google.com for example) with user data and bypass some local network controls? (DNS block lists, for example)

Is there an android SDK available?

Honestly I am happy that more remote access products are using QUIC, not WireGuard, for tunneling and realizing its technical benefits (e.g. AES hardware acceleration, dynamic endpoints, custom auth with JWT or mTLS, FIPS compliance, traffic masquerading as HTTP/3, etc.). I am a big fan of QUIC myself and I implemented it long ago in Octelium, which is a similar remote access product that's more centered around access control and zero trust rather than P2P connectivity. I believe QUIC should be the future of tunneling, especially when it comes to business and enterprise remote access use cases. Congrats on launching an I wish you the best of luck.

How is this different from https://holepunch.to/ ?

I'm out of my technical depth here, but out of curiosity: is this meant to be a full replacement for the current IP address paradigm, or is this meant to be a specific tool on top of/alongside IP addresses that solves particular problems/frictions?

Good for Iroh to have libraries within different languages.

I think that with Kotlin support, the creation of some android/multi-platform gui apps can be made easier if they want to use Iroh.

Is the intent to replace the IP protocol ever?

Netbird offers the same. Just based on wireguard and everything is open source.

I love it. I think. But I find it hard to parse tech videos with music in the background.

Missing a native go version

Is what?

So what has the reception been like with IETF?

What are people building with Iroh?

> And because all data that comes from the connection is secured by that key, we can build up from that same key into identity, permissions, and attribution.

So basically they want to find out who is who. In other words: sniffing.

It's interesting how the discussion is currently shifting to meta-explain why sniffing is necessary. I noticed this at universities in the last years; people now either have a tablet or a smartphone or a yubico key. This will be extended in the future, there is no doubt about that. And they are selling it with fancy words, just as Iroh showed.

This page is basically useless in explaining what Iroh is or does and why I should care.

I am confused why this is needed.

> IP addresses can break, without warning, and it's outside of your device's control.

We have DNS?

> Keys, however, are created & controlled by you. They stay the same as your device moves, and are yours to throw away, or not.

So are domain names? This page does not do a good job of helping me find what it is that I'm missing.

So is this like an unfree CJDNS? What are the main differences?

I should read the specs, but since it's such a foundational issue maybe someone who knows could respond briefly? the problem with a flat addressing space is that it requires every intermediate node to have state about every address, or perform a costly discovery mechanism for those it doesn't know about. is there a clever answer to this?

reticullum is better, and faster

Sounds good, but the first step in your quickstart is getting an API key, and I'm oh, so I guess your sales pitch was a lie and this is really just another Cloudflare-like play to build another intermediary in the internet. If that's not the case, then I shouldn't need an API key for hello world...

Were all building the exact same shit.

[dead]

[dead]

[dead]

Looking at the pricing page, how can this be the future, maybe the post was written in 1998