> One thing to keep in mind when using the connection pool: the connection pool needs the ability to track which connections are currently being used. To do this, the connection pool does not return Connection but ConnectionRef, a struct that derefs to Connection but contains some additional lifetime tracking.
> But Connection is Clone, so in principle there is nothing stopping you from cloning the wrapped connection and losing the lifetime tracking. Don't do this. If you work with connections from the pool, you should pass around either a ConnectionRef or a &Connection to make sure the underlying ConnectionRef stays alive.
Hmmm...
I'd like to see the incovenient API. Or maybe there's a bit more work that could be done to make it convenient? Is there an insurmountable problem that prevents completely hiding the underlying Connection?
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.
[insert yet another comment about having short product introductions at the top pf blog posts]
From their docs page:
> Iroh lets you establish direct peer-to-peer connections whenever possible, falling back to relay servers if necessary. This gives you fast, reliable connections that are authenticated and encrypted end-to-end using QUIC.
and iroh-blobs: provides blob and blob sequence transfer support for iroh. It implements a simple request-response protocol based on BLAKE3 verified streaming
I’m also wondering if it’s possible to use MoQ from iroh, for streaming unidirectional broadcast data that don’t need historical buffers, mainly to freeload on Cloudflare’s free MoQ relays.
Also how do the public relays provides by Iroh compare with Tailscale’s public DERP servers, operationally wise?
I'm going to guess that the difference is that Tailscale lets your machines find each other within a managed flat virtual network where as Iroh lets your applications talk to each other without any regard to which machine anything is running on.
Is it just me or is the safe and “unsafe” versions of using the connection pool identical? Seems like a typo with a clone in the “correct” example that shouldn’t be there?
> One thing to keep in mind when using the connection pool: the connection pool needs the ability to track which connections are currently being used. To do this, the connection pool does not return Connection but ConnectionRef, a struct that derefs to Connection but contains some additional lifetime tracking.
> But Connection is Clone, so in principle there is nothing stopping you from cloning the wrapped connection and losing the lifetime tracking. Don't do this. If you work with connections from the pool, you should pass around either a ConnectionRef or a &Connection to make sure the underlying ConnectionRef stays alive.
Hmmm...
I'd like to see the incovenient API. Or maybe there's a bit more work that could be done to make it convenient? Is there an insurmountable problem that prevents completely hiding the underlying Connection?
Iroh is fantastic.
I’ve been intending to play with it more, it’s given me so many little project ideas that otherwise would be a pain
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
[insert yet another comment about having short product introductions at the top pf blog posts]
From their docs page:
> Iroh lets you establish direct peer-to-peer connections whenever possible, falling back to relay servers if necessary. This gives you fast, reliable connections that are authenticated and encrypted end-to-end using QUIC.
and iroh-blobs: provides blob and blob sequence transfer support for iroh. It implements a simple request-response protocol based on BLAKE3 verified streaming
https://www.iroh.computer/proto/iroh-blobs
How does the use case differ from e.g. Tailscale?
I’m also wondering if it’s possible to use MoQ from iroh, for streaming unidirectional broadcast data that don’t need historical buffers, mainly to freeload on Cloudflare’s free MoQ relays.
Also how do the public relays provides by Iroh compare with Tailscale’s public DERP servers, operationally wise?
I'm going to guess that the difference is that Tailscale lets your machines find each other within a managed flat virtual network where as Iroh lets your applications talk to each other without any regard to which machine anything is running on.
sounds like exactly the sort of thing missing from kde connect
Or zenoh?
Cool concept. Iroh-blobs look promising for decentralized data storage. Curious how it handles versioning and sync performance at scale.
Love Iroh to death, so glad to see it continue to mature
Is it just me or is the safe and “unsafe” versions of using the connection pool identical? Seems like a typo with a clone in the “correct” example that shouldn’t be there?