April 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

Proposed XMPP Extension: Payment Required
by Daniel Gultsch 15 Jun '26

15 Jun '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Payment Required Abstract: This specification defines an XMPP protocol extension that enables services to require payment before granting access to a resource. It provides a payment-system neutral invoice format supporting multiple concurrent payment options, including bank transfers (SEPA, IBAN, UPI) and instant-settlement networks (Lightning Network), and integrates with the existing CAPTCHA challenge mechanism defined in XEP-0158. URL: https://xmpp.org/extensions/inbox/payment-required.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

8 11

Proposed XMPP Extension: New MUC
by Daniel Gultsch 12 May '26

12 May '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: New MUC Abstract: This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045, but adds a number of key improvements. URL: https://xmpp.org/extensions/inbox/new-muc.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

6 26

HTTP file upload and administrative boundaries
by Dave Cridland 30 Apr '26

30 Apr '26

Hi all, Some of the work I'm dealing with has the requirement that clients belonging to their organisation shouldn't access arbitrary HTTP endpoints outside their administrative boundary. I think this is a reasonable requirement. As an example, if A(a)a.example wants to send a file to B(a)b.example, A uploads to their own server, which: * Might (or might not) perform virus scanning, and * Might (or might not) log IP addresses and other activity, and * Might (or might not) expire the file sooner than B's organisation's retention policy. Some of these "might (or might not)" cases are probably specific to enterprise cases, but others are more general and apply to consumer/private messaging too. What I'd like to explore therefore is whether we could have B's server pull a copy of the file for B to access, processing and retaining it as B's organisation requires. But, and here lies my problem, I have literally no idea how to go about this without disruption to the generally working case of HTTP upload. Anyone got any ideas? Dave.

3 2

GC3 in 2026
by Matthew Wild 30 Apr '26

30 Apr '26

