Iroh 1.0

You explained the value proposition so well. The website just didnt get to the "why?" At all

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.

Until these questions are answered iroh will remain blocked.

+ 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

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.).

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).

[1] https://docs.iroh.computer/what-is-iroh

[2] https://news.ycombinator.com/item?id=48543554

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

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!

    > 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

How current is the PyPI package? https://pypi.org/project/iroh/

Strategy patterns and code-centralised feature management ftw :)

  > 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...

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.

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.

"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.

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.

As an example, AFAIK, Reticulum encrypts packet origin, so only recipient can see them. I don't think this is admissible in a corporate network.

I 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.

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.

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.

Here there seems to be no mention of ddos mitigation or shorter routes due to infrastructure. Yes you need a key to connect but your iroh relay server can still be attacked. I suppose you could roll your own distributed anycast system for this.

Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.

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-...

In addition we provide services that any commercial deployment using iroh will probably find essential: observability and a custom non rate limited relay network, as well as priority access to the engineering team.

If you 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

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.

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

Regarding security, one thing to be aware of is that iroh connections are just standard QUIC connections secured using standard TLS with the (also standard) raw public keys in TLS extension.

We don't roll our own crypto. What little non-standard crypto we had previously was removed on the path to iroh 1.0.

So iroh connections are just as secure as the QUIC/TLS connections your browser makes to your banking app. Whenever there are some new concerns like for example post quantum security, we can benefit from industry standards.

E.g. we do already support optional post quantum key exchange to secure connections.

https://www.iroh.computer/blog/iroh-post-quantum-handshakes

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.

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)

How does it support semi-connected devices, intermittent connection failures, etc?

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.

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.

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.

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.

https://www.iroh.computer/sendme

There are several projects inspired by sendme that use the same protocol but add mobile device support and a GUI:

https://www.altsendme.com/en

https://github.com/ARK-Builders/Drop-Desktop

https://github.com/zignig/sendme-egui

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.

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.

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.

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.

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...

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.

That being said, if IP ever gets replaced, your iroh based app will continue to work pretty much unchanged. Iroh will just get you the best possible connection (IP or whatever) under the hood.

Our QUIC implementation noq is a standards compliant QUIC implementation that in addition to RFC9000 also implements the QUIC multipath draft RFC.

We try very hard not to invent new things unless absolutely necessary. In a few places we had to implement draft RFCs, QUIC multipath and QUIC NAT traversal. And there are some corners where we had to add our own extensions. But we try very hard to keep this to an absolute minimum.

Also you can join our discord and there's #showcase https://iroh.computer/discord

But as someone who's not a network specialist, I fail to see how this is not a glorified P2P DNS.

Maybe this example helps:

https://github.com/n0-computer/iroh#rust-library

    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.

But everything we do is open source as well. Everything in the core is MIT and Apache2 licensed, including the relay binary/library.

https://datatracker.ietf.org/doc/html/rfc7250

In the beginning of the project we did use self-signed certs, but due to raw public keys that is no longer necessary. And in any case scary build flags aren't an issue since we control our own rust QUIC implementation, noq.

Our default enabled address lookup service is using DNS in a creative way, but we also have a service that is fully peer to peer and is using the mainline DHT, specifically the bep_0044 extension that allows you to store a tiny bit of arbitrary data for an Ed keypair that you control.

https://www.bittorrent.org/beps/bep_0044.html

https://pkarr.org

Some custom transports such as TOR hidden services have a discovery system built in. In these cases we can just use the existing discovery system.

See for example https://github.com/n0-computer/iroh-tor-transport

None of them require an API key.

https://github.com/n0-computer/iroh/tree/main/iroh/examples

https://github.com/n0-computer/iroh-examples