Re: QUIC(ker)

I appreciate this use case, but another one is you have N accounts served by the same server and can connect all of them over the same QUIC connection.

Another is 1 stream for 1:1 with carbons and another per MUC where you don't even send an account presence.

So I'd for sure like to keep those available, for yours I'd suggest something like a new XEP where the server sends a long random token on login you can send on new streams to shortcut normal login dance and request a filter for stanza JIDs or so.

On April 7, 2026 6:40:46 AM EDT, Dave Cridland <[email protected]> wrote:
>On Sun, 5 Apr 2026 at 13:19, Travis Burtrum <[email protected]> wrote:
>
>> Sure, if you want, plenty of usecases for that. And if you want a new
>> MUX-like protocol that enables "hey I'm gonna open a new stream that
>> authenticates this other way" you can. But I see no reason to tie an entire
>> transport to 1 identity or anything like that at the base level.
>>
>
>You appreciate that "Sure, if you want" is more RFC 6919 than RFC 2119?
>
>Let me give you a concrete case:
>
>I have a client that has some 1:1, but primarily it has several chatrooms.
>The network is what I'll describe as "dodgy" - it's low bandwidth, high
>latency, and has high degrees of packet loss occurring in bursts.
>
>When I send to a chatroom - or receive from one - the packet might
>therefore be lost, and need retransmission. When this occurs, all other
>stanzas occurring afterward need to wait for the missing packet to be
>retransmitted successfully.
>
>QUIC addresses this by allowing multiple streams, so by following this
>architecture and sending stanzas which are order-independent on different
>streams, I could change the last sentence to be qualified: "... all other
>stanzas to the same chatroom ...", which is much better. On networks which
>are not "dodgy", it's still useful to any C2S connection.
>
>But the only way to accomplish this in the XEP is to open multiple
>independent client streams within the same connection, which gives little
>to no advantage over simply opening multiple connections, and - at least in
>C2S - seems very niche. Introduce Carbons (and we must introduce Carbons)
>and it's actively harmful. In S2S, we could open multiple streams, one for
>each domain pair, as long as the TLS certs hold. But we can already do that
>via piggybacking and bidi, anyway - the advantage to S2S here is to avoid
>the HoL blocking, and that's very useful indeed. But, it could easily be
>made better by splitting channels based on bare-jid pair instead of simply
>at the domain-pair level, which is what I want to do at the C2S level as
>well.
>
>To my mind, HoL blocking is the primary use-case for multiple streams, and
>supporting multiple authenticated entities via the same connection seems
>problematic, and gets wildly complicated when we want to (for example) use
>additional streams for media, or file transfer, or ...
>
>So, summary: Authentication should be tied to a QUIC connection, not a QUIC
>stream, and we should be using streams to reduce HoL blocking.
>
>I'd appreciate other people's view here.
>
>Dave.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]