The XMPP Extensions Editor has received a proposal for a new XEP.
Title: XMPP Decentralized ID (XID)
Abstract:
XMPP Decentralized ID (XID) is a DNS independent XMPP entity
identifier. This specification describes how to generate, use, and
handle them.
URL: https://xmpp.org/extensions/inbox/xid.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Jingle Synchronized Real-Time Text
Abstract:
This specification defines a Jingle application extension for
negotiating real-time text as part of the same conversational session
as audio and video.
URL: https://xmpp.org/extensions/inbox/jingle-rtt-sync.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Jingle User Location
Abstract:
This specification defines a Jingle application extension for
negotiating and updating user location inside an active Jingle session
using the XEP-0080 User Location payload.
URL: https://xmpp.org/extensions/inbox/jingle-geoloc.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 0.1.0 of XEP-0514 (Emoji Markup) has been released.
Abstract:
This specification leverages Message Markup (XEP-0394) and Stateless
file sharing (XEP-0447) (or Stateless Inline Media Sharing (XEP-0385))
to send custom emojis
Changelog:
Accepted as Experimental by council vote on 2026-05-12 (XEP Editor
(dg))
URL: https://xmpp.org/extensions/xep-0514.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 1.35.5 of XEP-0045 (Multi-User Chat) has been released.
Abstract:
This specification defines an XMPP protocol extension for multi-user
text chat, whereby multiple XMPP users can exchange messages in the
context of a room or channel, similar to Internet Relay Chat (IRC). In
addition to standard chatroom features such as room topics and
invitations, the protocol defines a strong room control model,
including the ability to kick and ban users, to name room moderators
and administrators, to require membership or passwords in order to
join the room, etc.
Changelog:
* Fix 'from' attribute in examples where the room itself sends a
message.
* Fix associated pubsub node field name in disco info example. (nc)
URL: https://xmpp.org/extensions/xep-0045.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.
Hello Council and XEP Editors,
I would like to request reactivation of XEP-0346: Form Discovery and
Publishing.
The XEP is currently Deferred due to lack of activity. We are building
an alpha/prototype XMPP client, Tiedragon Teletyptel 2.0, and during
implementation of poll support we found that XEP-0346 is highly relevant
as a general mechanism for discovering and publishing forms.
Our current implementation is not production-ready, but we have running
code and a concrete use case:
- user-facing polls in 1:1 and MUC conversations
- form templates based on XEP-0004
- possible publication/discovery through PubSub
- accessibility and total-conversation workflows where structured forms
are useful beyond polls
We do not want to depend on a Deferred XEP as if it were stable.
Instead, we would like to help revive discussion and provide
implementation feedback from an alpha implementation.
The initial use case is poll creation and voting, but the broader need
is reusable form discovery/publishing for XMPP applications.
Would the Council / Editors be open to moving XEP-0346 back to
Experimental if we submit a substantive update or implementation notes?
If useful, I can prepare a pull request with:
- updated motivation and modern use cases
- security/privacy considerations
- relationship to XEP-0004 and XEP-0060
- implementation experience from Teletyptel 2.0
- clarification of poll-style usage without making polls the only use case
Kind regards,
Edward Tie
Tiedragon
Hello,
I have submitted two related Jingle ProtoXEPs:
1. Jingle T.140 / RTT
2. Jingle Location
Could someone from the XEP Editors / Council, or someone with Jingle
experience, help process and review these submissions?
Both ProtoXEPs are based on implementation work in Teletyptel 2.0 alpha.
The software is not production-ready yet, but we have running code and
practical test results. The goal is to explore accessible total
conversation over XMPP with audio, video, real-time text and optional
location sharing.
The main review areas are:
- correct Jingle session design
- whether the proposed features should be separate Jingle contents or
session metadata
- compatibility with existing Jingle/WebRTC clients
- relationship to T.140, RFC 4103 and XEP-0080
- fallback behavior when the peer does not support the feature
- security and privacy considerations
- whether the split into two ProtoXEPs is correct
I would appreciate help moving these submissions through the correct
XMPP Standards Foundation process.
Kind regards,
Edward Tie
Tiedragon
Apologies, I sent this to the members mailing list however some
developers are not members.
Please vote on the dates which work best for you. It will be a 3 day
sprint. Venue is currently not decided, but will be somewhere in London
:)
Begin forwarded message:
Date: Sun, 17 May 2026 16:15:06 +0100
From: Polarian via Members <members(a)xmpp.org>
To: members(a)xmpp.org
Cc: Polarian <polarian(a)polarian.dev>
Subject: [Members] [Vote] London XMPP Sprint 2026
Good afternoon,
After discussions with Matthew yesterday, we have decided that the
sprint should be held on one of the following ranges of dates.
* Fri 25th Sep to Sun 27th Sep
* Fri 2nd Oct to Sun 4th Oct
* Fri 9th Oct to Sun 11th Oct
* Fri 16th Oct to Sun 18th Oct
* Fri 23th Oct to Sun 25th Oct
* Fri 30th Oct to Sun 1st Nov
* Fri 6th Nov to Sun 8th Nov
* Fri 13th Nov to Sun 15th Nov
* Fri 20th Nov to Sun 22nd Nov
* Fri 27th Nov to Sun 29th Nov
To vote, please copy the above list, and reply WITHIN THE THREAD to me
either privately (if you don't want it public) or onlist and put one of
the following symbols next to every range:
+ (Available)
x (Unavailable)
- (Could be available)
For those who are not able to post to the list, please send me an email
(polarian(a)polarian.dev) and I will include your vote, please only vote
if you are interested in attending.
I will count the responses and pass them onto Matthew on Sunday 24th
May (1 week from now).
Note: Matthew is *NOT* MattJ aka Matthew Wild, we really need to
find a solution to the duplicate Matthews.
Happy voting!
Take care,
--
Polarian
Jabber/XMPP: polarian(a)icebound.dev
--
Polarian
Jabber/XMPP: polarian(a)icebound.dev
Hi all,
Apologies for this being long.
Recent conversations have left me with two distinct impressions:
1) Some people within the XSF have a very different idea of what our
process is than I do, that in my view does not match what we have
documented.
2) A significant number of those that do share my understanding of the
process (and presumably all of those that don't) wish it were different.
Frankly, whether I agree with the second group is broadly immaterial - if
the consensus is that our process isn't currently what we want it to be, we
should change it to something that does have consensus. This message is to
try to come up with a set of proposals which can gain consensus, while not
totally rewriting the process.
As I've noted several times before, I hugely dislike process, and
documenting it, but I hate having a documented process that doesn't match
what we do (or want to do) even more. I cannot begin to describe how hugely
frustrating it is to enter the process in good faith only to discover
that's not the process people will enforce. And I'm an old hand, for
newcomers it must be even worse. So it's probably time to wade into
XEP-0001 once again. I do not have any special rights over XEP-0001, I'm
not on the Board or Council, and while I'm an XSF Member that gives no
authority over anyone else in the Standards SIG (ie, this list, basically).
So anything I say or suggest herein should not be considered final or
preferential in any way - you're all welcome (and encouraged) to debate it.
So, with that out of the way, here's what I think the rough consensus of
our red lines should be (noting I'm not using RFC 2119 language here!):
Point A - All specification development should be as open and accessible as
possible, operate within a well-documented process, and unequivocally
within our IPR policy.
Point B - As an organisation, progression along the lifecycle of XEPs
should give clear and unambigious signals as to the maturity of the
document.
Point C - We don't want to dilute Experimental XEPs with "slop", for want
of a better word.
My impression from people is that there is a concern that because
Experimental is very broad in terms of maturity levels it fails on Point B
above.
Experimental was, I believe, designed to be the rough equivalent to
Internet-Drafts in the IETF, which have absolutely no standing, although
the XSF "adopts" them as an IETF Working Group does. Over the years, we've
introduced technical (and social) changes that mean that specifications in
Experimental have become safer to implement and deploy.
Proposed currently is a short-lived state that we often ignore - it's from
Last Call up to Stable. This shouldn't last more than a couple of weeks,
normally. There's no documented quality gate for entering it, though there
is a Council vote - then a Last Call, then another Council vote.
As such the signal prior to Stable is very fuzzy, so to tighten it up there
are a few options.
First, we could "left shift" - and I think this is what's been happening.
By applying the requirements of Stable (and in some cases, Final) to
Experimental, we push things off the beginning of the XSF's process. That,
I feel very strongly, is wrong, since it violates Point A on all counts,
and in any case leaves no benefit or point to Stable or Final.
Second, we could try and refine Experimental. My proposal here - because I
do have a concrete proposal - is to attempt to address Point B by making
Experimental better defined, and expanding Proposed.
Proposal 1 : For Experimental, I propose that XEP-0001 makes it clear that
such documents are "works in progress" - it does this already - but also
that they may contain errors and ommissions, and may prove unimplementable.
This is not, in fact, a change from our current process.
Proposal 2 : For Proposed, I suggest we expand this with the quality gate
that we expect specifications be implementable, have strong interest from
the relevant subsection of the community in implementing, and consensus
that they address a problem. Specifications would then enter this as the
"final straight" to Stable, have *multiple* Last Calls (I know) and then
once the Author is satisfied a Council vote to advance to Stable (or
Rejected, or leave it where it is in Proposed). I suggest also introducing
a timer that after six months, if not advanced to Stable, they drop back to
Experimental. In summary, then, Proposed becomes a strong candidate for
Stable.
I think this addresses Point B without damage to Point A - that is,
Experimental XEPs are more formally "the wild west", and Proposed is "We're
pretty sure this works and you should try it". I also think it raises the
bar for Stable, which is either a good thing, or a high risk that means we
don't have a use for Final. We might wish to note Stable is intended for
widespread deployment, rather than mere implementation, and that it's
feedback from this widespread deployment that might yet cause changes. I
think these are wording changes to match reality, though.
I anticipate that some specifications - mostly those that Council are
currently accepting - will spend little time in Experimental, and rapidly
move to Proposed. That seems like a good thing. Others will spend a lot of
time in Experimental, developing.
To address Point C, I noticed that in "the old days", we used to require 5%
of membership to trigger Council votes, and while I don't wish to "bind"
Council, this got me thinking down a line of increasing the signals
available to Council. While I'm not worried, personally, about Point C, I
do appreciate that others are, and I also note that "AI slop" in particular
is a growing problem.
Proposal 3 : I propose we introduce a new Call to the SIG (ie, Editor
questionnaire sent to the list), which asks for Expressions Of Interest for
submitted ProtoXEPs. This should give Council guidance on what documents
the community actually wants to work on. XEP-0001 should provide guidance
that Council should reject submissions without sufficient interest, and is
ordinarily expected to follow the consensus of the SIG. (Which SIG is an
interesting question; we normally only have one).
I think in the past, and still now on occasion, we've treated the ProtoXEP
announcements this way anyway. But formalizing this (and formalizing the
idea we're looking for Expressions Of Interest) seems like a good way to
gate slop nobody cares about. Presumably if people do care, it is by
definition not slop?
Proposal 4 : Further, I think it'd be useful to introduce additional
guidance as to what is expected of a ProtoXEP submission. First, a new
mandatory section of the Problem Statement, such that Council and the SIG a
better idea of what the author is hoping to solve, and second, that the
ProtoXEP should give a clear idea as to the general approach.
This is aimed at explicitly allowing XEPs which are not fully formed, while
still providing the kind of information that will let people (SIG and
Council) avoid letting in entirely vague slop.
Note that neither Proposals 3 or 4 place any limit on Council's veto, nor
any recourse/appeal, though it does shift to providing some guidance and
expectation. Ultimately, XSF Members just need to vote in sensible, trusted
people who follow the process.
Related to Proposal 3, there's also:
Proposal 5 : Finally I propose we document the Call questionnaires that the
Editor sends. This do form part of our process, and a significant part at
that. I propose these are documented together in a new XEP, so that they're
a little easier to change. Technically these would be Procedural and thus
Board approved, but we have historically placed the mechanics of how
XEP-0001 is implemented under Council control (see XEP-0143) and I'm
inclined to continue that if Board agrees.
I'm happy to commit to the time/effort to write these up (though Proposal 5
might be better done by the Editor), but I'd like to gauge interest from
the community first, and adjust the proposals as needed to get the best
consensus.
Once again, apologies for the length, and thanks for reading this far. I
owe you a drink, or something.
As a final note, I don't think my MUC ProtoXEP would get published under
these proposals - but I think I'd have a clearer idea on why - and how to
fix it.
Dave.
