- Standards

TLS Encrypted Client Hello (ECH) for XMPP

by Wiktor Kwapisiewicz

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

5 hours, 13 minutes

2
1
0 0

QUIC(ker)

by Dave Cridland

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.

5 hours, 18 minutes

5
13
0 0

Resolve uncertainty about File Sharing Standards

by Philipp Hörist

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

18 hours, 56 minutes

4
4
0 0

Proposed XMPP Extension: Explicit Mentions

by Daniel Gultsch

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.

3 days, 15 hours

11
65
0 0

Scoping discussion: updating XMPP RFCs / XMPP 2.0

by Guus der Kinderen

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

3 days, 20 hours

7
8
0 0

Proposed XMPP Extension: Occupant Mute Synchronization

by Daniel Gultsch

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.

4 days

2
1
0 0

Proposed XMPP Extension: Group Chat Reporting

by Daniel Gultsch

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.

4 days

2
1
0 0

Unmoderation/soft moderation

by Matthew Wild

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

4 days, 3 hours

4
4
0 0

Proposed XMPP Extension: Message Archive Management: Trim Command

by Daniel Gultsch

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.

4 days, 10 hours

1
0
0 0

NEW: XEP-0513 (Explicit Mentions)

by Daniel Gultsch

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.

4 days, 10 hours

1
0
0 0

2026

2025

2024

2023

Standards