March 2026 - Standards

Problems with latest XEP-0377 updates
by Matthew Wild 30 Mar '26

30 Mar '26

Hi, Today I read through the latest revisions of XEP-0377, and a number of things stood out. I've broken this email into a section per issue. Namespace versioning -------------------------- Version 0.4.0 of XEP-0377 contains schema changes without changing the namespace. This contravenes XEP-0053, which states: "While the XEP is in the Experimental state, if appropriate and in consultation with the author(s), the XMPP Registrar shall update the namespace version number at the end of namespace (e.g., from "0" to "1"); the XMPP Registrar shall do so only if the protocol defined in the XEP has been modified in a way that is not backwards-compatible with an earlier version of the protocol." Generally, adding previously undefined elements is considered to be a breaking change that requires a new namespace, especially in a protocol that is already deployed. Possible remedies: Given that the current namespace is already implemented and deployed, I would have preferred to see this XEP advanced than modified. However, if there is consensus that we really need these new rules, they could be tacked on in a new namespace such as 'urn:xmpp:reporting:1#processing'. There is precedent for this approach in other XEPs, including XEP-0313. Failing that, we would have to update to 'urn:xmpp:reporting:2' and update all implementations (and this also is the only way to guarantee that implementations will honour the processing rules). Extensibility via elements ------------------------ The new version created a registry to allow new processing options to be defined. However it does this via elements. For the reasons above, this simply can't work - the schema would have to be updated every time a new processing rule is added. Especially once the XEP is advanced, schemas simply don't change like this. They get coded into implementations, and implementations would be free to reject unexpected elements. Instead, a valid approach would be to define the rules as strings (URIs are a common choice, but not strictly required) and have these passed as attribute values or character data. For example: <processing xmlns='urn:xmpp:reporting:1#processing'> <allow>origin</allow> <allow>third-party</allow> </processing> Thoughts on processing rules in general ----------------------- I get why the processing rules were added. However I really think they are approaching the problem backwards. As a service operator, receiving a report that says "here is a problem, but I forbid you from doing anything about it" is a rather silly situation. It would almost be better to not receive the report at all. For a long time, this was why multiple client developers said they weren't interested in even implementing reporting - because nothing useful actually happened on the server side, so the reports were at best logged and at worst discarded. A better approach is to have the server tell the client what will/may happen to reports that are submitted (and then give the user the choice of whether to submit or not). In most online services this disclosure happens in the Terms of Service and/or Privacy Policy. It is then up to the implementation and service operator to decide what (and how much) to share from reports, when to share them, and with whom. Per various worldwide laws, these things should often already be disclosed, regardless of the protocol layer in use. Renaming ------------ This is a more minor point, but I had planned to reuse the reporting payload in protocols other than XEP-0191: Blocking Command, and this reuse was definitely on the table at the summit where the protocol was initially discussed. I think the new title feels like it is discouraging such reuse, compared to the previous title and contents (where usage within XEP-0191 was provided as an initial location where reports should happen). I intend to submit protoXEPs based on this specification with or without any of the points in this email being addressed, I only thought I should provide the feedback as I saw the new changes and they surprised me. Regards, Matthew

5 8

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