Good Morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, March 31
2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join
Notice the time zone change. For some people this might now be an hour
later than usual.
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
• LAST CALL: XEP-0377 (Blocking Command Reports)
• UPDATED: XEP-0461 (Message Replies)
• UPDATED: XEP-0493 (OAuth Client Login)
The two updated XEPs are just minor editorial changes.
4) Items for voting
a) XEP-0045: Add clarification regarding unsetting reserved nicknames
https://github.com/xsf/xeps/pull/1512
5) Pending votes
Marvin, Stephan Paul, Dan, Jerome on XEP-xxxx: Explicit Mentions
(https://xmpp.org/extensions/inbox/explicit-mentions.html)
See the spreadsheet of doom:
https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh…
6) Date of Next
7) AOB
8) Close
Version 0.1.1 of XEP-0493 (OAuth Client Login) has been released.
Abstract:
This specification details how a third-party can be securely granted
access to an XMPP account without exposing the account credentials,
using OAuth.
Changelog:
* Fix reference to RFC 7628 for SASL OAUTHBEARER (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0493.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.
Version 0.2.1 of XEP-0461 (Message Replies) has been released.
Abstract:
This document defines a way to indicate that a message is a reply to a
previous message.
Changelog:
Update the example to use the correct fallback namespace. (mye)
URL: https://xmpp.org/extensions/xep-0461.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.
This message constitutes notice of a Last Call for comments on
XEP-0377.
Title: Blocking Command Reports
Abstract:
This document specifies a mechanism by which reporting information can
be attached to a Blocking Command (XEP-0191) request. It enables
servers to process reports related to blocked entities while remaining
focused on this specific workflow rather than general abuse reporting.
URL: https://xmpp.org/extensions/xep-0377.html
This Last Call begins today and shall end at the close of business on
2026-04-14.
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!
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
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
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
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.
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.
