Iroh: A library to establish direct connection between peers

hey I work on this! AMA!

Can this be a made to work as an adapter to play older, raw UDP multiplayer games with random strangers? E.g. telling someone in Twitch chat “bro 1v1 me in CS1.6, here’s my Iroh ticket:”, they put it into their “InstaFrag NetDriver” Windows Client and you both launch CS1.6 and just start playing in an ad-hoc p2p lobby.

With Tailscale this use case is very cumbersome as you’d need to add them to your tailnet and configure access controls to make it an ephemeral connection.

There's no reason this _can't_ be built. The thing that's missing is simulating a raw UDP socket.

We could adapt the pattern from dumbpipe wrapping a TCP listner: https://github.com/n0-computer/dumbpipe?tab=readme-ov-file#t... which is exactly the "here join this ticket" you're describing

do keys have a defined prefix or identifier? e.g., Veilid uses vld0? pkarr uses pk:?

keys are always ED25519, we use raw public key bytes, without prefixes.

Applications are more than welcome to use prefixes, but the use of ED25519 is not configurable

To expand on this: iroh is a rust library. A NodeId is just an Ed25519 public key, but of course it has a distinct type. If in the future we want a different public key standard, it would be a different rust type.

Encoding keys is mostly left to the user. The only exception are tickets. Tickets are postcard serialized and have a version field, so we can keep tickets compatible if we ever want to use a different public key standard or hash function.

(disclaimer, I also work on iroh)

I've been following Iroh's development for quite some time now and I have to say that I've been really impressed with what you've built so far.

At one point I'm going to use Iroh (or something heavily inspired by it) as the transport layer for a project I am working on. Can't wait.

I do have one question though while I have your attention: what was the reason you decided to use the Ed25519 public key as the NodeId directly? I mean, why not derive the NodeId from the public key instead (by hashing it for example)? Then the protocol itself would not be so tightly bound to Ed25519. A little indirection here would have been useful imho.

It's the one thing I have been wondering about Irohs design that I haven't really been able to answer by myself.

Anyways, great work! Keep it up!

This is very much like my usecase too, except that I need to be able to use it via FFI since my engine is not Rust.

we do have https://github.com/n0-computer/iroh-c-ffi which is lowlevel but directly usable from any c like language

We decided to keep things simple. In general we try to provide one good way to do something instead of having a lot of options.

E.g. we only provide Ed25519 for keys and in iroh-blobs only BLAKE3 for hashing, instead of having a multihash scheme. Having the public key directly available is sometimes useful, e.g. for verifying signatures. It also allowed us to directly use the mainline extension BEP_0044 to store data for public keys.

That being said, I am very confident that we will be able to provide a relatively smooth transition if we ever have to switch from Ed25519 to another public key format.

For connection encryption we use a TLS extension called raw public keys in TLS, and here of course the keys are prefixed, and we could easily upgrade to another key format and then at some point stop supporting Ed25519 keys.

raw public keys in TLS: https://datatracker.ietf.org/doc/html/rfc7250 storing arbitrary data in the DHT: https://www.bittorrent.org/beps/bep_0044.html

How do you manage authentication on the discovery/relay side?

Oh nice, thanks for that. Do you think I should hold my breath for a UDP transport or just use it to negotiate direct socket connections?