Replying to Avatar Colby Serpa

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.
Avatar
Colby Serpa 1y ago

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…

Reply to this note

Please Login to reply.

Discussion

Avatar
Colby Serpa 1y ago

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.