[HN Gopher] Iroh: A library to establish direct connection betwe...
___________________________________________________________________
Iroh: A library to establish direct connection between peers
Author : gasull
Score : 117 points
Date : 2025-06-25 16:34 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ridiculously wrote:
| I was never angry with you. I was sad, because I was afraid you'd
| lost your route.
| softfalcon wrote:
| Sharing tea with a fascinating stranger is one of life's true
| delights.
| dignifiedquire wrote:
| this made my day
| schainks wrote:
| Failure is only the opportunity to begin again. Only this time,
| more wisely.
| tyoung wrote:
| Makes me cry everytime.
| ventare wrote:
| This may be, the worlds most perfect comment. Bravo.
| kubafu wrote:
| I came here for this. Thanks!
| conradev wrote:
| Iroh is very cool and their YouTube explainers are pretty great:
| https://youtube.com/@n0computer
|
| I just need good FFI now, which is on the roadmap!
| makeworld wrote:
| Can't wait to be able to use it in Go or Python :)
| aquariusDue wrote:
| I attended a workshop for iroh a while ago and really enjoyed it,
| and from what I can tell on the Discord server the folks
| developing it are gearing for a 1.0 release soon-ish.
|
| There's also Dumb Pipe and SendMe which are demos (I believe)
| built on iroh to showcase some of its uses, and at the workshop
| we were shown a video of a startup using iroh for video game
| streaming (something similar to the old OnLive).
|
| From what I understood (in spite of my lack of networking
| knowledge) and if I remember correctly clients have to be on the
| same relay (I think there's one for Europe and one for North
| America) and they use the Bittorent DHT Mainline (I had to google
| the iroh blog post about it because I forgot the exact name) for
| discovery. There was some stuff about BGP too, but it went over
| my head sadly.
|
| I hope somebody more knowledgeable chimes in because iroh is
| really exciting, I feel like I could throw together a p2p
| application and it wouldn't be a daunting task due to it.
| b_fiive wrote:
| (disclosure: I work on iroh): you're selling yourself short!
| All of this is accurate, except for maybe the BGP stuff :)
|
| Dumb Pipe & Sendme me are indeed demos, we do provide a set of
| default, public relays to use for free. The relay code is also
| open source, and if you want to pay us we can run a network for
| you.
|
| We try to provide a few different options for discovery, the
| one we think has the most general utility is a custom DNS
| server, but both local mDNS and Bittorrent Mainline are also
| pluggable options.
| b_fiive wrote:
| hey I work on this! AMA!
| xeonmc wrote:
| 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.
| b_fiive wrote:
| 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
| binary132 wrote:
| 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.
| dignifiedquire wrote:
| we do have https://github.com/n0-computer/iroh-c-ffi which
| is lowlevel but directly usable from any c like language
| pluto_modadic wrote:
| do keys have a defined prefix or identifier? e.g., Veilid uses
| vld0? pkarr uses pk:?
| b_fiive wrote:
| 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
| rklaehn wrote:
| 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)
| rrauch wrote:
| 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!
| ndyg wrote:
| Iroh is intriguing. Dumbpipe is magical, and its implementation
| is easy to understand. I use dumbpipe daily to expose cross-
| stream (https://github.com/cablehead/xs) stores I run on
| different servers to my local laptop's `xs` client.
| cprecioso wrote:
| A bit off topic I guess, but what's your usage for xs? I read
| the website, I think that I understand it and find it
| intriguing, but I'm not sure what one would use it for.
| bestouff wrote:
| This thing is written in Rust. I wanted to use it on an embedded
| system in Rust (Embassy) using a CAN transport but unfortunately
| there's neither a no_std version nor a CAN plugin. Otherwise it
| looks good.
| b_fiive wrote:
| Yeah, no_std is going to be _very_ hard. We need a no_std
| implementation of QUIC that can be wielded by mere mortals
| first, which I don 't think we'll be able to start on for at
| least a year.
|
| Right now we can get down to an ESP32, which we think is a
| decent start.
| akavel wrote:
| Hm, how does this answer relate to the answer you gave to
| this comment: https://news.ycombinator.com/item?id=44381084 ?
| where, as far as I understand, you say it's possible to swap
| out quic for something else? asking sincerely, I'm confused
| here.
| b_fiive wrote:
| ah very sorry, I can see how this isn't all that clear. In
| the comment you've mentioned when I say "custom protocol" I
| mean a custom QUIC ALPNs:
| https://datatracker.ietf.org/doc/html/rfc7301
|
| When we talk to mainline it's for discovery, which is
| separate from iroh connections, which always uses QUIC.
| Specifically: our fork of quinn, an implementation of QUIC
| in rust. Iroh is tightly coupled to quinn, and isn't
| swappable. Getting no_std support for us basically boils
| down to "can we get quinn to support no_std?". For that,
| see: https://github.com/quinn-rs/quinn/issues/579
| dignifiedquire wrote:
| this would be great to have, but as we rely heavily on quic, we
| first need an implementation of quic in no_std which is the
| current biggest challenge
| b0a04gl wrote:
| lets say if i someone wants to keep using bittorrent dht for peer
| finding but swap out quic for something else maybe grpc, does the
| lib support that split clean? asking from a modular embed first
| tooling pov, where discovery logic needs to outlive or outswap
| transport depending on deployment
| b_fiive wrote:
| yep totally doable. You'd use iroh configured with mainline,
| Then write a custom protocol for the grpc bit:
| https://www.iroh.computer/docs/protocols/writing
|
| We use this a bunch for writing rpc protocols on iroh:
| https://github.com/n0-computer/irpc , but there's no reason you
| couldn't write one with grpc.
| eminence32 wrote:
| Some years ago, "iroh" was supposed to a replacement for ipfs.
| However since then, they (very smartly, in my opinion) dropped
| those ambitions and are just focused on being a high-quality
| library for anyone writing a P2P app (like ipfs).
|
| I often see projects attempting to be a universe tool to solve
| every possible problem, and I think the iroh folks were smart to
| scale back and narrow their focus
| dignifiedquire wrote:
| appreciate the feedback, it was a hard decision to make, but
| has felt more right everyday since we made it
| Ingon wrote:
| I work on connet [1] and from what I've seen iroh seem pretty
| cool. A few random thoughts I had while watching the
| presentations/reading the docs:
|
| * the relays serve both for discovery and relay. In connet these
| are separate responsibilities, e.g. it has control server for
| discovery and a relay server for relaying connections.
|
| * it seems that the connections to the relays in iroh are TCP (at
| least what was said in one of the videos), while connet uses QUIC
| in all cases. This probably makes iroh more resilient, but
| multiplexing on top of TCP might suffer from head of line
| blocking.
|
| * it is pretty cool that iroh can seamlessly upgrade from relay
| to direct connection, connet doesn't do that on a connection
| level. It will however use direct in the subsequent virtual
| connections.
|
| * using ALPNs for protocol selection is pretty cool, connet only
| offers "virtual connections" protocol, where one of the peers is
| "server" and the other is a "client".
|
| * since there is a separate discovery server (with auth), in
| connet the endpoints are named separately with logical names,
| they don't represent peers necessarily. Because of this, you can
| have multiple peers with "server" role and "client" roles.
|
| Anyhow, thanks for posting this, iroh looks great and I will draw
| some inspiration from it for sure.
|
| [1] https://github.com/connet-dev/connet
| dhash wrote:
| these guys also have some really nice distributed systems
| explainer videos
| Python3267 wrote:
| How does this compare to libP2P? https://libp2p.io/
___________________________________________________________________
(page generated 2025-06-25 23:00 UTC)