[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.
> 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?
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?
It's extremely subtle, fooled me initially too. The `fn handle_connection` takes a different argument, so rust `Derefs` the `ConnectionRef` into `Connection` for the first example. A bit too subtle to my liking.
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.
That's interesting, because the connection to the relay server is established using HTTP1.1 over TLS. Followed by a WebSocket upgrade. It should look like any other webserver connection on the internet. Could be worth investigating your network conditions and filing an issue for this.
Windows Defender is an interesting challenge. It would be interesting to know if signing the executable has a positive effect here. At $previouscompany we had a software that looked very keylogger-like, and all our Windows Defender issues vanished once we started using EV codesigning certificates. They are not cheap ($300/year), but Defender seems to take the fact that the code is bound to a verified legal entity as a strong trust signal
12 comments
[ 4.5 ms ] story [ 37.5 ms ] threadFrom 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.
I’ve been intending to play with it more, it’s given me so many little project ideas that otherwise would be a pain
> 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?
[0]: vanadium.github.io
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.