- Standards

XEP-0077 password change
by Stephen Paul Weber 17 Apr '26

17 Apr '26

It seems to me that XEP-0077 is not RFC compliant in section 3.3 specifically it says: > In order to require additional information before changing the password, > the server or service SHOULD return a Data Form in the error stanza: However https://datatracker.ietf.org/doc/html/rfc6120#section-8.2.3 says: > An IQ stanza of type "error" MAY include the child element > contained in the associated "get" or "set" and MUST include an > <error/> child That is to say, it may not contain any child other than an <error/> child and possibly an echo of the request. Now, one could imagine a syntax for embedding a data form in an <error/> but this is not what XEP-0077 describes. Has anyone implemented this part of XEP-0077 in practise? If I return the error with this form will anyone respect it? Do we need to care that this is not RFC compliant or can we squint and say that it's a sort-of echo of the request but with more fields to fill out...

2 1

Unmoderation/soft moderation
by Matthew Wild 17 Apr '26

17 Apr '26

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

5 5

Proposed XMPP Extension: Occupant Mute Synchronization
by Daniel Gultsch 08 Apr '26

08 Apr '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Occupant Mute Synchronization Abstract: Allows synchronizing a list of muted group chat participants between multiple clients. URL: https://xmpp.org/extensions/inbox/xep-occupant-mute-sync.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

5 8

TLS Encrypted Client Hello (ECH) for XMPP
by Wiktor Kwapisiewicz 08 Apr '26

08 Apr '26

Hi, I'd like to check if anyone explored the idea of implementing ECH [0] for XMPP? The rationale would be to hide the last bits that are sent plaintext when connecting: hostname (SNI) and protocols (ALPN). I'm aware that this is not simple, would require close collaboration of client and server developers and there's a large potential for bikeshedding (e.g. whether to use SVBC records [1] or Host Meta 2 [2]) but the only resource I found on this topic [3] ended without a clear conclusion. From the practical point of view it seems that ECH will be available soon in OpenSSL and some web servers already implement that [4] [5]. Thanks for your time! Kind regards, Wiktor [0]: https://www.rfc-editor.org/rfc/rfc9849.html [1]: https://www.rfc-editor.org/rfc/rfc9460 [2]: https://xmpp.org/extensions/xep-0487.html [3]: https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/6WSGNTADZ… [4]: https://github.com/nginx/nginx/pull/840 [5]: https://github.com/haproxy/haproxy/issues/1924

2 2

Proposed XMPP Extension: Group Chat Reporting
by Daniel Gultsch 07 Apr '26

07 Apr '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Group Chat Reporting Abstract: This specification describes how a client can report abuse and spam in a MUC or other group chat context. URL: https://xmpp.org/extensions/inbox/xep-gc-reporting.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 2

XMPP Council Agenda 2026-04-07
by Daniel Gultsch 06 Apr '26

06 Apr '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, April 7 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 * Proposed XMPP Extension: Message Archive Management: Trim Command * Proposed XMPP Extension: Group Chat Reporting * Proposed XMPP Extension: Occupant Mute Synchronization * UPDATED: XEP-0384 (OMEMO Encryption) * UPDATED: XEP-0413 (Order-By) * UPDATED: XEP-0509 (Initial Authentication Pipelining) 4) Items for voting a) Proposed XMPP Extension: Message Archive Management: Trim Command https://xmpp.org/extensions/inbox/xep-mam-trimming.html b) Proposed XMPP Extension: Group Chat Reporting https://xmpp.org/extensions/inbox/xep-gc-reporting.html c) Proposed XMPP Extension: Occupant Mute Synchronization https://xmpp.org/extensions/inbox/xep-occupant-mute-sync.html 5) Pending votes Daniel on XEP-0045: Add clarification regarding unsetting reserved nicknames 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-0509 (Initial Authentication Pipelining)
by Daniel Gultsch 06 Apr '26

06 Apr '26

Version 0.2.0 of XEP-0509 (Initial Authentication Pipelining) has been released. Abstract: This specification defines a protocol for discovering if the SASL2 <authenticate> can be pipelined safely along with the stream open, and if so allows the client to perform this pipelining safely. Changelog: Updates based on implementation (dwd) URL: https://xmpp.org/extensions/xep-0509.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-0413 (Order-By)
by Daniel Gultsch 06 Apr '26

06 Apr '26

Version 0.2.1 of XEP-0413 (Order-By) has been released. Abstract: This specification allows to change order of items retrieval in a Pubsub or MAM query Changelog: Replace old namespace use in examples. (jp) URL: https://xmpp.org/extensions/xep-0413.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-0384 (OMEMO Encryption)
by Daniel Gultsch 06 Apr '26

06 Apr '26

Version 0.9.1 of XEP-0384 (OMEMO Encryption) has been released. Abstract: This specification defines a protocol for end-to-end encryption in one-to-one chats, as well as group chats where each participant may have multiple clients per account. Changelog: Fix using id=0 in examples. Spec requires positive numbers. (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0384.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

Resolve uncertainty about File Sharing Standards
by Philipp Hörist 04 Apr '26

04 Apr '26

Dear Council Members, For years now we have two competing standards https://xmpp.org/extensions/xep-0447.html and https://xmpp.org/extensions/xep-0385.html and it leads to confusion and additional work for new implementers and prevents in some cases implementations at all. According to the xmpp.org page both XEPs have each 6 implementations. I would suggest to issue a last call to gather feedback. After all feedback is addressed council should advances only one. Regards Philipp

4 4