September 2026 - Standards

New protoxep: MUC is ready
by Nicolas Cedilnik 29 Sep '26

29 Sep '26

Hi all, I submitted a protoXEP today <https://github.com/xsf/xeps/pull/1563>. A rendered version is at <https://nicoco.fr/muc-ready.html> It is a proposition for a mechanism to avoid the following situation: 1. a MUC services shuts down and kicks clients out; 2. clients don't re-join the MUC automatically. This is generally not an issue for local users, since MUC services and XMPP server implementations are tightly coupled in practice and can work around the situation by supporting restarting the MUC service "silently". Also, when the whole XMPP server is restarted, clients re-login and re-join all MUCs after that, so the issue does not arise. It is however a problem for non-local users. Clients have adopted different strategies for this situation. For instance, Conversations does not attempt to re-join automatically, and gajim retries periodically. I propose that MUC services can emit MUC invitations on startup to signal that a room is ready to be re-joined. The invite stanza has a dedicated |<ready />| element, which lets clients treat these invites differently than others, eg, by avoiding to display it to the user or triggering re-join as they see fit. Slidge already has this "invite users on startup" behaviour and I developed a small prosody module <https://modules.prosody.im/mod_muc_invite_affiliated.html> <https://modules.prosody.im/mod_muc_invite_affiliated.html> with a similar behaviour. If this proposition is accepted, I will add the dedicated element in the invites of both this prosody module and slidge. Maybe this should be a new section in /XEP-0249: Direct MUC Invitations/ instead? What does the community think? Is it a terrible idea or does it fill a gap that is missing? -- Nicolas

1 0

Proposed XMPP Extension: SASL2 Terms of Service Acceptance Task
by Daniel Gultsch 29 Sep '26

29 Sep '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: SASL2 Terms of Service Acceptance Task Abstract: This specification defines a SASL2 task, per the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes. URL: https://xmpp.org/extensions/inbox/sasl2-tos.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 2

Proposed XMPP Extension: Multistream XMPP
by Daniel Gultsch 29 Sep '26

29 Sep '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Multistream XMPP Abstract: Multistream protocols such as QUIC and WebTransport offer significant performance improvements to XMPP, particularly over constrained or degraded networks. This specification defines a binding for the XMLStream onto multistream transports, including both QUIC and WebTransport. URL: https://xmpp.org/extensions/inbox/xmpp-quic-redux.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 2

Sparse Mesh Federation Topologies
by Dave Cridland 25 Sep '26

25 Sep '26

Hi all, I appreciate that the subject line is a bit, well, pretentious. Sorry. In a meeting the other day, a requirement popped up to avoid the existing full-mesh routing in XMPP. I didn't comment, or explore it. Existing cases (Openfire's "trunking", Metre, Isode M-Link Edge/Gateway) have done this by explicit configuration, some gnarly DNS spoofing, and odd-ball TLS overrides. I'm wondering if it's worth exploring a standards-based solution here, where we'd have something like a routing protocol (like a BGPish or OSPFish thing for XMPP)? This would mean that when a.example talks to b.example, it might be told that b.example can forward traffic to c.example (and possibly how), and a.example could decide by some metrics, configuration, and trust that it would then send traffic to c.example via b.example. Or, not. I imagine the security implications will require quite a bit of thought, to say the least... Is there any interest in discussing this further? Dave.

2 2

XSF membership application period Q4 2026
by Alexander Gnauck 24 Sep '26

24 Sep '26

I have setup the XSF membership application Wiki page for the application period Q4-2026. Applications are encouraged from developers and others who are actively involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki: https://wiki.xmpp.org/web/Membership_Applications_Q4_2026 If you don't have a wiki account, send your full name, preferred nickname and email address to me or one of the other Sysops: https://wiki.xmpp.org/web/Sysops When you need help with your application then don't hesitate to contact me directly Apply now!!! Thanks, Alex

1 0

Re: New QUIC binding
by Dave Cridland 22 Sep '26

22 Sep '26

On Tue, 22 Sept 2026 at 14:14, Florian Schmaus <fschmaus(a)gmail.com> wrote: > > Hi Dave, > > Is there a brief summary about what xep467 and yours do differently? > And, of the same interest, which things you do in a similar way (if any). > XEP-0467 maps a TCP-like XMLStream onto a single bidirectional QUIC stream. Multiple XMLStreams can be carried in a single QUIC connection as multiple QUIC streams. This preserves nearly all the properties of TCP, for good or bad. The good is that XEP-0198 maps across cleanly, the bad is that Head-of-Line blocking affects the entire XMLStream as a whole, just like in TCP. You do, though, get the advantages of QUIC connection migration between, say, 5G and WiFi. It's a good first step, but it's also a dead end because we can't take advantage of other QUIC capabilities. My approach is to have a single XMLStream map to multiple bidirectional QUIC streams. The specification (but not what I implemented) allows for multiple XMLStreams within a single QUIC connection. This avoids HoL blocking between conversations, reducing the effects of poor networks on the XMLStream as a whole, and meant I needed a different approach for "the ticks" - or at least the first one - since XEP-0198 doesn't work. As such, it uses QUIC itself to provide much of what XEP-0198 does, including the first tick. It also allows us to pipe calls, file transfers, and other non-XMLStream data alongside the XMLStream(s) using other QUIC streams and datagrams, in the future. Or possibly even sending XML elements over datagrams, if we're feeling a bit wild. The similarities are really that both approaches use QUIC, and so we get connection migration, round-trip reductions for connect, and so on. You can (in theory, see other note) connect, negotiate TLS, and do SASL authentication in a single round-trip. > > > https://github.com/xsf/xeps/pull/1561 > > Is there a rendered version somewhere? > No, sadly. Dave.

