- Standards

How will MEP / XEP-0316 handle unstable fullJIDs?
by Greatsword 19 Jun '26

19 Jun '26

Just had a read of XEP-0316: MUC Eventing Protocol, and it seems interesting and useful, but I'm wondering what happens to the MEP nodes owned by a particular occupant. The XEP states... > An occupant does so by sending a publish-subscribe publish request to the occupant's Occupant JID <room@service/nick> (similar to the way in which publishing via PEP happens by sending a request to the user's bare JID <user@host>). For instance, the following example shows how a room occupant would inform the other occupants about an event of interest. which would mean that interested parties would be subscribing to room@service/nick for their MEP nodes, but this could change from the user leaving or changing their nick. Is it just meant to be a sort of temporary live thing where you can ad-hoc send these events and then they just go away when you leave? or could this be attached to something more stable, like Occupant-ID. Thanks all! -- - greatsword

1 1

How will MEP / XEP-0316 handle unstable fullJIDs?
by Greatsword 19 Jun '26

19 Jun '26

Just had a read of XEP-0316: MUC Eventing Protocol, and it seems interesting and useful, but I'm wondering what happens to the MEP nodes owned by a particular occupant. The XEP states... > An occupant does so by sending a publish-subscribe publish request to the occupant's Occupant JID <room@service/nick> (similar to the way in which publishing via PEP happens by sending a request to the user's bare JID <user@host>). For instance, the following example shows how a room occupant would inform the other occupants about an event of interest. which would mean that interested parties would be subscribing to room@service/nick for their MEP nodes, but this could change from the user leaving or changing their nick. Is it just meant to be a sort of temporary live thing where you can ad-hoc send these events and then they just go away when you leave? or could this be attached to something more stable, like Occupant-ID. Thanks all! -- - greatsword

1 0

XMPP Spaces URIs
by Timothée Jaussoin 16 Jun '26

16 Jun '26

Hi! XMPP Spaces are now described in https://xmpp.org/extensions/xep-0503.html . A XMPP Space is a Pubsub node that contains bookmarks pointing to MUCs. We would like to have a proper Space URI that allow users to invite easily others to their Spaces. This will be added as a section to XEP 0503. So far a Pubsub node is described in https://xmpp.org/extensions/xep-0060.html#impl-uri I'd like to have something short and transparent so I'm proposing something like this: Proposal 1: xmpp:spaces.server.tld?;node=x56ae32&space I'm wondering if something shorter like this is possible ? (where the client is resolving the "space" parameter as the Pubsub node) Proposal 2: xmpp:spaces.server.tld?;space=x56ae32 The goals are * to prevent non "space-ready" XMPP clients to open it as a Pubsub node by mistake * have something short and easily shareable (Discord is having something like this https://discord.gg/AP5HFj7w) If one of the proposals is okay for you I'll propose a PR on 0503 and make the changes in Movim (I'm sure nicoco will be able to do it in Slidge, the other 0503 implementation). Because this is having effect on the XMPP uris format I'm wondering if there's some kind of rules or specific requests to follow ? Regards, edhelas

3 5

Proposed XMPP Extension: XMPP Decentralized ID (XID)
by Daniel Gultsch 16 Jun '26

16 Jun '26

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.

10 21

Proposed XMPP Extension: Payment Required
by Daniel Gultsch 15 Jun '26

15 Jun '26

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.

8 11

XSF membership application period Q3 2026
by Alexander Gnauck 15 Jun '26

15 Jun '26

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

1 0

Proposed XMPP Extension: Jingle Synchronized Real-Time Text
by Daniel Gultsch 15 Jun '26

15 Jun '26

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.

5 8

XMPP Council Agenda 2026-06-02
by Daniel Gultsch 02 Jun '26

02 Jun '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, June 2 2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update • UPDATED: XEP-0045 (Multi-User Chat) https://xmpp.org/extensions/xep-0045.html • NEW: XEP-0514 (Emoji Markup) https://xmpp.org/extensions/xep-0514.html • Proposed XMPP Extension: Jingle Synchronized Real-Time Text https://xmpp.org/extensions/inbox/jingle-rtt-sync.html • Proposed XMPP Extension: XMPP Decentralized ID (XID) https://xmpp.org/extensions/inbox/xid.html • Proposed XMPP Extension: Jingle User Location https://xmpp.org/extensions/inbox/jingle-geoloc.html 4) Items for voting a) Proposed XMPP Extension: Jingle Synchronized Real-Time Text https://xmpp.org/extensions/inbox/jingle-rtt-sync.html b) Proposed XMPP Extension: XMPP Decentralized ID (XID) https://xmpp.org/extensions/inbox/xid.html c) Proposed XMPP Extension: Jingle User Locationhttps://xmpp.org/extensions/inbox/jingle-geoloc.html 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh… 6) Date of Next 7) AOB 8) Close

1 0

Proposed XMPP Extension: Jingle User Location
by Daniel Gultsch 02 Jun '26

02 Jun '26

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.

3 2

NEW: XEP-0514 (Emoji Markup)
by Daniel Gultsch 02 Jun '26

02 Jun '26

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.

1 0