Subnostr

Yup, like libp2p QUIC.

You can see here how much faster QUIC is at establishing a connection than HTTPS. It’s because QUIC bundles the TLS into the first outward requests, reducing the number of round trips.

This QUIC model will already be built into GitNestr by default. Although, hornet storage will support the legacy wss:// method to ensure backwards-compatibility with clients who don’t upgrade.

This is what I’ll be tinkering with when trying the new outbox model later on, since it’ll already be built into the Hornet storage relay. Laying my cards on the table. nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c

Mike Dilger ☑️ 1y ago

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.

Reply to this note

Please Login to reply.

Discussion

Colby Serpa 1y ago

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.

Colby Serpa 1y ago

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.

Mike Dilger ☑️ 1y ago

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.

Colby Serpa 1y ago

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.

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…

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.

Mike Dilger ☑️ 1y ago

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.