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.
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.
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
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!
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.
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.
