29 Jan
2026
29 Jan
'26
4:02 p.m.
Hey all,
Some of you have heard me talk about this at the Summit, but I'd like to
revisit/reexamine our QUIC binding to improve performance of XMPP on low
bandwidth. I'm not sure we'll get to this at the Summit, and there's not
many who want to talk about it so I wondered if this summit topic could
have been an email. (Except then we discussed it anyway)
The primary concerns on low bandwidth - beyond sending fewer bytes on the
wire - are round-trips and head-of-line blocking.
I think XMPP has a good story on round-trips; we're down to very few during
authentication and connection setup, and during normal messaging operation
we don't worry about latency at all.
Head-of-Line blocking, or HoL Blocking, is when - in our case - packet loss
causes the stream to stall until the packet is retransmitted, which is at
least a round-trip away - and can be more due to bandwidth-delay product.
At the same time, we cannot eliminate this entirely (by, say, sending
stanzas over UDP directly) because if we do that we lose the ordering. Out
of order messages can be confusing, and lead to bad misunderstandings.
The rules on this are in RFC 6120, and are rather more complicated than we
normally worry about - normally, we just process everything on a strea, in
order, and this does satisfy the rules. But the rules allow us to process
stanzas in any order we like, as long as
So, what I'm thinking is a way to use the additional channels in QUIC such
that we open multiple channels on both C2S and S2S sessions, which would
form part of the same virtual stream, and we can distribute messages such
that we maintain ordering within messages where we need to, but allows us
to out-of-order (and avoid HOL Blocking) messages sent between unrelated
jids.
This differs to the existing XEP, where each channel maps to a single XML
Stream and XMPP session.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as
well, so we probably want both with a uniform approach.
So, my plan is to get an implementation together and a XEP.
Anyone else interested?
Dave.
29 Jan
29 Jan
4:58 p.m.
I'm interested in implementing this multiple channels for one xml stream thing
in Monal.
-tmolitor
Am Donnerstag, 29. Januar 2026, 17:02:05 CET schrieb Dave Cridland:
Hey all,
Some of you have heard me talk about this at the Summit, but I'd like to
revisit/reexamine our QUIC binding to improve performance of XMPP on low
bandwidth. I'm not sure we'll get to this at the Summit, and there's not
many who want to talk about it so I wondered if this summit topic could
have been an email. (Except then we discussed it anyway)
The primary concerns on low bandwidth - beyond sending fewer bytes on the
wire - are round-trips and head-of-line blocking.
I think XMPP has a good story on round-trips; we're down to very few during
authentication and connection setup, and during normal messaging operation
we don't worry about latency at all.
Head-of-Line blocking, or HoL Blocking, is when - in our case - packet loss
causes the stream to stall until the packet is retransmitted, which is at
least a round-trip away - and can be more due to bandwidth-delay product.
At the same time, we cannot eliminate this entirely (by, say, sending
stanzas over UDP directly) because if we do that we lose the ordering. Out
of order messages can be confusing, and lead to bad misunderstandings.
The rules on this are in RFC 6120, and are rather more complicated than we
normally worry about - normally, we just process everything on a strea, in
order, and this does satisfy the rules. But the rules allow us to process
stanzas in any order we like, as long as
So, what I'm thinking is a way to use the additional channels in QUIC such
that we open multiple channels on both C2S and S2S sessions, which would
form part of the same virtual stream, and we can distribute messages such
that we maintain ordering within messages where we need to, but allows us
to out-of-order (and avoid HOL Blocking) messages sent between unrelated
jids.
This differs to the existing XEP, where each channel maps to a single XML
Stream and XMPP session.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as
well, so we probably want both with a uniform approach.
So, my plan is to get an implementation together and a XEP.
Anyone else interested?
Dave.
6:38 p.m.
Le 29 janv. 2026 à 11:02, Dave Cridland
<dave(a)cridland.net> a écrit :
Hey all,
Some of you have heard me talk about this at the Summit, but I'd like to
revisit/reexamine our QUIC binding to improve performance of XMPP on low bandwidth.
I'm not sure we'll get to this at the Summit, and there's not many who want to
talk about it so I wondered if this summit topic could have been an email. (Except then we
discussed it anyway)
The primary concerns on low bandwidth - beyond sending fewer bytes on the wire - are
round-trips and head-of-line blocking.
I think XMPP has a good story on round-trips; we're down to very few during
authentication and connection setup, and during normal messaging operation we don't
worry about latency at all.
Head-of-Line blocking, or HoL Blocking, is when - in our case - packet loss causes the
stream to stall until the packet is retransmitted, which is at least a round-trip away -
and can be more due to bandwidth-delay product.
At the same time, we cannot eliminate this entirely (by, say, sending stanzas over UDP
directly) because if we do that we lose the ordering. Out of order messages can be
confusing, and lead to bad misunderstandings.
The rules on this are in RFC 6120, and are rather more complicated than we normally worry
about - normally, we just process everything on a strea, in order, and this does satisfy
the rules. But the rules allow us to process stanzas in any order we like, as long as
So, what I'm thinking is a way to use the additional channels in QUIC such that we
open multiple channels on both C2S and S2S sessions, which would form part of the same
virtual stream, and we can distribute messages such that we maintain ordering within
messages where we need to, but allows us to out-of-order (and avoid HOL Blocking) messages
sent between unrelated jids.
This differs to the existing XEP, where each channel maps to a single XML Stream and XMPP
session.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as well,
so we probably want both with a uniform approach.
So, my plan is to get an implementation together and a XEP.
Anyone else interested?
Yes. As Peter St-Andre and I started a thread some time ago, our use case is (deep) space
messaging/chat where latency is significant, but QUIC can be configured to work very well
in this environment. If we have a good spec, I'll have my team implement it using the
Quinn QUIC stack and simulate it on our (deep space) testbed.
Regards, Marc.
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
30 Jan
30 Jan
2:12 a.m.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as
well, so we probably want both with a uniform approach.
I think we have, with "WebTransport" a real opportunity to specify a proper
XMPP-native transport mechanism (no extra framing or use case specific hacks
like WebSocket or BOSH, full normal TLS support possible when implemented in
a normal client, etc) that happens to also work from browsers (and other
things like transit through HTTP proxies and HTTP reverse proxies... at
least if they support http3 smelling things).
I'm not sure what the "raw" QUIC advantages could be, but I would be
strongly in favour of making this a special case MAY with WebTransport
handshake support as at least a SHOULD level thing.
4 Apr
4 Apr
1:03 p.m.
On Fri, 30 Jan 2026 at 02:13, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
I think we have, with "WebTransport" a real
opportunity to specify a
proper
XMPP-native transport mechanism (no extra framing or use case specific
hacks
like WebSocket or BOSH, full normal TLS support possible when implemented
in
a normal client, etc) that happens to also work from browsers (and other
things like transit through HTTP proxies and HTTP reverse proxies... at
least if they support http3 smelling things).
I'm not sure what the "raw" QUIC advantages could be, but I would be
strongly in favour of making this a special case MAY with WebTransport
handshake support as at least a SHOULD level thing.
For all the purposes I need QUIC for (and Marc Blanchet, too), having full
control over congestion control, keep alives, idle timeouts etc is
important. Web Transport doesn't let you tinker in this way.
Also, Web Transport adds the HTTP/3 handshake, which is breaking the 0-RTT
desire.
I think Web Transport might well be great for many cases, but I'm currently
focused on low-bandwidth, high-latency, high-loss networks, so for my
purposes at least I'm only interested in QUIC itself at this stage.
But, solving QUIC should mean that Web Transport is very easy.
Dave.
30 Jan
30 Jan
4:18 a.m.
Nothing in the current XEP https://xmpp.org/extensions/xep-0467.html forbids multiple
streams, in fact it mentions it directly
Multiple bi-directional MAY be opened in one session
and MUST be treated as a seperate connections with the same security and authentication as
negotiated in the initial TLS handshake. This means clients can log into multiple
accounts, or the same account multiple times over one QUIC session, or servers can open
multiple s2s connections over one QUIC session where one of the servers can prove control
over multiple domains, for example if the certificate covered multiple domain names.
https://xmpp.org/extensions/xep-0487.html is how both QUIC and WebTransport can be
discovered, and both are implemented in https://github.com/moparisthebest/xmpp-proxy
already, stop by the muc if you want, you can even connect with webtransport or quic now
;) xmpp:xmpp-proxy@code.moparisthe.best?join
On January 29, 2026 11:02:05 AM EST, Dave Cridland <dave(a)cridland.net> wrote:
Hey all,
Some of you have heard me talk about this at the Summit, but I'd like to
revisit/reexamine our QUIC binding to improve performance of XMPP on low
bandwidth. I'm not sure we'll get to this at the Summit, and there's not
many who want to talk about it so I wondered if this summit topic could
have been an email. (Except then we discussed it anyway)
The primary concerns on low bandwidth - beyond sending fewer bytes on the
wire - are round-trips and head-of-line blocking.
I think XMPP has a good story on round-trips; we're down to very few during
authentication and connection setup, and during normal messaging operation
we don't worry about latency at all.
Head-of-Line blocking, or HoL Blocking, is when - in our case - packet loss
causes the stream to stall until the packet is retransmitted, which is at
least a round-trip away - and can be more due to bandwidth-delay product.
At the same time, we cannot eliminate this entirely (by, say, sending
stanzas over UDP directly) because if we do that we lose the ordering. Out
of order messages can be confusing, and lead to bad misunderstandings.
The rules on this are in RFC 6120, and are rather more complicated than we
normally worry about - normally, we just process everything on a strea, in
order, and this does satisfy the rules. But the rules allow us to process
stanzas in any order we like, as long as
So, what I'm thinking is a way to use the additional channels in QUIC such
that we open multiple channels on both C2S and S2S sessions, which would
form part of the same virtual stream, and we can distribute messages such
that we maintain ordering within messages where we need to, but allows us
to out-of-order (and avoid HOL Blocking) messages sent between unrelated
jids.
This differs to the existing XEP, where each channel maps to a single XML
Stream and XMPP session.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as
well, so we probably want both with a uniform approach.
So, my plan is to get an implementation together and a XEP.
Anyone else interested?
Dave.
4 Apr
4 Apr
9:23 p.m.
On Fri, 30 Jan 2026 at 04:19, Travis Burtrum <travis(a)burtrum.org> wrote:
Nothing in the current XEP
https://xmpp.org/extensions/xep-0467.html
forbids multiple streams, in fact it mentions it directly
I took this to mean ... well, actually I'm not sure what this means. So
clients can open multiple bi-directional reliable streams, they must be
treated as seperate connections but with the same security and
authentication? What does "separate connections" mean if they're
authenticated the same? Are they the same resource on a C2S? Does the S2S
mention suggest that each domain pair MUST (MIGHT?) be on a different
stream, and that we SHOULDN'T mix them?
I think this needs a massive amount more detail.
What I'm working toward is where we want to send to 5 different entities,
we can - as a trivial degenerate case - connect via C2S, pass through SASL,
open up 4 additional QUIC streams, and then send to each remote entity over
a different QUIC stream, so that if a packet is lost the HoL blocking only
affects the one stream.
The more generalised idea is that given any stanza, if we take the bare
jids of both to and from, then this pair must map to only a single stream
at a time (and you actually need XEP-0198 in effect to switch streams
reliably without messing up the ordering on the switch).
I'm going to get some `tc` stuff up and running and experiment, but I think
this is roughly the algorithm that'll work best on the low-bandwidth,
high-latency, high-loss networks I'm targeting.
Dave.
Multiple bi-directional MAY be opened in one
session and MUST be treated
as a seperate connections with the same security and
authentication as
negotiated in the initial TLS handshake. This means clients can log into
multiple accounts, or the same account multiple times over one QUIC
session, or servers can open multiple s2s connections over one QUIC session
where one of the servers can prove control over multiple domains, for
example if the certificate covered multiple domain names.
5 Apr
5 Apr
3:48 a.m.
On April 4, 2026 5:23:40 PM EDT, Dave Cridland <dave(a)cridland.net> wrote:
On Fri, 30 Jan 2026 at 04:19, Travis Burtrum
<travis(a)burtrum.org> wrote:
The same security and authentication of the TLS negotiation, so if you are a client with a
connection to a server with a cert you trust that is good for bob.com and tom.com you can
open new quic streams for any number of accounts on those domains. But not google.com.
tl;dr only trust your TLS auth when deciding if you can use the connection for this
domain. (different XEPs and RFCs might change the way you trust of course)
The server just treats them as entirely seperate connections. so you are free to log in
for a session per domain with smacks each if you want.
Nothing in the current XEP
https://xmpp.org/extensions/xep-0467.html
forbids multiple streams, in fact it mentions it directly
I took this to mean ... well, actually I'm not sure what this means. So
clients can open multiple bi-directional reliable streams, they must be
treated as seperate connections but with the same security and
authentication? What does "separate connections" mean if they're
authenticated the same? Are they the same resource on a C2S? Does the S2S
mention suggest that each domain pair MUST (MIGHT?) be on a different
stream, and that we SHOULDN'T mix them?
I think this needs a massive amount more detail. Multiple bi-directional MAY be opened in one
session and MUST be treated
as a seperate connections with the same security and
authentication as
negotiated in the initial TLS handshake. This means clients can log into
multiple accounts, or the same account multiple times over one QUIC
session, or servers can open multiple s2s connections over one QUIC session
where one of the servers can prove control over multiple domains, for
example if the certificate covered multiple domain names.
7:50 a.m.
On Sun, 5 Apr 2026 at 04:49, Travis Burtrum <travis(a)burtrum.org> wrote:
On April 4, 2026 5:23:40 PM EDT, Dave Cridland <dave(a)cridland.net> wrote:
The same security and authentication of the TLS negotiation, so if you are
a client with a connection to a server with a cert you trust that is good
for bob.com and tom.com you can open new quic streams for any number of
accounts on those domains. But not google.com. tl;dr only trust your TLS
auth when deciding if you can use the connection for this domain.
(different XEPs and RFCs might change the way you trust of course)
So they go through SASL etc and form a complete XMLStream on each
connection, under your model? For client sessions, this would mean multiple
resources? This seems very wasteful.
Dave.
On Fri, 30 Jan 2026 at 04:19, Travis Burtrum
<travis(a)burtrum.org> wrote:
> Nothing in the current XEP https://xmpp.org/extensions/xep-0467.html
> forbids multiple streams, in fact it mentions it directly
>
> > Multiple bi-directional MAY be opened in one session and MUST be
treated
> as a seperate connections with the same
security and authentication as
> negotiated in the initial TLS handshake. This means clients can log into
> multiple accounts, or the same account multiple times over one QUIC
> session, or servers can open multiple s2s connections over one QUIC
session
where one
of the servers can prove control over multiple domains, for
example if the certificate covered multiple domain names.
I took this to mean ... well, actually I'm not sure what this means. So
clients can open multiple bi-directional reliable streams, they must be
treated as seperate connections but with the same security and
authentication? What does "separate connections" mean if they're
authenticated the same? Are they the same resource on a C2S? Does the S2S
mention suggest that each domain pair MUST (MIGHT?) be on a different
stream, and that we SHOULDN'T mix them?
I think this needs a massive amount more detail.
12:18 p.m.
On April 5, 2026 3:50:36 AM EDT, Dave Cridland <dave(a)cridland.net> wrote:
On Sun, 5 Apr 2026 at 04:49, 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.
On April 4, 2026 5:23:40 PM EDT, Dave Cridland <dave(a)cridland.net> wrote:
The same security and authentication of the TLS negotiation, so if you are
a client with a connection to a server with a cert you trust that is good
for bob.com and tom.com you can open new quic streams for any number of
accounts on those domains. But not google.com. tl;dr only trust your TLS
auth when deciding if you can use the connection for this domain.
(different XEPs and RFCs might change the way you trust of course)
So they go through SASL etc and form a complete XMLStream on each
connection, under your model? For client sessions, this would mean multiple
resources? This seems very wasteful. On Fri, 30 Jan 2026 at 04:19, Travis Burtrum
<travis(a)burtrum.org> wrote:
> Nothing in the current XEP https://xmpp.org/extensions/xep-0467.html
> forbids multiple streams, in fact it mentions it directly
>
> > Multiple bi-directional MAY be opened in one session and MUST be
treated
> as a seperate connections with the same
security and authentication as
> negotiated in the initial TLS handshake. This means clients can log into
> multiple accounts, or the same account multiple times over one QUIC
> session, or servers can open multiple s2s connections over one QUIC
session
where one
of the servers can prove control over multiple domains, for
example if the certificate covered multiple domain names.
I took this to mean ... well, actually I'm not sure what this means. So
clients can open multiple bi-directional reliable streams, they must be
treated as seperate connections but with the same security and
authentication? What does "separate connections" mean if they're
authenticated the same? Are they the same resource on a C2S? Does the S2S
mention suggest that each domain pair MUST (MIGHT?) be on a different
stream, and that we SHOULDN'T mix them?
I think this needs a massive amount more detail.
7 Apr
7 Apr
10:40 a.m.
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.
10 Apr
10 Apr
10:14 p.m.
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. 
11 Apr
11 Apr
5: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.
25 Apr
25 Apr
6:35 p.m.
Multiple accounts on the same server is common, eg for people with more than one phone
number from jmp.chat
You need protocol to have bare JID bound to the quic connection anyway, so we can have
both. Though the only thing spec'd and implemented now is each stream is independent
which doesn't need protocol.
On April 11, 2026 1:52:00 AM EDT, Ralph Meijer <ralphm(a)ik.nu> wrote:
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.
30 Apr
30 Apr
11:57 a.m.
On Sat, 25 Apr 2026 at 19:35, Travis Burtrum <travis(a)burtrum.org> wrote:
Multiple accounts on the same server is common, eg for
people with more
than one phone number from jmp.chat
I'm sure it happens, but I imagine it happens considerably less than a
single account talking to multiple people.
You need protocol to have bare JID bound to the quic
connection anyway, so
we can have both. Though the only thing spec'd and implemented now is each
stream is independent which doesn't need protocol.
As noted elsewhere, I've implemented a PoC for multi-stream QUIC, and a PR
against XEP-0467 for it. Would appreciate your comments/feedback.
I would note that I'm actually running discovery via SRV records; I'm not
keen on the idea of using an HTTP call to get the connection details, and
haven't revisited SVCB for XMPP yet - though I probably should. I've
deliberately not included this SRV discovery in the spec, I think that's
entirely orthogonal.
Dave.
4 Apr
4 Apr
12:52 p.m.
A little update:
I've implemented a very rough bit of support for single-channel, C2S only,
QUIC in Openfire, and similar in Wimsy so I can actually use it.
It... works? But it also does very little of any interest, so is probably
not interesting to anyone outside of implementers. If you are one, ping me
for a test account.
I've added a SRV to _xmpp-client._quic.dave.cridland.net for discovery;
while XEP-0487 is an option that still feels very ikky.
I'll go reply to all the messages on this thread now with specifics, sorry!
Dave.
On Thu, 29 Jan 2026 at 16:02, Dave Cridland <dave(a)cridland.net> wrote:
Hey all,
Some of you have heard me talk about this at the Summit, but I'd like to
revisit/reexamine our QUIC binding to improve performance of XMPP on low
bandwidth. I'm not sure we'll get to this at the Summit, and there's not
many who want to talk about it so I wondered if this summit topic could
have been an email. (Except then we discussed it anyway)
The primary concerns on low bandwidth - beyond sending fewer bytes on the
wire - are round-trips and head-of-line blocking.
I think XMPP has a good story on round-trips; we're down to very few
during authentication and connection setup, and during normal messaging
operation we don't worry about latency at all.
Head-of-Line blocking, or HoL Blocking, is when - in our case - packet
loss causes the stream to stall until the packet is retransmitted, which is
at least a round-trip away - and can be more due to bandwidth-delay product.
At the same time, we cannot eliminate this entirely (by, say, sending
stanzas over UDP directly) because if we do that we lose the ordering. Out
of order messages can be confusing, and lead to bad misunderstandings.
The rules on this are in RFC 6120, and are rather more complicated than we
normally worry about - normally, we just process everything on a strea, in
order, and this does satisfy the rules. But the rules allow us to process
stanzas in any order we like, as long as
So, what I'm thinking is a way to use the additional channels in QUIC such
that we open multiple channels on both C2S and S2S sessions, which would
form part of the same virtual stream, and we can distribute messages such
that we maintain ordering within messages where we need to, but allows us
to out-of-order (and avoid HOL Blocking) messages sent between unrelated
jids.
This differs to the existing XEP, where each channel maps to a single XML
Stream and XMPP session.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as
well, so we probably want both with a uniform approach.
So, my plan is to get an implementation together and a XEP.
Anyone else interested?
Dave.
1:09 p.m.
Coooool!
Which QUIC stack(s) are you using?
I'll be interested in testing it out first under normal conditions and then see how it
behaves in high delay environments (space)
Regards, Marc.
Le 4 avr. 2026 à 08:52, Dave Cridland
<dave(a)cridland.net> a écrit :
A little update:
I've implemented a very rough bit of support for single-channel, C2S only, QUIC in
Openfire, and similar in Wimsy so I can actually use it.
It... works? But it also does very little of any interest, so is probably not interesting
to anyone outside of implementers. If you are one, ping me for a test account.
I've added a SRV to _xmpp-client._quic.dave.cridland.net
<http://quic.dave.cridland.net/> for discovery; while XEP-0487 is an option that
still feels very ikky.
I'll go reply to all the messages on this thread now with specifics, sorry!
Dave.
On Thu, 29 Jan 2026 at 16:02, Dave Cridland <dave(a)cridland.net
<mailto:dave@cridland.net>> wrote:
Hey all,
Some of you have heard me talk about this at the Summit, but I'd like to
revisit/reexamine our QUIC binding to improve performance of XMPP on low bandwidth.
I'm not sure we'll get to this at the Summit, and there's not many who want to
talk about it so I wondered if this summit topic could have been an email. (Except then we
discussed it anyway)
The primary concerns on low bandwidth - beyond sending fewer bytes on the wire - are
round-trips and head-of-line blocking.
I think XMPP has a good story on round-trips; we're down to very few during
authentication and connection setup, and during normal messaging operation we don't
worry about latency at all.
Head-of-Line blocking, or HoL Blocking, is when - in our case - packet loss causes the
stream to stall until the packet is retransmitted, which is at least a round-trip away -
and can be more due to bandwidth-delay product.
At the same time, we cannot eliminate this entirely (by, say, sending stanzas over UDP
directly) because if we do that we lose the ordering. Out of order messages can be
confusing, and lead to bad misunderstandings.
The rules on this are in RFC 6120, and are rather more complicated than we normally worry
about - normally, we just process everything on a strea, in order, and this does satisfy
the rules. But the rules allow us to process stanzas in any order we like, as long as
So, what I'm thinking is a way to use the additional channels in QUIC such that we
open multiple channels on both C2S and S2S sessions, which would form part of the same
virtual stream, and we can distribute messages such that we maintain ordering within
messages where we need to, but allows us to out-of-order (and avoid HOL Blocking) messages
sent between unrelated jids.
This differs to the existing XEP, where each channel maps to a single XML Stream and XMPP
session.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as well,
so we probably want both with a uniform approach.
So, my plan is to get an implementation together and a XEP.
Anyone else interested?
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
1:12 p.m.
On Sat, 4 Apr 2026 at 14:10, Marc Blanchet <marc.blanchet(a)viagenie.ca>
wrote:
Coooool!
Which QUIC stack(s) are you using?
Quiche in Netty - this is Openfire.
I'll be interested in testing it out first under
normal conditions and
then see how it behaves in high delay environments (space)
I've not yet pushed it, but will do hopefully today.
Dave.
1:17 p.m.
Le 4 avr. 2026 à 09:12, Dave Cridland
<dave(a)cridland.net> a écrit :
On Sat, 4 Apr 2026 at 14:10, Marc Blanchet <marc.blanchet(a)viagenie.ca
<mailto:marc.blanchet@viagenie.ca>> wrote:
Good. Quiche has been updated to expose the hooks necessary for space, with only one
exception: a new congestion controller can not be added when using Quiche as a library, so
one has to do a fork. (Quinn on the other hand enables adding a new congestion controller
without having to do a fork). In space, standard congestion controllers don't work
well when there is intermittence.
Regards, Marc.
Coooool!
Which QUIC stack(s) are you using?
Quiche in Netty - this is Openfire. I'll be interested in testing it out first
under normal conditions and then see how it behaves in high delay environments (space)
I've not yet pushed it, but will do hopefully today.
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
25
days inactive
116
days old
18 comments
6 participants
participants (6)
-
Dave Cridland -
Marc Blanchet -
Ralph Meijer -
Stephen Paul Weber -
Thilo Molitor -
Travis Burtrum