- Standards

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

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.

4 3

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

XEP-0332 implementation experience and an offer to work on a revision
by Özcan Oğuz 24 Sep '26

24 Sep '26

Hello everyone, I have been implementing XEP-0332 in xmpp-httpx, a TypeScript library for Node.js and browsers, and would like to share implementation experience and offer to help co-author a revision. The library implements paths for all seven body mechanisms, with documented interpretations and deviations. It has been exercised over Prosody 13 and used by several browser integrations and an HTTP-origin gateway. These are implementation and integration results, not independent XEP-0332 interoperability tests. I also created a WebExtension and Dillo extension for httpx. Code: https://github.com/ooguz/xmpp-httpx Protocol notes: https://github.com/ooguz/xmpp-httpx/blob/main/docs/protocol-notes.md Test coverage and interoperability matrix: https://github.com/ooguz/xmpp-httpx/blob/main/docs/interop.md There are two related areas I would like to discuss and clarify: 1. Clarifying and updating the existing protocol The request/response model has been useful in practice. Several details nevertheless need clarification or an explicit design decision: Chunked transfer completion and failure: empty transfers, missing or conflicting chunks, bounded buffering, and the processing rules for the existing close element. Zero-based numbering is already specified. The unit of maxChunkSize and guidance for accounting for Base64 expansion and the complete stanza envelope. The relationship between an embedded Jingle offer and ordinary Jingle session initiation, acknowledgement, acceptance, and rejection. The allowed request-body mechanisms and their discovery. In particular, our use of IBB for request bodies goes beyond the current response-only restriction. A consistent distinction between malformed HTTPX requests, unsupported transport mechanisms, HTTP errors, and failures after the response IQ has already been sent. Gateway header and body handling, including the existing description of preserving HTTP chunk framing. A migration policy for SIPUB’s deprecated dependencies. I would separate corrections to examples from behavioral changes, and document our implementation choices as such rather than assume that they should become the specification. 1. An optional CONNECT extension A second application suite, n146 (the reason why I started development in the first place) uses the same library as a web-over-XMPP proxy. It is not yet publicc ready and is not an independent protocol implementation. For that application, we implemented an experimental CONNECT mapping: A req with method='CONNECT' identifies a host and port using authority-form. A successful resp identifies an IBB session. The proxy opens that session, which carries tunnel bytes in both directions. This reuses IBB’s explicitly defined bidirectional operation. It extends XEP-0332, which currently excludes CONNECT. In our tests, the mapping supports HTTPS access through HTTP CONNECT and SOCKS5 frontends, including concurrent browser traffic in Chromium and Firefox. These are application-level results; I would not present them as proof that the tunnel semantics are complete. Before proposing normative text, I think we need agreement on connection establishment, graceful shutdown versus abort, pending-data handling, timeouts, peer/session binding, and failures between the successful response and IBB establishment. The current implementation’s shutdown choices need further review. Discovery also needs to identify the precise supported wire format. I would not reuse one feature identifier for both the existing experimental req form and a future standalone connect element without defining how peers distinguish them. For an initial profile, IQ-carried IBB seems a useful baseline. Windowing, bounded buffering, and scheduling across concurrent streams could be documented as implementation guidance, with reproducible benchmarks rather than general performance guarantees. CONNECT and absolute-form forwarding would also require explicit destination authorization, network access restrictions, resource limits, and security/privacy guidance distinguishing XMPP transport encryption from TLS carried inside a tunnel. I would be happy to work with the author and interested implementers on: A focused patch addressing existing ambiguities and example errors. A separately reviewable CONNECT and request-target proposal, either within XEP-0332 or as a companion extension. Shared wire fixtures and interoperability tests against an independent implementation. I can contribute XML patches, examples backed by test fixtures, and the public implementation as an interoperability target. I would welcome feedback on the scope before combining these changes into a revision. Would updating XEP-0332 be the preferred direction, and should CONNECT be considered within that work or separately? Pointers to other implementations, or to earlier discussion of its exclusion, would also be very useful. Sincerely, Özcan Oğuz

3 2

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