flub

Iroh uses QUIC connections and uses the EndpointId, the public ed25519 key, in the TLS handshake for authentication. This makes it impossible for a server to try and machine-in-the-middle the connection.

iroh is fully open source though, you can run your own relay server and not have any dependencies on number0

iroh is an open source library. The relay servers are open source too but number0 runs public, rate limited, relay servers that can be used by everyone. The commercial offerings are for dedicated relay servers and more insight into your network.

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.

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.

MoQ: yeah, MoQ runs on top of QUIC so you can run it on top of iroh. I think some version of this will happen sometime.

DERP: very similar. iroh relay servers were initially modelled on DERP, but are now diverging more and more.

Fragmenting datagrams (or IP packets) is generally not a good idea. All protocol designs have been moving away from this the past few decades. If you want unreliable messages of larger than the MTU maybe taking some inspiration from Media-over-QUIC is a good idea. They use one uni-directional QUIC stream per message and include some metadata at the start of each stream to explain how old it is. If a stream takes too long to read to end-of-stream and you already have a newer message in a new uni-directional stream you can cancel the previous streams (using something like SendStream::reset or RecvStream::stop in Quinn API terms, depending on which side detects the message is no longer needed earlier). Doing this will stop QUIC from retransmitting the lost data from the message that's being slow to receive.

There might be some confusion here, holepunching is a core functionality of iroh. There are still some firewall configurations that iroh can not yet holepunch and that can still be improved, but in general the holepunching works rather well.

I'm not sure I fully understand this window logic question. QUIC does MTU discovery, so if the link supports bigger datagrams the MTU will go up. Unreliable datagrams using RFC9221 can be sent up to the MTU size minus the QUIC packet overhead. So if your link supports >1500 bytes then you should be able to send datagrams >1500 bytes using iroh.

As one of the iroh developers I must say thank you for creating ZeroTier! It absolutely was part of the inspiration and it's seamless functioning continues to amaze me daily. Something that continues to drive me to strive for as seamless an experience in iroh.

I love the fact we can make different tools learning from each other and approaching making p2p usable in different ways.