1 0

ProtoXEP: SASL2 Terms of Service Acceptance Task
by Guus der Kinderen 21 Sep '26

21 Sep '26

Hi all, (due to the XSF's mail server's issues of last week, I've sent this email a couple of times. I expect the earlier mails to never be delivered, but in case of a flood of the same message: my apologies). I'd like to submit a proposal for consideration as a XEP. The PR linked below is a draft SASL2 task, built on the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes. It defines a single task on top of the generic <continue/> flow. Briefly, the task lets the server present the current terms and version and the client accept them within the SASL2 negotiation, and treats acceptance as a per-account record the server should persist, with a non-fatal fallback (re-ask next time) for anonymous authentication or a transient storage failure. I'm bringing this at an early stage deliberately: I'd like the list to shape a rough idea through discussion rather than just rubber-stamp a finished one. The alternative to bringing this in rough is having the real discussion happen somewhere else entirely, before it ever reaches this list - I prefer to have that discussion within the XSF ecosystem, because the XSF should be the place where knowledgeable people organize around doing this work, not somewhere they only show up once it's done. Given the recent AI-disclosure thread: this was produced through an extended back-and-forth with Claude, including a full review of the Openfire reference implementation it's based on. The prose is machine-drafted; I made the substantive calls and take responsibility for the result. PR: https://github.com/xsf/xeps/pull/1562 Happy to rework, narrow, or withdraw this based on feedback. Kind regards, Guus

1 0

New QUIC binding
by Dave Cridland 21 Sep '26

21 Sep '26

Hey all, I'm coming to the end of three weeks of testing XMPP/QUIC over "constrained" networks. The networks here aren't actually particularly bad; but the guest WiFi is horrendous, and I've tested some fairly odd-ball things like running XMPP/QUIC over public 4G data at 5,000ft above one of the great lakes, and an alarming number of people testing this (including the nice people with the network degradation hardware) so I've got a new ProtoXEP. This is a new QUIC binding, with WebTransport support, and is entirely and totally incompatible with the existing Experimental XEP-0467. Obviously Travis paved the way here, and I'm late to the party! https://github.com/xsf/xeps/pull/1561 The first thing I'd like to make clear is that I don't think what I've done is "final" in any sense, but it is a practical starting point for useful discussion. I'm 100% open to changes, and fully expect some in the coming weeks. The second thing is that what I've written is not what I have implemented and tested - it's what I suspect I should really have implemented, in hindsight. I didn't think about the stream headers, for example, which allow multiple stream types, or the refinements about ordering rules I've documented here - I just did bare streams and bare jid pair ordering. It works well, but can be improved. As such, I'd like to propose that - as an experiment in ways of working - Council does not vote on this yet, and we should instead discuss as a community and figure out ourselves when it's ready to put before Council (assuming it ever is). But... The basics of this specification (modulo stream headers) are in Wimsy and my "dwd-deploy" branch of Openfire, and have been heavily tested under a range of network conditions. The basics seem to work well, and effectively cope with some awful traffic conditions. I've been working on this for about 6 months, and for most of that time any messages you've seen from me have gone over QUIC for the C2S leg. Dave.

2 2

LAST CALL: XEP-0424 (Message Retraction)
by Daniel Gultsch 20 Sep '26

20 Sep '26

This message constitutes notice of a Last Call for comments on XEP-0424. Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted. URL: https://xmpp.org/extensions/xep-0424.html This Last Call begins today and shall end at the close of business on 2026-07-20. Please consider the following questions during this Last Call and send your feedback to the standards(a)xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!

8 16

ProtoXEP: SASL2 Terms of Service Acceptance Task
by Guus der Kinderen 18 Sep '26

18 Sep '26

Hi all, I'd like to submit a proposal for consideration as a XEP. The PR linked below is a draft SASL2 task, built on the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes. It defines a single task on top of the generic <continue/> flow. Briefly, the task lets the server present the current terms and version and the client accept them within the SASL2 negotiation, and treats acceptance as a per-account record the server should persist, with a non-fatal fallback (re-ask next time) for anonymous authentication or a transient storage failure. I'm bringing this at an early stage deliberately: I'd like the list to shape a rough idea through discussion rather than just rubber-stamp a finished one. The alternative to bringing this in rough is having the real discussion happen somewhere else entirely, before it ever reaches this list - I prefer to have that discussion within the XSF ecosystem, because the XSF should be the place where knowledgeable people organize around doing this work, not somewhere they only show up once it's done. Given the recent AI-disclosure thread: this was produced through an extended back-and-forth with Claude, including a full review of the Openfire reference implementation it's based on. The prose is machine-drafted; I made the substantive calls and take responsibility for the result. PR: https://github.com/xsf/xeps/pull/1562 Happy to rework, narrow, or withdraw this based on feedback. Kind regards, Guus

1 0