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
Hi folks,
I'm curious if anyone has thoughts on being able to undo a XEP-0425
moderation action.
The use cases I have in mind are:
- admin accidentally moderated the wrong message
- one admin moderates a message, but after consideration/discussion
with other admins, it is decided it shouldn't have been moderated
- reverting automated moderation after human review
This last point is the one that sparked this email, however I have
experienced the other cases as well over the past couple of years.
For the automated case, all I necessarily want is for clients to hide
(by default) messages in a group chat which are likely to be spam, for
example if some trusted but non-admin users have reported it. When an
admin does respond, they could then moderate the message fully, or
unhide it (if the report was incorrect, e.g. malicious).
This hiding/unhiding could be a new XEP, or we could solve
"unmoderation", which solves the other use cases and probably makes
the most sense.
Thoughts?
Regards,
Matthew
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Message Archive Management: Trim Command
Abstract:
This specification describes how a client can request "trimming" of an
archive
URL: https://xmpp.org/extensions/inbox/xep-mam-trimming.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 0.1.0 of XEP-0513 (Explicit Mentions) has been released.
Abstract:
This specification defines a way to explicitly mention a person or
groups of people.
Changelog:
Accepted as Experimental by council vote on 2026-03-31 (dg)
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.
Version 5.6.7.8 of XEP-0512 (XMPP as Interpretive Dance) has been
released.
Abstract:
This document defines a method for representing XMPP communications
through the medium of interpretive dance. By mapping core protocol
elements to specific physical movements, it allows expressive, low-
bandwidth, and audience-friendly implementations of XMPP suitable for
artistic performances, theatrical demonstrations, and deeply confusing
hackathons.
Changelog:
Initial published version. (gdk)
URL: https://xmpp.org/extensions/xep-0512.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.
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
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
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.
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.
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!
