HN Reader

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

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

I was never angry with you. I was sad, because I was afraid you'd lost your route.

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.

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!

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.

How does this compare to libP2P? https://libp2p.io/

hey I work on this! AMA!

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.

these guys also have some really nice distributed systems explainer videos

The promise of this is super interesting. How would people compare it to libp2p? Is libp2p a lower level toolkit that leaves the assembly to you?

I've been wanting something like what Syncthing does for peer discovery for a while - something like this. Too bad it's written in such a low-level language.

I'm using GunDB (for my still in-development project), what would I need to migrate from GunDB to Iroh?

Does this always have to be p2p or does it also allow for client server architecture

This is what GIT should had from start ! Imagine...

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