May 2026 - Standards

by Dave Cridland

Hi all, I'm trying to summarise a discussion in the council@ chatroom, and - like an LLM - I am not perfect so may misrepresent or misunderstand some views. Errors, therefore, I shall claim as my own; views however are not. First, some history. In the early days of XEP-0045, each occupant corresponded to precisely one full jid (ie, a client session). All stanzas sent to the occupant jid were, therefore, forwarded through directly to that full jid. This general model of "pure forwarding" has been maintained throughout XEP-0045's history, but it has been modified heavily. Quite early on - Kev thought 2001, MattJ thought 2003 - the need to have vCards in particular be different started changing rules, and when Prosody started doing MUC (and also M-Link) they started intercepting vCard to the MUC occupant jid and forwarding that to the user's bare jid. Prosody now does this with PEP as well. In addition, "nick sharing" - allowing multiple full jids of the same user behind a single occupant jid - makes forwarding most IQ stanzas complicated. All this causes existing problems with preserving privacy in semi-anonymous rooms. What we do in the future (under MUC2/GC3/IRC4 whatever) broadly falls into 3 options that were discussed. Option 1: The occupant jid forwards nothing, but has a way of requesting a contact jid. Option 2: The occupant jid forwards everything to the user's bare jid, and their server "deals" with it. Option 3: The occupant jid responds itself, without forwarding, and data (vCards, PEP, etc) need to be uploaded by the user and stored by the MUC. Option 4: The occupant jid has rules set by the user, which cause it to either forward or reject particular traffic. I imagine some of these rules will cause PEP subscriptions and event forwarding/fanout, potentially. There were proponents of each of these approaches (and some proponents of multiple). There's a further discussion in xsf@ that I've not yet properly read. My opinions follow: Of these options, I think I'd like Option 4, but will settle for Option 2. Option 2 feels like the natural fallback for Option 4 anyway. One outcome is that in Future-MUC, there's an implication that Private Messages, PEP, and vCard will go to the *bare* Jid, and that unless we do something "clever", so will Jingle calls to Occupants. We would then control these with existing (or new) access control on our own server, or Option 4's new rules, or some combination of both. I appreciate the simplicity of Option 1, but I think it's too simple - even for Private Messages I'd need to reveal my identity. If I'm in a sensitive room (say a healthcare related one) I might really want (or need) PMs but not be willing to reveal my identity. Option 3 seems very heavyweight and expensive to maintain and manage. I don't particularly want to upload an avatar (and more) to each MUC room, and nor do I see how those will work with (for example) Jingle. As noted, I may have misconstrued the options presented! Dave.

2 months, 2 weeks

4
3
0 0

XMPP Council Agenda 2026-05-05

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, May 5 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: Payment Required (https://xmpp.org/extensions/inbox/payment-required.html) * Proposed XMPP Extension: Emoji Markup (https://xmpp.org/extensions/inbox/emoji-markup.html) * Proposed XMPP Extension: New MUC (https://xmpp.org/extensions/inbox/new-muc.html) * UPDATED: XEP-0449 (Stickers) * UPDATED: XEP-0463 (MUC Affiliations Versioning) * UPDATED: XEP-0503 (Server-side spaces) * Proposed XMPP Extension: TLS Channel-Binding Downgrade Protection (https://xmpp.org/extensions/inbox/tdp.html) 4) Items for voting a) Proposed XMPP Extension: Payment Required https://xmpp.org/extensions/inbox/payment-required.html b) Proposed XMPP Extension: Emoji Markup https://xmpp.org/extensions/inbox/emoji-markup.html c) Proposed XMPP Extension: New MUC https://xmpp.org/extensions/inbox/new-muc.html d) Proposed XMPP Extension: TLS Channel-Binding Downgrade Protection https://xmpp.org/extensions/inbox/tdp.html e) XEP-0045: Fix examples for messages from the room itself https://github.com/xsf/xeps/pull/1537 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh… 6) Date of Next 7) AOB 8) Close

2 months, 2 weeks

1
0
0 0

Proposed XMPP Extension: TLS Channel-Binding Downgrade Protection

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: TLS Channel-Binding Downgrade Protection Abstract: This specification provides a way to secure the SASL and SASL2 SCRAM handshakes against channel-binding downgrades through TLS version downgrades. URL: https://xmpp.org/extensions/inbox/tdp.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

2 months, 2 weeks

1
0
0 0

UPDATED: XEP-0503 (Server-side spaces)

by Daniel Gultsch

Version 0.3.0 of XEP-0503 (Server-side spaces) has been released. Abstract: This document defines an XMPP protocol to cluster several groupchat rooms together. Changelog: * Fix pubsub node field name in room disco info. * Specify how to attach images (avatar and banner) to a space. (nc) URL: https://xmpp.org/extensions/xep-0503.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.

2 months, 2 weeks

1
0
0 0

UPDATED: XEP-0463 (MUC Affiliations Versioning)

by Daniel Gultsch

Version 0.2.0 of XEP-0463 (MUC Affiliations Versioning) has been released. Abstract: This specification provides a way to reduce the amount of queries necessary to stay up-to-date with affiliations in a MUC room. Changelog: Use a dedicated child element of <x/> rather than namespaced attributes. (lmw) URL: https://xmpp.org/extensions/xep-0463.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.

2 months, 2 weeks

1
0
0 0

UPDATED: XEP-0449 (Stickers)

by Daniel Gultsch

Version 0.2.0 of XEP-0449 (Stickers) has been released. Abstract: This specification provides a protocol to send stickers and to create and share sticker packs. Changelog: Make pack attribute explicitly a MAY. Add more details about sending/receiving stickers without a sticker pack. (lmw) URL: https://xmpp.org/extensions/xep-0449.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.

2 months, 2 weeks

1
0
0 0

2026

2025

2024

2023

Standards May 2026