March 2026 - Standards

LAST CALL: XEP-0424 (Message Retraction)
by Daniel Gultsch 03 Jul '26

03 Jul '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 2025-01-06. 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!

9 27

Scoping discussion: updating XMPP RFCs / XMPP 2.0
by Guus der Kinderen 29 Jun '26

29 Jun '26

Hi all, At the recent Summit, we had a long and nuanced discussion about the state of the XMPP RFCs and whether there is value in updating parts of them, potentially through the IETF, to better reflect how XMPP is actually implemented and used today. To be clear upfront: This is not a proposal to start an IETF working group, nor a commitment to produce new RFCs. The discussion at the Summit surfaced enough open questions that it seems worthwhile to first have a focused scoping and feasibility discussion. Some of the motivations that were raised: - The current RFCs do not describe a baseline that results in interoperable modern implementations - Discoverability for new implementers is difficult (knowing which XEPs are "essential") - The IM landscape has changed significantly since the original RFCs - External review and feedback could be valuable - There may be marketing and positioning benefits, but these are secondary At the same time, many concerns were raised: - The sheer amount of work required, and whether we realistically have the manpower - Risk of scope creep (e.g., baking too much into RFCs) - Loss of flexibility compared to the XEP process - Fear of starting something we cannot finish - Unclear interaction with compliance suites and the "living standard" nature of XMPP - Potential pushback or distraction from other IETF efforts (e.g., MIMI) Questions that seem worth discussing at this stage: - Is it useful to think about updating some RFCs (e.g., core, IM), while leaving the rest to XEPs? - What would be clearly in-scope vs out-of-scope? - Is there enough interest and capacity to justify exploring this further? - What would be a sensible first step that does not overcommit us? If you were at the Summit and felt strongly one way or the other, it would be great to hear your perspective here. If you weren't, fresh viewpoints are equally welcome. The goal of this thread is simply to assess whether this topic is worth pursuing further, and if so, in what very limited and realistic form. Kind regards, Guus

7 9

Proposal: Add <no-notify/> hint to XEP-0334 (Message Processing Hints)
by Laura G. 22 Jun '26

22 Jun '26

I'd like to propose adding a new processing hint to XEP-0334 to support silent/whisper messages - messages that are delivered normally but don't trigger notifications on the recipient's device. Use Case: My mother and I communicate via XMPP throughout the day. She frequently participates in screen recordings and video calls (about 1 hour daily) where notification sounds and popups would be disruptive. However, she doesn't want to use DND mode because she needs to remain reachable for genuine emergencies. The solution we need: the ability to send non-urgent messages silently so she can read them when she next checks her client, without interrupting her work. User Demand: This feature is heavily requested across messaging platforms. A quick search shows thousands of users asking "how to send silent messages" or "send without notification" for Facebook Messenger, WhatsApp, Telegram, and other platforms. Telegram already implements this as "send without sound." The demand is clear and widespread. Proposed Addition to XEP-0334: A <no-notify/> processing hint with the following semantics: <message to='recipient(a)example.com' type='chat'> <body>Please look at the following when you have time: ...</body> <no-notify xmlns='urn:xmpp:hints'/> </message> Behavior: - The receiving client SHOULD NOT trigger audio/visual notifications - The message SHOULD still be delivered and stored normally - The message SHOULD appear in the chat history - The message MAY still update unread counts (implementation-dependent) - Clients MAY provide UI indication that a message was sent silently Benefits: - Allows nuanced communication without forcing binary DND states - Respects recipient's focus/workflow while maintaining async communication - Reduces notification fatigue - Provides sender control over message urgency - Simple to implement - clients already have notification suppression logic Backwards Compatibility: Clients that don't recognize <no-notify/> will simply deliver the message normally, which is acceptable fallback behavior. This would be a natural extension to the existing hint types in XEP-0334 (no-store, no-copy, store, no-permanent-store) and addresses a genuine gap in XMPP's messaging capabilities. Thoughts? Is this something the community would support adding to XEP-0334, or would it be better suited as a separate XEP? Best regards, L.G. I'm using an email mask just because I don't want recruiters to get a view of my personal life, please consider the proposal objectively.

6 8

QUIC(ker)
by Dave Cridland 30 Apr '26

30 Apr '26

