- Standards

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

XEP-0388 xs:sequence in schema
by Dave Cridland 29 Aug '26

29 Aug '26

Hey folks, Travis pointed out a "bug" in ejabberd around the ordering of SASL2 elements, because XEP-0388 uses xs:sequence I suspect this isn't a bug in ejabberd, but a bug in XEP-0388 for using xs:sequence instead of xs:all - I suspect I wrote this and was just being rubbish at writing schemas, and didn't intend to impose an ordering, much less have receiving implementations depend on it. How much pain would it be to just change it? Dave.

2 1

XEP-0474: proposal to add more test vectors (verification needed first)
by Guus der Kinderen 28 Aug '26

28 Aug '26

Hi all, I've recently implemented XEP-0474 (SASL SCRAM Downgrade Protection, version 0.5.0) in Openfire. The example in section 6.3 was useful during that work. While writing tests I generated a handful of additional vectors, and I think the XEP would be more useful to implementers if it carried a few more of them. The cases I found worth pinning down: - the 6.3 example extended to SHA-256 and SHA-512, since the specification applies to any SCRAM hash function but only exemplifies one; - a case where no channel-binding types were advertised, which is where an implementation might wrongly emit a bare %x1F separator; - a case including non-SCRAM mechanisms (PLAIN, EXTERNAL), making it explicit that the full advertised mechanism list is hashed, not just the SCRAM ones; - the single-entry degenerate cases. In A and C the values are deliberately listed in an order that differs from the sorted order, so an implementation that skips the i;octet sort will fail those two. B, D and E instead pin down the presence or absence of the %x1F section. The vectors are below. I've given the hash input both as an escaped string and as hex, so that the list construction and the hashing can be checked separately. Important caveat: these come from a single implementation (mine). The SHA-1 value of the first one is the only one that is already published in the XEP. I would not want the others added to the specification on the basis of my implementation alone: A test vector that is wrong is worse than no test vector. So: would anyone with an independent XEP-0474 implementation be willing to check them? If more people arrive at the same values independently, I'm happy to write them up as a pull request against the XEP in whatever form the author and council prefer. If anyone arrives at different values, that is an even more interesting result - please let me know either way. -- A. The existing §6.3 example ------------------------------------------ advertised mechanisms : SCRAM-SHA-1, SCRAM-SHA-1-PLUS advertised cb types : tls-server-end-point, tls-exporter hash input : SCRAM-SHA-1%x1ESCRAM-SHA-1-PLUS%x1Ftls-exporter%x1Etls-server-end-point input (hex) : 534352414d2d5348412d311e534352414d2d5348412d312d504c55531f746c732d6578706f727465721e746c732d7365727665722d656e642d706f696e74 SHA-1 : G6k/rBLDqgOhRRaCuuatSDFkJ08= SHA-256 : H6VEQ+6wl/eYKuTjJn4D9/e9GTn1AcYGw/oiSJ3Yhy0= SHA-512 : Q1q0WwH927l2RRoYIMiDY0g7R21hTZK+bfBgkhqek9JSTfIzUlnUZQRB2A6lZL3ER7ZMWRRdQzEJKVH671Bh0g== -- B. Same mechanisms, no channel-binding advertised ---------------------- advertised mechanisms : SCRAM-SHA-1, SCRAM-SHA-1-PLUS advertised cb types : (none) hash input : SCRAM-SHA-1%x1ESCRAM-SHA-1-PLUS input (hex) : 534352414d2d5348412d311e534352414d2d5348412d312d504c5553 SHA-1 : g00gt4Qd0gJ3EvnclTnY0KEYfRg= SHA-256 : Uuua9QJnTss43LMyJpE0esh43d9r8DB6N89DXs91aFo= SHA-512 : eOeUdpE/0pNIUnVTIcURoWHTT22Ohgk8C5/03RZTyqK9vShp/jK5G+v7G36yqSEsZgXnH7wVq2gBuUxm11OEHA== -- C. Full advertisement, including non-SCRAM mechanisms ------------------ advertised mechanisms : SCRAM-SHA-1, SCRAM-SHA-1-PLUS, SCRAM-SHA-256, SCRAM-SHA-256-PLUS, PLAIN, EXTERNAL advertised cb types : tls-unique, tls-exporter, tls-server-end-point hash input : EXTERNAL%x1EPLAIN%x1ESCRAM-SHA-1%x1ESCRAM-SHA-1-PLUS%x1ESCRAM-SHA-256%x1ESCRAM-SHA-256-PLUS%x1Ftls-exporter%x1Etls-server-end-point%x1Etls-unique input (hex) : 45585445524e414c1e504c41494e1e534352414d2d5348412d311e534352414d2d5348412d312d504c55531e534352414d2d5348412d3235361e534352414d2d5348412d3235362d504c55531f746c732d6578706f727465721e746c732d7365727665722d656e642d706f696e741e746c732d756e69717565 SHA-1 : SQjUrwq125kFEHbaywmNGkNY8NI= SHA-256 : jl3RxAJC6h0xX0nWBprC7vAD09HBsUNvCx5Ei/97Lt4= SHA-512 : 8822jz/cRVDn3bk/XTx/RgrUHucqhcpcqWTOzXIU8lMwLZr2aKT/GXnqYdLWDLZS/qkmt7vmkPM7FJ0I8ADi2Q== -- D. Minimal: one mechanism, one channel-binding type -------------------- advertised mechanisms : SCRAM-SHA-256-PLUS advertised cb types : tls-exporter hash input : SCRAM-SHA-256-PLUS%x1Ftls-exporter input (hex) : 534352414d2d5348412d3235362d504c55531f746c732d6578706f72746572 SHA-1 : 50fovNdJS+nqcJ0IYUsXqRTUrtU= SHA-256 : vxAYBdhmEYs9EAv8GQJQqk2YPUoLPUaj9em9zXzXzA0= SHA-512 : Fk0ja0KqooAP1flikg4vmSejIFhTSExpY1qISx86+1xAgftZDqyAN0cokd2RWPt1ttQSYlxr2EA8BRj7jwLiow== -- E. Single mechanism, no channel-binding advertised --------------------- advertised mechanisms : SCRAM-SHA-1 advertised cb types : (none) hash input : SCRAM-SHA-1 input (hex) : 534352414d2d5348412d31 SHA-1 : LrtFoCs8XsoI+diY4u3rG69UGN8= SHA-256 : hzhrgAj6xgd4yQIejnb2tHGgllHiKhjRwvofy7ETi64= SHA-512 : EMrc8V7X7onzZnTj6wtLdWqN9CM6v3VhUIZ2Th01rCX/uSlNzKVafB2MBIriyBEjzGLGEjlnn1e8nI4LHR4rDQ== Kind regards, Guus

2 1

UPDATED: XEP-0490 (Message Displayed Synchronization)
by Daniel Gultsch 26 Aug '26

26 Aug '26

Version 1.1.0 of XEP-0490 (Message Displayed Synchronization) has been released. Abstract: This specification allows multiple clients of the same user to synchronize the displayed state of their chats. Changelog: * Add security consideration for sender verification of PEP notifications. (dg) URL: https://xmpp.org/extensions/xep-0490.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

UPDATED: XEP-0084 (User Avatar)
by Daniel Gultsch 26 Aug '26

26 Aug '26

Version 1.1.5 of XEP-0084 (User Avatar) has been released. Abstract: This document defines an XMPP protocol extension for exchanging user avatars, which are small images or icons associated with human users. The protocol specifies payload formats for both avatar metadata and the image data itself. The payload formats are typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163. Changelog: Fix inconsistent hash in the example with multiple data sources for the same file. (nc) URL: https://xmpp.org/extensions/xep-0084.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0