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.
There might be a small misunderstanding here. Our relays do two things. They relay user data, and relay a small number of special packets to help with hole punching. Other than that they are very simple. They never see unencrypted data, so they don't know anything more about the nodes they serve than what they need to function.
Connections are TCP https websocket connections, because this is most likely to get through even the most restrictive firewalls.
Discovery is handled outside the relays, via either a special DNS server or via the bittorrent mainline DHT. You can even implement your own discovery.
> * 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.
What are the relative advantages/disadvantages of these two strategies?
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
Aye. You often solve a technical problem while working to build something and later it turns out that building block has more utility than the thing you set out to build.
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.
(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.
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.
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.
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.
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.
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.
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.
Each time I looked at libp2p I didn't even knew where to begin. With Iroh it was trivial to get connections.
Also, AFAIK, Iroh makes some architectural choices (using relays to help establish connections), that make it less "pure p2p", but much more likely to actually work reliably.
The two sides are peers when it comes to connection establishment, but once you have a connection they can and frequently will have different roles.
Many existing iroh protocols have clear client and server roles once the connection is established. E.g. gossip is a peer to peer protocol, blobs is a client server protocol in that one side provides data and the other requests it.
For a client you can use an ephemeral node id and not publish your info to discovery, since you will never be dialed yourself.
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
Ingon|8 months ago
* 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
rklaehn|8 months ago
Connections are TCP https websocket connections, because this is most likely to get through even the most restrictive firewalls.
Discovery is handled outside the relays, via either a special DNS server or via the bittorrent mainline DHT. You can even implement your own discovery.
nerdsniper|8 months ago
What are the relative advantages/disadvantages of these two strategies?
eminence32|8 months ago
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|8 months ago
rkagerer|8 months ago
aquariusDue|8 months ago
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|8 months ago
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.
outside1234|8 months ago
ridiculously|8 months ago
softfalcon|8 months ago
schainks|8 months ago
kubafu|8 months ago
tyoung|8 months ago
ventare|8 months ago
dignifiedquire|8 months ago
ndyg|8 months ago
cprecioso|8 months ago
conradev|8 months ago
I just need good FFI now, which is on the roadmap!
makeworld|8 months ago
bestouff|8 months ago
b_fiive|8 months ago
Right now we can get down to an ESP32, which we think is a decent start.
dignifiedquire|8 months ago
Python3267|8 months ago
b_fiive|8 months ago
b_fiive|8 months ago
xeonmc|8 months ago
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.
unknown|8 months ago
[deleted]
iamnotempacc|8 months ago
littlestymaar|8 months ago
pluto_modadic|8 months ago
dhash|8 months ago
throw10920|8 months ago
outside1234|8 months ago
dpc_01234|8 months ago
Also, AFAIK, Iroh makes some architectural choices (using relays to help establish connections), that make it less "pure p2p", but much more likely to actually work reliably.
splintercell|8 months ago
swoorup|8 months ago
rklaehn|8 months ago
Many existing iroh protocols have clear client and server roles once the connection is established. E.g. gossip is a peer to peer protocol, blobs is a client server protocol in that one side provides data and the other requests it.
For a client you can use an ephemeral node id and not publish your info to discovery, since you will never be dialed yourself.
dpc_01234|8 months ago
Calwestjobs|8 months ago
b0a04gl|8 months ago
b_fiive|8 months ago
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.