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:[email protected]?join On January 29, 2026 11:02:05 AM EST, Dave Cridland <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
