- Standards

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

0RTT and Early Data
by Dave Cridland 08 Sep '26

08 Sep '26

Hey all, I would have liked, at this point, to write a nice note about how I've got Early Data working. But I've got several problems with this, both practical and standards related. This email concentrates on the standards side. The goal with this would be that on QUIC, we can connect, establish TLS, perform authentication, binding, stream state configuration, and eventually other things all within the first round-trip. This would result in connections (or at least reconnections - some data needs caching) to occur fast even on quite slow networks. 0RTT "Early Data" is replayable, so an attacker can extract it from the QUIC connection (or TLS handshake on TCP) and re-send it. This can be defeated by counters (as FAST defines in XEP-0484) or by ensuring that the request is idempotent and carries no side-effects (as HTTP recommends). The counter works by defeating the replayability; HTTP's approach means that the replayability no longer matters. The problem with the counter approach we've taken to date is that this immediately onflicts with cases where we do want to replay it for legitimate reasons, such as Happy Eyeballs and similar approaches to "racing" multiple connection attempts. On poor networks, a first connection attempt might succeed, but the response is lost, causing counters to be updated and subsequent attempts to be rejected. The only alternative I can see is to defer any side effects until the handshake completes, noting that this does include resource binding - in particular resource conflict resolution, which often has quite large side effects for the losing session. I think this seems vaguely possible, but I worry I have forgotten other side effects. The other potential problem is that the early data is sent, and processed, before most channel binding types are available, in particular the TLS Exporter type. I suspect - and if you know, please chip in - that this is OK, in as much as if the handshake completes with the session ticket and PSK then the original channel binding from the first connection still holds, in effect, as proof that the endpoints remain unchanged. But I would really like to know for sure. Finally, I note that because we're reliant on handling the early data before a client can receive the features, then either the client should "just know" the available mechanisms for early data authentication, or else it will need to be told in a previous session. And IAP (XEP-0509) needs to work, so the actual features/config inputs used to calculate that need to remain unchanged. Anyway, would appreciate any notes/ideas others have on this area! Dave.

1 0

XMPP Council Agenda 2026-09-08
by Daniel Gultsch 08 Sep '26

08 Sep '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, September 8 2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update none 4) Items for voting a) XEP-0292: Fix examples https://github.com/xsf/xeps/pull/1560 b) Move 'XEP-0424 (Message Retraction)' to stable https://xmpp.org/extensions/xep-0424.html 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh… 6) Date of Next 7) AOB 8) Close

1 0

XMPP Summit 29 (Friday + Saturday)
by Daniel Gultsch 03 Sep '26

03 Sep '26

Hi all, the 29th XMPP Summit is coming up in a little over 24 hours. Friday and Saturday from 13:00-16:00 UTC. This is our first online summit and is hosted on a Big Blue Button server provided to us by the FSFE. https://conf.fsfe.org/b/mkw-hvi-ujx-kb7 This is your last chance to propose some topics on our wiki. https://wiki.xmpp.org/web/Conferences/Summit_29#Proposed_Topics We will be voting on the 4 topics that we are going to be discussing very early in our Friday time slot. So be on time and do get familiar with the topics beforehand. On time means 20 minutes early! The room will be open and we will be having some nice hallway discussions. cheers Daniel

1 0