The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Payment Required
Abstract:
This specification defines an XMPP protocol extension that enables
services to require payment before granting access to a resource. It
provides a payment-system neutral invoice format supporting multiple
concurrent payment options, including bank transfers (SEPA, IBAN, UPI)
and instant-settlement networks (Lightning Network), and integrates
with the existing CAPTCHA challenge mechanism defined in XEP-0158.
URL: https://xmpp.org/extensions/inbox/payment-required.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
I have setup the XSF membership application Wiki page for the
application period Q3-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_Q3_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
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