Hi folks, As promised in another thread, I'm posting a round-up of "GC3" resources. But first, I'll summarize what this is about for people who missed the summits/sprints where it was discussed. The idea grew, from discussions with a few people, that it would be good to level up group chats in XMPP, without breaking significantly with the extremely entrenched MUC protocol. In fact, we have already extended MUC (XEP-0045) in various ways, both by updating XEP-0045 itself and through various add-on XEPs in recent years, some with relatively rapid adoption (XEP-0421), and others not so rapid (yet?). There has been vague occasional talk of "MUC 2" for a very long time (since before MIX), mostly various isolated ideas for improvements. I wanted to try and finally glue some of these ideas together, without necessarily "stealing" the title as an official MUC successor, so "GC3" became a working title. Shortly after I'd started gathering this together, we held a sprint in the UK. A lot of that sprint ended up being reviewing the GC3 wishlist, priorities, eliminating some bad ideas, and clarifying some possible approaches. The slides of the GC3 presentation I gave at Summit 27, a few months later, are here: https://matthewwild.co.uk/uploads/xmpp-gc3-jan-2025.pdf The main GC3 notes, including feedback from the sprint and summit, are available here: https://pad.nixnet.services/s/7xKNOKxxE In addition to the notes, there have been a couple of partial attempts at turning it into something more like a specification. This one by Jonas: https://pad.nixnet.services/s/yu7drWpml This one by Kev: https://github.com/swift/protoxeps/blob/master/gc3.md Both these are missing some things, they probably overlap in some areas and conflict in others. But definitely together they form the basis of anything that would become a GC3 XEP. Apart from this, Kev also produced some additional related documents: - https://github.com/swift/protoxeps/blob/master/acl.md - https://github.com/swift/protoxeps/blob/master/related-entities.md These were spawned from GC3 discussions, but could certainly stand as XEPs in their own right. I don't want to speak for Kev, but I assume if there is sufficient interest then he would be willing to work further on these and get them submitted, or have someone else help to do so. Okay, that's the status of documentation. Partly because of the numerous ideas floating around, I also wanted to work on at least a rough prototype implementation of at least some core parts of the code. Just to try out the approach and prove it can work. I know that implementation isn't required by the XSF in order to have an experimental XEP. However, faced with the decision between spending time on writing a GC3 XEP, and figuring out if it can even be implemented, I personally chose to prioritize the latter. This isn't any kind of statement about whether or not there should be a GC3 XEP submitted at this stage, I *personally* just don't want to spend time writing such a broad XEP for a protocol that may need drastic changes as soon as anyone tries to implement it. I won't (and, anyway, can't) stop someone else with time and motivation from doing what they want (implementation or specification) with any of the "GC3" notes we've gathered. I presented them at the summit precisely with the hopes that everyone interested in the topic may do exactly that, so we can move the thing forward. After the summit presentation, I started making some necessary changes to the Prosody MUC code to allow us to accommodate some of the discussed GC3 features. Mainly internal refactoring of some APIs and data structures to make it more extensible and support chats where we have mixed MUC and GC3 clients. The only externally visible change in Prosody so far, is that I began implementing a participant list fetch protocol (behind an experimental feature flag). Ironically, it's one of the parts of the protocol we deemed during the sprint as high priority and yet we don't actually have a protocol for this written anywhere in the several "GC3"-related documents, yet. One of the features of such a protocol would be paging, e.g. using RSM. Prosody's implementation doesn't currently support this. I immediately ran into the problem that to support paging, the participant list needs to be ordered and stable. Currently Prosody stores affiliations and participants in unordered hash tables. Another thing that needs refactoring. Okay, that's the implementation update from me. Now, the status and future of GC3... It appears from discussions that multiple people have come to view me as having some kind of "ownership" over GC3. This was entirely unintended and very unfortunate. It's true (I think?!) that I picked the name, and I wrote the first draft of notes. However I think by now that between various discussions online and offline across and venues (regrettably not this list?), my personal contributions to the whole thing are quite outnumbered by others. Obviously if nobody else beat me to it, at some point writing a GC3 XEP was inevitably on my todo list. So I accept that I'm somehow the "default" person in a way - going to push this forward, eventually, if nobody else can/will. But it seems somehow this appeared as some kind of exclusivity, and this was likely due to poor communication on my part. In that regard, I am glad that Dave ignored this and broke the ice with the MUC2 proposal regardless, surfacing this whole issue. I like collaborating with smart folk, it's why I am here and why I do open-source. But I (and I'm not alone) have far more ideas, wishes and responsibilities than I have time to work on all at once. Sometimes this also means I get rather behind on emails, or that I might miss MUC discussions. If anyone else feels that I am somehow blocking them from doing what they want - I'm always willing to talk it over. And if that fails, please, just go ahead and do it. Now, finally, GC3 future... Realistically, I'm unlikely to change trajectory. I have a long list of stuff to do, and honestly, GC3 is outranked by various other priorities for the coming month or two at least. This means, I see the following possible outcomes: - MUC2 halts and nothing further happens until I finally get around to a GC3 XEP (nobody wants this) - MUC2 continues as a from-scratch parallel effort (not ideal in my opinion, but I can't and won't block such an effort, especially not if others think it's a good path) - MUC2 is at least informed and improved by the prior work on GC3, adopting as much or as little as deemed appropriate. Even if it ultimately adopts none of it, I think this would be a win. What I care about is that we arrive at a good MUC successor XEP with a good path to adoption. I will say it again just to be clear here: I don't care what it's called, or whose name(s) are on the document. Regards, Matthew

1 0

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

QUIC multi-stream
by Dave Cridland 30 Apr '26

30 Apr '26

Hi all, I've submitted a PR against XEP-0467 for QUIC multi-stream support. The PR points to a PoC implementation for C2S on both client and server - I should note these both currently only work on Linux. They do run, though, and I'm using them as my "daily driver". You should definitely not do this, the code is demonstrably unsafe (due to implementation, not the spec). This will all need substantial tweaking before it's really where I'd like it, but the key features are that one conversation need not HoL block another. This builds on QUIC's migration etc. The downside of this approach is that it utterly kills XEP-0198. XEP-0198 is predicated on stream state being able to be captured in just two integers and an opaque id. QUIC essentially handles the resumption case, but QUIC connection state is much more complex than two integers, and we lose the common usage of XEP-0198 <r/> - <a/> to drive "single-tick" state. We'll need something new to replace it. If you are familiar with QUIC then you are likely much more familiar with QUIC than I am; please please do review and discuss! Thanks, Dave.

1 0

Proposed XMPP Extension: Emoji Markup
by Daniel Gultsch 27 Apr '26

27 Apr '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Emoji Markup Abstract: This specification leverages and (or ) to send custom emojis URL: https://xmpp.org/extensions/inbox/emoji-markup.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

7 22