There is ongoing W3C work on a protocol called WebTransport which allows JavaScript clients to initiate connections which are QUIC-like, over UDP, benefit from avoiding head-of-line-blocking, are multiplexed, still have transport and congestion control, etc. It's mainly for low-latency applications like streaming, video conferencing, and MMORPG like browser games.
But I don't think latency rises to the level of a serious concern. You can do nostr-over-anything though if you want, the world is your oyster. But to me, this isn't one of our biggest issues.
We agree to disagree then. Clearly, switching between hundreds of connections in an outbox model is going to require establishing a new connection with each relay, which takes time — and QUIC shrinks that time down… you can see it in the GIF. QUIC is the fastest transport protocol available today.
QUIC is both TCP and UDP by the way — an intelligent hybrid that prioritizes speed with TLS encryption built-in by default. You literally can’t run QUIC without encryption like you can ws:// or HTTP.
Also with WebTransport you can't run it without TLS.
But is the latency the issue or the SSL overhead?
I honestly don't know, I'm only surmising.
The latency is decreased by shrinking the number of back-and-forths… the TLS handshake is in the first message. HTTPS was built atop HTTP so they had to add an extra back-and-forth.
QUIC has all the TLS built-in, so the number of steps to establish a connection is less — which makes it faster — as the GIF demonstrates. I encourage you to research it more! 🙏
Our relay will be ready soon and will have libp2p QUIC as an option. Libp2p is coded in many languages too.
By the looks of it, WebTransport uses QUIC!
Also, I remember seeing WebTransport as an option in libp2p as well… https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API
https://libp2p.io/2022-12-19-libp2p-webtransport/
I’ll look into if it’s worth expanding hornets to support WebTransport rather than just QUIC. Might be useful pieces built around it…
WebTransport allows browsers to interact with relays running QUIC, which is nice, but we really should be moving away from the centralized web anyhow. I’m going to stick to raw QUIC for now since we’re basically building a desktop app with a React shell (electron app) as the GitNestr client. Raw QUIC has less rounds of communication than WebTransport, as you can see from this attached diagram.
People who want to run semi-centralized clients as websites could leverage WebTransport to communicate with hornet storage #nostr relays when the time comes. I prefer not to feed the problem though. Isn’t your client a desktop app? You could just use raw libp2p QUIC like us. 
Thread collapsed
Thread collapsed
Just to be clear, when I said "SSL overhead" I was talking about the CPU usage and battery life effects of SSL setups due to the public key exchange crypto, not network latency of the SSL setup.
But the overhead of verifying Schnorr signatures on secp256k1 might be even more, I dunno.
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
