I just need good FFI now, which is on the roadmap!
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.
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.
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.
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
Applications are more than welcome to use prefixes, but the use of ED25519 is not configurable
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)
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!
Right now we can get down to an ESP32, which we think is a decent start.
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
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.
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
* 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.
ridiculously•4h ago
softfalcon•4h ago
dignifiedquire•3h ago
schainks•2h ago
tyoung•1h ago
ventare•38m ago
kubafu•15m ago