XMPP Council - 2026-08-11

We still don't have anything on the agenda. I'm fine with skipping today and seeing you all in a week. Editor has some work todo but nothing that would add anything new to the agenda. (just processing things we already voted on)

Ping me if you want to add anything to next week's agenda or if I'm missing something.

+1w wfm

+1w wfm

+1w wfm

Oh, you guys were quick. Speaking of, I have suggested changes to XEP-0467, which the author, moparisthebest, doesn't like. Does Council want a competing QUIC binding (suggested by moparisthebest) or do we want to resolve that in some other way? I don't mind, quite happy to write a competitor.

no competing, yours should be a new xep building on 467 adding the tiniest bit of negotiation wherever you want (in the stream or in host-meta) to enable this optional not-always-desirable stream splitting, extensible !

It absolutely can't "build on".

that's like saying stream management or carbons are mandatory and can't be "build on"

No, it's not. XEP-0467 assumes any inbound QUIC stream is a new XML Stream. My changes break that assumption.

only because you neglected to add any negotiation

That involves sequencing; you need to inject a round-trip then.

send <quic-stream for="whatever.com" code="random code given after first auth"/> as the first stanza and done ?

right the same sequencing that is required if you intend to share auth across connections

I think this is a fine use-case btw, just don't want to preclude my use-cases that involves multiple quic streams with different authentication between them

if you simply have 1 stanza to associate auth across different streams then all use-cases work , hell it'd even work across TLS connections

concretely I'd propose a new xep not even tied to quic, simply if server supports it after auth it sends eg: <stream-auth-id secret="uuid secret able to auth a new stream with same scope as this one while one is active"/> then every new stream you open you send this first: <stream-auth secret="from-above" jid="bob.com"/> and the server responds either with an error or like you auth'd the same way, gives you same resource etc? or maybe it'd be an iq or a shorter lived FAST token or something ? no strong opinions on the how, just that it seems trivial to negotiate properly no ?

if you really wanted to tie it to quic another alternative would be to use ALPN which allows server and client to agree which inner protocol to use... I don't quite like it as much since the above allows mixing both use-cases on 1 or more connections ?

I can merge the two - allow multiple XML streams, each over multiple QUIC streams, on a single QUIC connection. But I don't think I can realistically do it backwards comaptibly without introducing a round-trip during session startup.