Hey all, Some of you have heard me talk about this at the Summit, but I'd like to revisit/reexamine our QUIC binding to improve performance of XMPP on low bandwidth. I'm not sure we'll get to this at the Summit, and there's not many who want to talk about it so I wondered if this summit topic could have been an email. (Except then we discussed it anyway) The primary concerns on low bandwidth - beyond sending fewer bytes on the wire - are round-trips and head-of-line blocking. I think XMPP has a good story on round-trips; we're down to very few during authentication and connection setup, and during normal messaging operation we don't worry about latency at all. Head-of-Line blocking, or HoL Blocking, is when - in our case - packet loss causes the stream to stall until the packet is retransmitted, which is at least a round-trip away - and can be more due to bandwidth-delay product. At the same time, we cannot eliminate this entirely (by, say, sending stanzas over UDP directly) because if we do that we lose the ordering. Out of order messages can be confusing, and lead to bad misunderstandings. The rules on this are in RFC 6120, and are rather more complicated than we normally worry about - normally, we just process everything on a strea, in order, and this does satisfy the rules. But the rules allow us to process stanzas in any order we like, as long as So, what I'm thinking is a way to use the additional channels in QUIC such that we open multiple channels on both C2S and S2S sessions, which would form part of the same virtual stream, and we can distribute messages such that we maintain ordering within messages where we need to, but allows us to out-of-order (and avoid HOL Blocking) messages sent between unrelated jids. This differs to the existing XEP, where each channel maps to a single XML Stream and XMPP session. Notes from the Summit: WEBTRANS would also be of interest, but "raw" QUIC has some advantages as well, so we probably want both with a uniform approach. So, my plan is to get an implementation together and a XEP. Anyone else interested? Dave.

6 18

Proposed XMPP Extension: Explicit Mentions
by Daniel Gultsch 02 Apr '26

02 Apr '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Explicit Mentions Abstract: This specification defines a way to explicitly mention a person or groups of people. URL: https://xmpp.org/extensions/inbox/explicit-mentions.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

11 65

Extending XEP-0313 with trimming support
by Matthew Wild 31 Mar '26

31 Mar '26

Hi folks, There are a few limitations with XEP-0313 which I've been hoping to address for a while, mostly around giving users more control and making it easier for operators to comply with various data protection requirements. Users have control over most account data in XMPP. However archives are, generally, read-only. In particular, user data should generally be deleted upon request. Currently such requests would have to be manually sent to the service operator, as there is no in-band method for this yet. My proposal is to support an in-band 'trim' command, which allows removal of all archived messages, or up to (and including) a specific archived message, or deletion of the entire archive. The functionality is optional and discoverable, so shouldn't affect backwards compatibility. This has some limitations. For example, it wouldn't allow selectively deleting all messages with a specific contact, which is occasionally requested. Such an operation would leave holes in the archive (which XEP-0313 forbids to ensure sync points don't get removed). But I'm in favour of solving what we easily can for now. There are other things I would like to improve around archiving, such as exposing retention configuration. But I plan for these to live in new XEPs. As XEP-0313 is stable and almost universally implemented, I wanted to raise awareness of this proposal and seek some consensus from the community before pushing it forward to Council. The PR can be found at https://github.com/xsf/xeps/pull/1514 The new section is rendered at https://matthewwild.co.uk/uploads/xep-0313.html#trim Regards, Matthew

4 9

XMPP Council Agenda 2026-03-31
by Daniel Gultsch 31 Mar '26

31 Mar '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, March 31 2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join Notice the time zone change. For some people this might now be an hour later than usual. The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update • LAST CALL: XEP-0377 (Blocking Command Reports) • UPDATED: XEP-0461 (Message Replies) • UPDATED: XEP-0493 (OAuth Client Login) The two updated XEPs are just minor editorial changes. 4) Items for voting a) XEP-0045: Add clarification regarding unsetting reserved nicknames https://github.com/xsf/xeps/pull/1512 5) Pending votes Marvin, Stephan Paul, Dan, Jerome on XEP-xxxx: Explicit Mentions (https://xmpp.org/extensions/inbox/explicit-mentions.html) See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh… 6) Date of Next 7) AOB 8) Close

1 0

UPDATED: XEP-0493 (OAuth Client Login)
by Daniel Gultsch 31 Mar '26

31 Mar '26

Version 0.1.1 of XEP-0493 (OAuth Client Login) has been released. Abstract: This specification details how a third-party can be securely granted access to an XMPP account without exposing the account credentials, using OAuth. Changelog: * Fix reference to RFC 7628 for SASL OAUTHBEARER (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0493.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-0461 (Message Replies)
by Daniel Gultsch 31 Mar '26

31 Mar '26

Version 0.2.1 of XEP-0461 (Message Replies) has been released. Abstract: This document defines a way to indicate that a message is a reply to a previous message. Changelog: Update the example to use the correct fallback namespace. (mye) URL: https://xmpp.org/extensions/xep-0461.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-0377 (Blocking Command Reports)
by Daniel Gultsch 31 Mar '26

31 Mar '26

This message constitutes notice of a Last Call for comments on XEP-0377. Title: Blocking Command Reports Abstract: This document specifies a mechanism by which reporting information can be attached to a Blocking Command (XEP-0191) request. It enables servers to process reports related to blocked entities while remaining focused on this specific workflow rather than general abuse reporting. URL: https://xmpp.org/extensions/xep-0377.html This Last Call begins today and shall end at the close of business on 2026-04-14. 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!

1 0