b_fiive

sup steb, this is expede's work!

Now, see. that's what I said as well. But the rest of the team was tired of me trying to name the hosted iroh "n0des", which I'm now ready to admit was a stretch. And so now here we are spelling n0q as noq. c'est la vie.

It's been a draft for a long while, and was only recently approved

disclosure: I work on the team behind noq. Can't emphasize enough that the quinn maintainers are really lovely people, and quinn is an excellent project.

worm-blossom crew is just a delightful bunch of humans doing really great work

delighted to hear! iroh-blobs is Rüdiger's love letter to BLAKE3, and hot dang has he taken this piece of machinery quite far. Much of this is covered in the post, but some highlights:

* fetch any sub-sequence of bytes, verified on send & receive * fetch sub-sequences of bytes in collections (sets of blobs / directories) * store on disk, inlining small blobs into the database for faster lookups * fan in from disk & the network * "multi-provider" fan in that can re-plan a fetch on the fly * should land support for WASM compilation (browsers) soon! https://github.com/n0-computer/iroh-blobs/pull/187

We're hard at work on making the API more ergonomic, but as a foundational protocol it's truly impressive. Rudi has been working with the BLAKE3 authors on both perf testing & the hazmat API.

disclosure: I work on iroh

Yep! It's totally usable for games, and used in a few! One of my favs is the godot engine plugin: https://github.com/tipragot/godot-iroh

QUIC can do both reliable & unreliable streams, as can iroh

sibling comment with links to docs is the more accurate, but to summarize, it's some of both:

* all connections are always e2ee (even when traffic flows through a relay)

* relays are both for connection negotiation, and as a fallback when a direct connection isn't possible

* initial packet is always sent through the relay to keep a fast time-to-first-byte, while a direct connection is negotiated in parallel. typical connections send a few hundred bytes over the relay & the rest of the connection lifetime is direct

yes, to an extent. It will time out if the connection completely dies for more than the timeout interval, but all connections are designed to survive changes to network changes like IP address or network interface (eg: switching from WiFi to ethernet, or cellular)

same team behind dumbpipe makes sendme, which is much closer to this use case! https://github.com/n0-computer/sendme

it's p2p. dumbpipe is hardcoded to use a public set of relays that we run for free (we being number 0, the team that make iroh & dumbpipe).

we can definitely add a config argument to skip the hardcoded relays & provide custom ones!

Thanks for the heads up! We've fixed: https://github.com/n0-computer/dumbpipe.dev/pull/11

less configuration. more reliable. less pure p2p (iroh uses relays)

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

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.

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

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.

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

(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.

hey I work on this! AMA!

I don't know much about the fund itself, but https://www.indie.vc/ seems like their whole thesis is this middle path.

I work on iroh, and this is exactly correct. It doesn't do locally discovery by default, but can be configured to discover devices on local networks. Docs link above is the best place to start, and here's a code example to compliment: https://github.com/n0-computer/iroh/blob/main/iroh/examples/...

If you're a rust fan we make a similar library, that's all-in on "p2p-QUIC", with pre-baked protocols to import on top: https://github.com/n0-computer/iroh

I switched recently from vscode, and it's now my daily driver. I mainly edit rust & typescript, experience has been great. I did need two critical keybindings for toggling the terminal: https://gist.github.com/b5/8a03cee3cf6321ee65ffcb28899c4362 , and documentation was a little thin on how to set it up

indeed. Browsers or node/deno/bun/whatever?

yep! Iroh documents [1] give you a very nice primitive that is technically a CRDT, but in practice most people use it as a key-value store. We really wanted a mutable solution that would support real deletions (instead of tombstones), and starting with append-only logs locks you out of that choice.

With Iroh + CRDTs you have three choices: 1. Use iroh's connection & gossip layers in conjunction with a mature CRDT library like Automerge or Y.js. 2. Build a more sophisticated CRDT on top of iroh documents. 3. Worry a little less about weather your data structures form a semilattice & build on a last-writer wins key-value store (basically: just use documents)

We've seen uses for all three. Hope that helps!

[1] https://iroh.computer/docs/layers/documents