- Standards

NEW: XEP-0519 (Portable Import/Export Format for XMPP Components)
by Daniel Gultsch 13 Nov '26

13 Nov '26

Version 0.1.0 of XEP-0519 (Portable Import/Export Format for XMPP Components) has been released. Abstract: This document specifies a file format for importing and exporting component data to and from XMPP software Changelog: Accepted as Experimental by council vote on 2026-11-10 (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0519.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

NEW: XEP-0521 (Jingle Audio/Video Conferences)
by Daniel Gultsch 13 Nov '26

13 Nov '26

Version 0.1.0 of XEP-0521 (Jingle Audio/Video Conferences) has been released. Abstract: This specification defines a way to hold multiparty conferences with an SFU via Jingle. Changelog: Accepted as Experimental by council vote on 2026-11-10 (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0521.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

NEW: XEP-0520 (SASL2 Terms of Service Acceptance Task)
by Daniel Gultsch 13 Nov '26

13 Nov '26

Version 0.1.0 of XEP-0520 (SASL2 Terms of Service Acceptance Task) has been released. 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. Changelog: Accepted as Experimental by council vote on 2026-11-10 (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0520.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

LAST CALL: XEP-0424 (Message Retraction)
by Daniel Gultsch 13 Nov '26

13 Nov '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 19

Re: LAST CALL: XEP-0424 (Message Retraction)
by violet＠nullhost.de 13 Nov '26

13 Nov '26

Hello! Apologies in advance; I've just subscribed to the mailing list (so I can't reply to the thread), and I'm also a pretty new XMPP developer (I've definitely missed the Last Call). > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes! > 2. Does the specification solve the problem stated in the introduction > and requirements? Mostly. I have a specific concern for retraction in 1:1 chats, where retractions target the @id. RFC 6120 states the @id can be unqiue to the stream, or across all streams (aka "global"), where this is up to the sender. For an XEP that uses @id to refer to *any* previously sent message, even requiring supporters to use a global @id is not enough, as the RFC also makes no mention of what happens to the @id outside of that stream (only that entities use it to know some response was a direct result of a stanza they sent within that stream). Because of this, it seems to me that an entirely valid client implementation is to count up from 0 for each stanza sent in that stream (maybe due to lightweight requirements where there is no CSPRNG?), and their server can route that stanza along with an entirely different @id, as long as it remembers the link between that @id and the one the client used for when a response is sent back to that client. (I would also like to submit that, while such an implementation would be expensive, and I cannot prove that implementations like this currently exist, we should still take them into account as they are fully compliant, and not doing so is how we make specifications that can be unreliable.) Requiring entities to also not modify the @id when sending into different streams would have considerations for entities that don't support the specification (thus the @id can be different for others). And if supporting entities don't modify an @id from an unsupporting entity, that could also possibly break stream-uniqueness guarantees. I am sure there are many similar issues. An XEP which successfully uses @id in 1:1 is LMC, as it is explicitly limited to the last message. Thus, if there are multiple messages from that entity with that @id, the message to be corrected is the most recent one from them at that time, with that @id. If we want to target *any* previous message, this cannot be done. > 3. Do you plan to implement this specification in your code? If not, > why not? As it is currently written, no. I believe 0359's <origin-id/> would be one possible solution for the above, as that element (and even the name of 0359) seems to have been written specifically for this problem. Looking at the commit history for 0424, this used to be the case until ~2 years ago! I would love to hear why it stopped being used. > 4. Do you have any security concerns related to this specification? Maybe not necessarily security-related, but it seems entirely possible to write fully-compliant implementations which can break in 1:1 chats, due to the instability of @ids. > 5. Is the specification accurate and clearly written? I have two nitpicks with its wording: > Supporting clients MUST set a unique 'id' on the <message> element in > outgoing stanzas (as per Unique and Stable Stanza IDs (XEP-0359) [9]), > [...] "unique" here could be interpreted, using the RFC, as unique to one stream or across all streams. Additionally, 0359 makes zero mentions of requiring supporters to handle @ids any differently (it only introduces <stanza-id/> and <origin-id/>), while this passage states it does. This could cause problems where entities may check for 0359 support, and then incorrectly assume a behavior entirely unspecified by 0359. This mistake is actually made later in 0424: > Clients that don't support Unique and Stable Stanza IDs (XEP-0359) [9] > (and therefore don't support Message Retraction (XEP-0424) [14]), > are not guaranteed to have a unique 'id' attribute on their <message> > elements. > [...] > To mitigate this, clients can do a Service Discovery (XEP-0030) [1] request > to check if the other client supports XEP-0359, and if not, [...] I am sure this XEP will eventually see a lot of adoption in the future (and it definitely serves a very important purpose in my eyes), but as it currently stands for 1:1, I see some edge cases that I would prefer not to have to debug, whenever they become an issue. Thank you all for your efforts to maintain the XMPP ecosystem. — Violet

3 2

UPDATED: XEP-0513 (Intentional Mention Markup)
by Daniel Gultsch 12 Nov '26

12 Nov '26

Version 0.1.1 of XEP-0513 (Intentional Mention Markup) has been released. Abstract: This specification defines a markup format to intentionally mention a person or groups of people. Changelog: Revisions based on feedback, including using XEP-0394, making different types of mentions more consistent between each other, using existing terminology from legacy messengers, removing the permissions form, and generally removing unneeded functionality. (snit) URL: https://xmpp.org/extensions/xep-0513.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-0338 (Jingle Grouping Framework)
by Daniel Gultsch 12 Nov '26

12 Nov '26

Version 1.1.1 of XEP-0338 (Jingle Grouping Framework) has been released. Abstract: This specification provides an XML mapping for translating the RFC 5888 SDP Grouping Framework to Jingle Changelog: Add the XML Schema. (egp) URL: https://xmpp.org/extensions/xep-0338.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-0045 (Multi-User Chat)
by Daniel Gultsch 12 Nov '26

12 Nov '26

Version 1.35.6 of XEP-0045 (Multi-User Chat) has been released. Abstract: This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc. Changelog: * Standardize the muc#roomconfig_enablearchiving field (XEP Editor) URL: https://xmpp.org/extensions/xep-0045.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

HTTP file upload deletion
by Matthew Wild 11 Nov '26

11 Nov '26

Hi folks, We had a brief discussion at the current XMPP London sprint about allowing a user to delete their uploaded files. I know I've been thinking about this for a long time, and I think there have been prior discussions (on this list?) about potential approaches. Today we discussed options, and picked the one that seems feasible to implement in the codebases represented here. The PR for the XEP is at https://github.com/xsf/xeps/pull/1584 The submitted approach uses an iq request to the XMPP server with the GET URL of the file to be deleted. Other approaches discussed in the past include using the HTTP DELETE verb (e.g. on the slot's PUT URL or the service could return a special deletion URL in the slot response). This approach fails because the client requesting the deletion might not be the same client that requested the slot. It therefore won't have access to the secret URLs. The downside is that the XMPP server has to keep track of this, which I know will impact Prosody at least, where we have support for external upload services, and we don't necessarily track files past the initial slot request/response. But I'm confident we can find solutions, and implementing deletion is important. The iq is in a new namespace, so it's easily discoverable and backwards-compatible. I also know that there are other more generic file management proposals/protocols around, and I don't think adding this stanza to XEP-0363 necessarily competes with those. Regards, Matthew

5 12

SFS vs SIMS vs OOB vs...
by Dave Cridland 08 Nov '26

08 Nov '26

Hi all, I propose that we do SFS, and drop the others. It's a bit silly having three file sharing things. SIMS is Deferred, currently, which is as dead as an Experimental XEP can be, but adding a note at the top to state that it's recommended to do SFS instead seems sensible. OOB is Stable, I suggest we move it to Deprecated. SFS and FME are both Experimental, so need advancing through to sensibly Deprecate OOB. In summary then: 1) Last Call XEP-0446, move to Stable. 2) Last Call XEP-0447, move to Stable. 3) Deprecate XEP-0066 (with note pointing to XEP-0447). 4) Add similar note to XEP-0385 but leave in Deferred. I'd like to build consensus for this, so: - Does anyone object? If so, how, why, and what would fix this? - Does anyone agree with me? Can we improve the plan? Dave.

8 19