> 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?
[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.
It uses a third server to facilitate initial p2p connections but I keep loosing/fail to connect to this server. I don't know if it's because of many restarts during development or something else.
Windows Defender nukes this from orbit, making it nearly impossible to ship to clients in a trusting fashion. But I guess any program which punches through the firewall is suspect.
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?
Iroh-blobs
(iroh.computer)142 points by janandonly 27 October 2025 | 25 comments
Comments
> 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?
I’ve been intending to play with it more, it’s given me so many little project ideas that otherwise would be a pain
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.
It uses a third server to facilitate initial p2p connections but I keep loosing/fail to connect to this server. I don't know if it's because of many restarts during development or something else.
Windows Defender nukes this from orbit, making it nearly impossible to ship to clients in a trusting fashion. But I guess any program which punches through the firewall is suspect.
[0]: vanadium.github.io