11 Apr
2026
11 Apr
'26
7:52 a.m.
The use case of multiple accounts served by the same server doesn't feel common at all
for c2s, and it is not clear to me why a client couldn't just initiate multiple QUIC
connections instead. If we indeed get to 0-RT reconnects, that should be just fine.
Binding (bare JID) identity to the QUIC connections seems extremely desirable to me for
your other use case and the ones that Dave mentioned. It also makes it much easier to have
"oob" data streams (calls or file transfer or whatever) authenticated, without
requiring tokens.
I think the latter would be more common use cases than multiple accounts, so I'd
rather optimize for this.
--
ralphm
On 11 April 2026 00:14:47 CEST, Travis Burtrum <travis(a)burtrum.org> wrote:
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.