July 2026 - Standards

LAST CALL: XEP-0424 (Message Retraction)
by Daniel Gultsch 10 Sep '26

10 Sep '26

This message constitutes notice of a Last Call for comments on XEP-0424. Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted. URL: https://xmpp.org/extensions/xep-0424.html This Last Call begins today and shall end at the close of business on 2026-07-20. 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!

7 14

DC EDIC
by Matija Šuklje 27 Jul '26

27 Jul '26

Dear all, I’m a little bit involved with the DC EDIC (Digital Commons European Digital Infrastructure Consortium) and it seems like it could be interesting for the wider XMPP community. From its mission: > DC-EDIC develops, maintains, and scales digital commons for Europe, pooling > resources across member states to reduce technological dependency. <https://digital-commons-edic.eu/> The about page summarizes it pretty well and in short too, so I won’t copy- paste it here. They are setting up an EU STF similar to (and together with) the German Sovereign Tech Fund/Agency to sponsor development and maintenance of important software. While the first project is planned to be about a “collaborative workspace flagship”, communication and messaging is already explicitly part of that. In my opinion, DC EDIC could prove to be a big vector for getting FOSS, interoperability and (open-)standard-based formats and protocols into (European) public administrations and also to get funding for it. There are things both in the mission and the future project criteria that I feel resonate with the XMPP ecosystem very well and IMHO it would be a damn waste not to keep an eye on it and reach out. For example, there is currently a _call for experts_ out, where not just countries in DC EDIC, but also FOSS communities may suggest topic experts. I suggest the XSF puts forward someone there: <https://digital-commons-edic.eu/news/2026-07-01-advisory-board-call-for-exp…> kind regards, Matija -- gsm: tel:+386.41.849.552 www: https://matija.suklje.name xmpp: hook(a)campfire.wheremymonkeyis.at matrix: @hook:kompot.si

1 0

Post-quantum security of OMEMO
by Chris Tsichrinis 22 Jul '26

22 Jul '26

Hello everyone, I keep reading about recent developments in the quantum computing field, with whatever this may mean for classic asymmetric encryption/key exchange algorithms. More specifically, it appears that both Google (Quantum frontiers may be closer than they appear <https://blog.google/innovation-and-ai/technology/safety-security/cryptograp…>) and Cloudflare (Cloudflare targets 2029 for full post-quantum security <https://blog.cloudflare.com/post-quantum-roadmap/>) have targeted 2029 for post-quantum migration. Both of these blog posts made me ponder about the post-quantum security of the OMEMO. I am not an expert on the field of asymmetric cryptography, but per XEP-0384 <https://xmpp.org/extensions/xep-0384.html>, OMEMO uses the X3DH key agreement protocol for key exchange and the Double Ratchet Algorithm for message encryption and decryption. From what I can grasp, Signal has developed the PQXDH key agreement protocol as a post-quantum secure variant of X3DH, while Double Rachet also seems to provide no post-quantum protection <https://signal.org/docs/specifications/doubleratchet/#harvest-now-decrypt-l…>. With that being said, I'd like to ask if there are any plans to update the relevant OMEMO standard in the future to make OMEMO post-quantum-proof and if not, whether OMEMO's post-quantum security is considered trivial or not. Thanks in advance

2 1

ronaldoclubsupport@jabb3r.org
by keyshaj3636＠gmail.com 20 Jul '26

20 Jul '26

Hello I need to know why my account is not top up

1 0

ronaldoclubsupport@jabb3r.org
by keyshaj3636＠gmail.com 20 Jul '26

20 Jul '26

I need to know why my account not top up

1 0

We should require AI disclosure
by Goffi 14 Jul '26

14 Jul '26

Hello everybody, I would like to bring a discussion on AI policy. We can't really ignore anymore that modern models have become very capable, and I suspect that they are used for spec authoring. This raises, I believe, copyright issues: if someone use AI to redact a whole section of a spec, how can we be sure that it's not an existing specs for some other place, possibly under copyright, that is copied or paraphrased? How can an author guarantee that it's original work (hint: they can't)? I think that there are 3 distinct uses: 1. As a light formatting/checking help, for instance to generate a table from a human written section, to correct the formulation of a sentence, or to draft an example. This is notably useful for non native English speakers. 2. As a help to search existing state of art on some feature, or any kind of data, without writing anything in a protoXEP. 3. As a way to generate whole sections. Instinctively, and If we put aside ethical and ecological concerns about LLMs, I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases, it should be disclosed. I would like your feedback on this matter, in particular people with legal knowledge. I would like to avoid a flamewar, I know that this topic is sensitive and there opinions are highly divided, please express your opinion calmly. The fact is, we can't ignore this anymore. Should this be discussed with board or council? Thanks. Best, Goffi

14 42

Moving XEP-0066 to Final (emitting Last Call?)
by Goffi 08 Jul '26

08 Jul '26

Hello, The Council talked about moving a couple of stable XEPs which have not been modified for years to "Final". As this process has not been done for a long time, we want to first try with XEP-0066 (Out of Band Data). Peter, would you be fine with moving this specification to "Final"? Please not that dwd suggested to get rid of section 6 first (XEP-0095 being deprecated). If Peter is fine with getting rid of the section and moving forward, we can emit a last call. Thanks. Goffi

3 3

LAST CALL: XEP-0424 (Message Retraction)
by Daniel Gultsch 03 Jul '26

03 Jul '26

This message constitutes notice of a Last Call for comments on XEP-0424. Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted. URL: https://xmpp.org/extensions/xep-0424.html This Last Call begins today and shall end at the close of business on 2025-01-06. 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!

9 27

NEW: XEP-0516 (XMPP Decentralized ID (XID))
by Daniel Gultsch 01 Jul '26

01 Jul '26

Version 0.1.0 of XEP-0516 (XMPP Decentralized ID (XID)) has been released. Abstract: XMPP Decentralized ID (XID) is a DNS independent XMPP entity identifier. This specification describes how to generate, use, and handle them. Changelog: Accepted as Experimental by council vote (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0516.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.

3 2

Update to Jingle User Location ProtoXEP: call-scoped XEP-0080 binding
by Edward Tie 01 Jul '26

01 Jul '26

Hello, I have updated the Jingle User Location ProtoXEP with clearer wording after the Council discussion. The updated draft is here: https://github.com/xsf/xeps/pull/1550 The main clarification is that this proposal does not replace XEP-0080. XEP-0080 remains the location payload. The problem this proposal tries to solve is the call/session binding: XEP-0080 tells where the user is, but it does not reliably tell for which active Jingle call that location was shared. PEP/PubSub is useful for general user-location publication, but for an active call it does not clearly answer: - which Jingle session / sid the location belongs to; - whether the location was explicitly shared for this call; - whether it is fresh, stale, one-time, or live; - when call-scoped location sharing stops; - whether a relay, accessibility assistant or future emergency gateway may treat it as the location for the active call. The revised direction is therefore narrower: A small Jingle binding for XEP-0080 during an active call. It reuses the existing XEP-0080 geoloc payload and adds Jingle session context, stop-sharing/expiry wording, fallback wording and privacy wording. It also explicitly avoids claiming to be an emergency-service protocol by itself. The reason I think this matters is accessibility and 112/911-readiness. A deaf or speech-impaired user may be in a Total Conversation call with audio, video, RTT, captions, relay/interpreter services or a future emergency gateway. In that situation the peer or gateway should not have to guess whether the latest XEP-0080/PEP item belongs to the current call. Feedback is welcome, especially on whether this narrower “Jingle binding for XEP-0080” direction is the right shape. Kind regards, Edward

1 0