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

Last year, I was trying to choose between the two and went with that I know... but it feels like there's real momentum on Iroh's side.

So you might get a lot of traffic. You can configure rate limiting, as we do on our public relays.

The traffic is fully encrypted and can not be decrypted by the relay. The only information the relay has is what is necessary for it to function - the endpoint id and ip addresses of the endpoints that are connected to it at any given time, as well as endpoint pairings.

You relay encrypted traffic with no egress to the open internet. So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.

Nice. I already do rate limiting, traffic balancing using sch cake. This looks like an interesting project. I could envision open source NVR's implementing this. I also like the name of the project.

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.

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

related prototypes

https://github.com/eqtylab/agentbeam

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

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

Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work.

In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth and the lowest possible latency.

This was not a solved problem until now.

https://tailscale.com/blog/how-nat-traversal-works

p2p apps need direct connections.

Here this is a decentralized network with a lot of existing public relays. But in principle a VPN can solve a lot of the same problems. It's just that commercial VPNs are not decentralized, and doing your own wireguard setup is a pain.

https://tailscale.com/blog/how-nat-traversal-works

This allows you to provide information to an arbitrary person (a friend/coworker/etc) to let them access the thing without them having to jump through all the extra hoops of joining your tailnet/them joining yours/adding a VPN/etc.

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.

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

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.

https://youtube.com/@n0computer

> But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.

Interesting (and somewhat proven) idea to finance it, smart :)

Did you guys started doing this already on a case-by-case basis and have some experience of it already, and if so what are the common things you typically help out with exactly? I'm just curious what sort of things a company who'd use a protocol like that might need help with, that they wouldn't have experience with in-house, since they're going down a P2P road already (assuming that, maybe maybe need help with greenfield projects)?

If you use their offering, you probably get some kind of web interface for metrics that isn't open-source.

https://docs.iroh.computer/concepts/relays https://www.iroh.computer/services/hosting

"we want to be infrastructure for people, and a business towards professionals."

stuck between "we need cash to operate" and "we want to be a public good infrastructural system." , with the negative parts of a for-profit whisked away with "Well it's open source."

it's a business concept i'm okayish with as long as the "Well it's open source." caveat doesn't come with a total bespoke and unusable code base to figure out.

Our code is as good as we can make it, and everything is modular and well documented. For example our QUIC implementation noq which underlies every iroh connection can also be used as a standalone QUIC impl that implements QUIC multipath.

https://docs.rs/noq/latest/noq/

If we wanted to have "total bespoke and unusable code" we would have inlined all of this into the iroh repo to make it unusable.

Tailscale is a great service that happens to be open source, but Iroh is clearly structured as a library that you can build into whatever you want.

I love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.

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.

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.

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

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.

If you look at an iroh connection using wireshark, it is just a QUIC connection. You can use all the existing tools, and a lot of things you learn when using iroh transfers to traditional QUIC connections and vice versa.

Most iroh contributors come out of the p2p world, and you could say that we had a bit of abstraction fatigue after working on regular P2P networks for some years.

We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery.

Note that there are some "regular p2p networks" that use iroh under the hood, e.g. holochain https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-... as well as various p2p chat apps.

https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-...

Mainline is incredibly frugal in terms of resource use, but we want it disabled by default so mobile apps don't look like bittorrent clients and get flagged by the OS.

When we do a p2p address lookup, every mainline server node could possibly be responding. Any bep_0044 record gets stored on 20 random mainline server nodes.

So a bittorrent client that participates in the DHT as a server and is long running enough to be included into the DHT routing tables will respond, yes.

Congrats iroh team!

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

Is there an android SDK available?

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

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

[1] https://reticulum.network/

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.

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.

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.

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.

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.

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.

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

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.

None of them require an API key.

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

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

Our 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