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. 
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.
