- Standards

XSF membership application period Q2 2026
by Alexander Gnauck 16 Mar '26

16 Mar '26

I have setup the XSF membership application Wiki page for the application period Q2-2026 Applications are encouraged from developers and others who are actively involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki: https://wiki.xmpp.org/web/Membership_Applications_Q2_2026 If you don't have a wiki account, send your full name, preferred nickname and email address to me or one of the other Sysops: https://wiki.xmpp.org/web/Sysops When you need help with your application then don't hesitate to contact me directly Apply now!!! Thanks, Alex

1 0

Reinstating XHTML-IM (XEP-0071)
by Schimon Jehudah 16 Mar '26

16 Mar '26

Greetings. I am not an XSF member, yet I am interested to reinstate XHTML-IM. I have useful ideas that would be possible with XHTML-IM. Nevertheless, even without new ideas, I deem that XEP-0071 should be reinstated with added security concerns; Email software also handle (X)HTML, and so many other software, while implementing security measures; and Therefore, I deem that, XEP-0071 should be reinstated. Kind reagrds, Schimon

9 20

Feedback on XEP-0379, XEP-0401, XEP-0445
by Daniel Gultsch 16 Mar '26

16 Mar '26

Hi, I’m sorry to say but the "Easy Onboarding" stack is a bit of a mess and I believe it requires significant work before we can consider restarting the Last Call. Personally the most impactful feature of that stack has always been allowing registrations on servers that don’t have public (open) registrations. This solves a real need for "Family and Friends" style servers that really, really should not have open registration. I was never fully sold on the pre-authenticated roster part of the stack. I don’t know. I guess it’s kinda neat but I don’t really need a mutual presence subscription to get the first message out. The XEPs try to separate those two concerns (I guess partially due to me providing the same feedback a few years ago) but do a pretty bad job at it. 0445 is technically a separate XEP but without 0401 I have no (standardized) way retrieving those registration tokens. However 0401 doesn’t provide a guarantee that the server even supports 0445 and I have no way of knowing that before retrieving the invite URI. Only after retrieving the invite URI and checking for the existence of the ibr=y parameter I know that the server supports 0445. Currently, when I want to display a button in my client that reads. "Invite people to my server" I can’t because i have no discovery for that. Side note: The XEP is kinda sneaky in that it uses the same "preauth" parameter for 0379 and 0445. So even if I as a client developer are only really interested in the registration part; the delta work to also implement 0379 is extremely minimal. (Which I guess that’s fine and very much on purpose; but it speaks to the separation between those three XEPs not really existing). With an implementor hat but I guess also partially with my council hat I really need these 3 XEPs to go one of two ways: a) Give me a real way to use 0445 stand alone. Give me a standardized, discoverable way to request those IBR tokens from my server. b) Collapse those three XEPs back into one and make 0445 a required part of the stack. (Basically guarantee me that the URI that falls out of 0401 also allows me to register on the server of the person that invited me) P.S.: Completely separate of concerns above: We (both Prosody and ejabberd) do that have started to put a Link: <xmpp:…> header into the HTTP landing page. This allows a client to HEAD the HTTP endpoint when scanned from a QR code and then process the xmpp URI directly and internally without opening a website first. That way you can always put the HTTP uri into a QR code and when scanned it will always do the right thing regardless of whether it was scanned by the OS or by the XMPP app directly. I think this should go into the XEP.

3 5

UPDATED: XEP-0511 (Link Metadata)
by Daniel Gultsch 15 Mar '26

15 Mar '26

Version 0.1.1 of XEP-0511 (Link Metadata) has been released. Abstract: This specification describes how to attach metadata for links to a message. Changelog: Added security consideration. Added alt text to example. (spw) 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.

3 3

FORM_TYPEs for Data Forms
by stokito＠gmail.com 14 Mar '26

14 Mar '26

There is a page https://xmpp.org/registrar/formtypes.html It's Last Updated: 2009-04-06 so maybe it was outdated? It looks like it has all the FORM_TYPEs except of http://jabber.org/protocol/muc#request and http://jabber.org/protocol/muc#roominfo It also lacks of links to the mentioned XEPs. The ejabberd returns extra fields for the http://jabber.org/protocol/muc#roominfo: muc#roominfo_creationdate muc#roomconfig_allowinvites muc#roomconfig_changesubject muc#roomconfig_enablelogging muc#roomconfig_lang muc#roomconfig_maxusers muc#roomconfig_membersonly muc#roomconfig_moderatedroom muc#roomconfig_passwordprotectedroom muc#roomconfig_persistentroom muc#roomconfig_presencebroadcast All these fields are declared in the #roomconfig https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owner But they aren't declared for the #roominfo Could you add them?

1 0

UPDATED: XEP-0473 (OpenPGP for XMPP Pubsub)
by Daniel Gultsch 10 Mar '26

10 Mar '26

Version 0.1.1 of XEP-0473 (OpenPGP for XMPP Pubsub) has been released. Abstract: Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use case. Changelog: Fix inconsistency between text and example; it's the 'key' attribute that carries the shared secret ID (formerly it was 'secret'). (jp) URL: https://xmpp.org/extensions/xep-0473.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

Configuring a PubSub node
by Schimon Jehudah 01 Mar '26

01 Mar '26

Greetings. I am intending to connfigure an existing node, which is particulatly useful when intending to change routine (i.e. "default") configurations. Is it a necessary requirement to request a form; or, is it possible to configure a node at once, without requesting a form? https://xmpp.org/extensions/xep-0060.xml#owner-configure I thank you for any sort of help. Kind reagrds, Schimon

1 0

LAST CALL: XEP-0377 (Spam Reporting)
by Daniel Gultsch 25 Feb '26

25 Feb '26

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!

7 16

NEW: XEP-0511 (Link Metadata)
by Daniel Gultsch 25 Feb '26

25 Feb '26

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.

2 1

Proposed XMPP Extension: Link Metadata
by Daniel Gultsch 25 Feb '26

25 Feb '26

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.

5 5