February 2026 - Standards

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

2 days, 5 hours

7
8
0 0

LAST CALL: XEP-0377 (Spam Reporting)

by Daniel Gultsch

This message constitutes notice of a Last Call for comments on XEP-0377. Title: Spam Reporting Abstract: This document specifies a mechanism by which users can report spam and other abuse to a server operator or other spam service. URL: https://xmpp.org/extensions/xep-0377.html This Last Call begins today and shall end at the close of business on 2026-01-05. 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!

1 month, 1 week

7
16
0 0

NEW: XEP-0511 (Link Metadata)

by Daniel Gultsch

Version 0.1.0 of XEP-0511 (Link Metadata) has been released. Abstract: This specification describes how to attach metadata for links to a message. Changelog: Accepted as Experimental by council vote (dg) URL: https://xmpp.org/extensions/xep-0511.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 month, 1 week

2
1
0 0

Proposed XMPP Extension: Link Metadata

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Link Metadata Abstract: This specification describes how to attach metadata for links to a message. URL: https://xmpp.org/extensions/inbox/link-metadata.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 month, 1 week

5
5
0 0

XMPP Council Agenda 2026-02-24

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, February 24 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 • UPDATED: XEP-0353 (Jingle Message Initiation) https://xmpp.org/extensions/xep-0353.html • NEW: XEP-0510 (End-to-End Encrypted Contacts Metadata) https://xmpp.org/extensions/xep-0510.html 4) Items for voting none 5) Pending votes Goffi on Link Metadata https://xmpp.org/extensions/inbox/link-metadata.html See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh… 6) Date of Next 7) AOB 8) Close

1 month, 1 week

1
0
0 0

NEW: XEP-0510 (End-to-End Encrypted Contacts Metadata)

by Daniel Gultsch

Version 0.1.0 of XEP-0510 (End-to-End Encrypted Contacts Metadata) has been released. Abstract: This specification describes how to encrypt contacts metadata to minimize server exposure. Changelog: Accepted as Experimental by council vote (dg) URL: https://xmpp.org/extensions/xep-0510.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 month, 1 week

1
0
0 0

UPDATED: XEP-0353 (Jingle Message Initiation)

by Daniel Gultsch

Version 0.8.0 of XEP-0353 (Jingle Message Initiation) has been released. Abstract: This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource. Changelog: Adapt usage of JID types to real-world usage: * Send JMI responses to full JID of initiator instead of bare JID * Send JMI <finish/> element to full JID of both parties (melvo) URL: https://xmpp.org/extensions/xep-0353.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 month, 1 week

1
0
0 0

Occupant colours

by Dave Cridland

I quite like XEP-0392. I didn't honestly think I would when it first proposed and published, but it's really handy. But, XEP-0392 doesn't - anywhere - specify what the "input" should be. I can see some options: 1) Pick the relevant jid. I'm currently using the bare jid for 1:1 conversations, and the XEP-0045 occupant jid (including nickname) for MUCs. That seems the most obvious, but means nickname changes also change colour. 2) Pick the display name. I could use the name for 1:1 (the one I display, from Roster etc) and the nickname from a MUC. That has the advantage that where those are the same, the colour will be consistent - "Zash" will be coloured the same on all MUCs, for example. 3) Pick the most stable identifier I can. So occupant_id in MUC, though still bare Jid for 1:1. This would mean the bright pink occupant would remain bright pink no matter what nickname change they tried. No escape! Any suggestions? Or doesn't it matter? Dave.

1 month, 1 week

2
1
0 0

Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: End-to-End Encrypted Contacts Metadata Abstract: This specification describes how to encrypt contacts metadata to minimize server exposure. URL: https://xmpp.org/extensions/inbox/contacts-e2e.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 month, 1 week

10
25
0 0

Write-only PubSub node (XEP-0060)

by Schimon Jehudah

Greetings. I am interested to know, whether there is a possibility to create a write-only node. For instance, a node which be written by anyone, and read by selected people, be useful to moderation of contents. Pending urn:xmpp:microblog-await:0 Moderators: read and write Public: write Denied urn:xmpp:microblog-denied:0 Moderators: read and write Public: none Approved urn:xmpp:microblog:0 Moderators: read and write Public: read P.S. The node names are not standard node names. These are node names for the purpose of realization. Kind regards, Schimon

1 month, 2 weeks

1
0
0 0

2026

2025

2024

2023

Standards February 2026