- Standards

Proposed XMPP Extension: Portable Import/Export Format for XMPP Components
by Daniel Gultsch 25 Oct '26

25 Oct '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Portable Import/Export Format for XMPP Components Abstract: This document specifies a file format for importing and exporting component data to and from XMPP software URL: https://xmpp.org/extensions/inbox/pie-components.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 3

UPDATED: XEP-0425 (Moderated Message Retraction)
by Daniel Gultsch 24 Oct '26

24 Oct '26

Version 0.3.1 of XEP-0425 (Moderated Message Retraction) has been released. Abstract: This specification defines a method for groupchat moderators to retract messages of other users. Changelog: Clarify that the tombstone of a retracted XEP-0308 correction keeps its <replace/> element (jcb) URL: https://xmpp.org/extensions/xep-0425.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

UPDATED: XEP-0292 (vCard4 Over XMPP)
by Daniel Gultsch 24 Oct '26

24 Oct '26

Version 0.12.1 of XEP-0292 (vCard4 Over XMPP) has been released. Abstract: This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. Changelog: Fix examples for gender and pref vcard fields (ph) URL: https://xmpp.org/extensions/xep-0292.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

UPDATED: XEP-0070 (Verifying HTTP Requests via XMPP)
by Daniel Gultsch 24 Oct '26

24 Oct '26

Version 1.0.3 of XEP-0070 (Verifying HTTP Requests via XMPP) has been released. Abstract: This specification defines an XMPP protocol extension that enables verification of an HTTP request via XMPP. Changelog: Fix namespaces in examples (spw) URL: https://xmpp.org/extensions/xep-0070.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

[XEP-0171] Clarification on rate limiting
by huxiangkun2003＠gmail.com 24 Oct '26

24 Oct '26

While implementing and reviewing XEP-0171 (Language Translation), I noticed that the specification currently lacks an explicit standard error response for scenarios where the translation service is busy, overloaded, or rate-limiting requests (e.g., hitting quota limits or temporary server congestion). According to RFC 6120, the `<resource-constraint/>` defined-condition with error type `wait` indicates that the entity lacks the system resources (CPU, memory, quotas, etc.) necessary to service the stanza, which fits this use case perfectly: ``` <iq type='error' id='translationReq' from='translation.robot.com' to='ace(a)example.com'> <error type='wait'> <resource-constraint xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/> </error> </iq> ``` (Note: depending on implementation, an optional application-specific error element or human-readable <text/> could accompany it if needed). Explicitly documenting this would improve interoperability and guide client developers on how to implement retry logic or display appropriate feedback to users, rather than treating rate-limiting as a generic/permanent failure.

1 0

Regarding spam emails
by Christos Tsichrinis 22 Oct '26

22 Oct '26

Can we sincerely talk about setting up a spam filter or at the very least, requiring Gmail addresses to first be manually reviewed by a human before they can start a thread? These weekly spam floods are definitely not just a single instance, and this is getting more and more annoying for me (and others I can imagine). Kindly, Christos Tsichrinis (a.k.a. oakchris1955)

2 1

XMPP Council Agenda 2026-08-25
by Daniel Gultsch 20 Oct '26

20 Oct '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 25 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-0066 (Out of Band Data) https://xmpp.org/extensions/xep-0066.html • UPDATED: XEP-0515 (TLS Channel-Binding Downgrade Protection) https://xmpp.org/extensions/xep-0515.html • NEW: XEP-0518 (Payment Required) https://xmpp.org/extensions/xep-0518.html 4) Items for voting a) XEP-0143: Add author responsibility to submission process https://github.com/xsf/xeps/pull/1552 b) XEP-0490: Add security consideration for sender verification of PEP notifications https://github.com/xsf/xeps/pull/1554 c) XEP-0134: Add guideline against context-dependent elements https://github.com/xsf/xeps/pull/1558 d) XEP-0084: Fix example with both pubsub and HTTP source https://github.com/xsf/xeps/pull/1559 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

4 4

Comments on ProtoXEP: Jingle Audio/Video Conferences
by Dave Cridland 20 Oct '26

20 Oct '26

Hi Jérôme, standardizers, I saw that Jérôme had resubmitted av_conferences, and since this is an area of interest of mine, and one I sadly lack the detailed understanding to drive, I reviewed it with some interest. Firstly, this is, in my view, a major step forward and I would welcome it being published as a XEP. This is despite my suspicion that it will need more work. The main areas are around signalling for some of the cases that are hinted at. For example, bounded/demand forwarding, resolution selection, and so on. The biggest structural change - I think - is that the spec assumes that participants would get one or more SSRCs bound to them, and I suspect the "right" way to achieve a good result in the client is to bind SSRCs to UX elements; so a SSRC maps to "The 4th most recent speaker", or "This pinned particiant", for example - and the Focus then instructs the SFU to map an inbound stream to that SSRC accordingly. That implies that <origin/>, which maps to the <content-add/> set in Jingle, would need to be replaced with something that's part of the <description-info/> instead. Obviously this is all with the caveat that I have no idea what I'm talking about, really... But, I would really love to see interoperable multiparty calls in XMPP. Dave.

2 1

Spec proposal: bookmark last known name
by Nicolas Cedilnik 18 Oct '26

18 Oct '26

Hey everybody (bis), I submitted a(nother) proxoXEP today: <https://github.com/xsf/xeps/pull/1575>. A rendered version is at <https://nicoco.fr/bookmark-last-known-name.html>. The idea is for clients (or, wait for it: gateways) to set a bookmark extension "last-known-name" for MUCs in the PEP bookmarks. This last known name can then be used in the "start chat"-like dialog of clients for them to display a human-readable for the "chat" without (or before/while) querying its disco#info. Of course, this spec only makes sense if client developers think it does fill a gap. As a user, I know that there is a gap, because it happened a few times to me that I wanted to join a room from my new client, and couldn't figure out which bookmark item it was because it had never been joined before from this client (and the JID localpart was gibberish). Maybe it makes more sense to expect clients to disco#query all bookmark items instead. Side-note: maybe we should have some sort of registrar for standardized bookmark extensions, instead of having them all as separate XEPs? Maybe not. Community, what do you think? -- nicoco

1 0

Spec proposal: bookmarks hierarchy
by Nicolas Cedilnik 18 Oct '26

18 Oct '26

Hello all, Edhelas and I submitted a PR on github for a spec proposal: <https://github.com/xsf/xeps/pull/1574> A rendered version is at <https://nicoco.fr/bookmarks-hierarchy.htm>. The idea is to have an additional item in pubsub/pep nodes containing bookmark items, defining bookmarks directories. The bookmark items themselves have a dedicated extension referring to these directories, with a "weight" used to sort them within the categories. Our obvious use case is organising rooms in a XEP-0503 space, but it could possibly be used for organising PEP bookmarks too. Feedback welcome and appreciated! Have a nice sunday, -- nicoco

1 0