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 <dave(a)cridland.net> wrote:
On Sun, 5 Apr 2026 at 13:19, Travis Burtrum
<travis(a)burtrum.org> 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.