Version 1.1.0 of XEP-0490 (Message Displayed Synchronization) has been
released.
Abstract:
This specification allows multiple clients of the same user to
synchronize the displayed state of their chats.
Changelog:
* Add security consideration for sender verification of PEP
notifications. (dg)
URL: https://xmpp.org/extensions/xep-0490.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.1.5 of XEP-0084 (User Avatar) has been released.
Abstract:
This document defines an XMPP protocol extension for exchanging user
avatars, which are small images or icons associated with human users.
The protocol specifies payload formats for both avatar metadata and
the image data itself. The payload formats are typically transported
using the personal eventing profile of XMPP publish-subscribe as
specified in XEP-0163.
Changelog:
Fix inconsistent hash in the example with multiple data sources for
the same file. (nc)
URL: https://xmpp.org/extensions/xep-0084.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.
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!
Version 0.1.0 of XEP-0518 (Payment Required) has been released.
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 built on payment URIs
(such as the RFC 8905 payto scheme), supporting multiple concurrent
payment options, from bank transfers to transfers over distributed
ledgers or instant-settlement networks, and integrates with the
existing CAPTCHA challenge mechanism defined in XEP-0158.
Changelog:
Accepted as Experimental by council vote on 2026-07-07 (XEP Editor
(dg))
URL: https://xmpp.org/extensions/xep-0518.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 0.1.1 of XEP-0515 (TLS Channel-Binding Downgrade Protection)
has been released.
Abstract:
This specification provides a way to secure the SASL and SASL2 SCRAM
handshakes against channel-binding downgrades through TLS version
downgrades.
Changelog:
Fixed typo in Bind 2 namespace (XEP Editor (dg))
URL: https://xmpp.org/extensions/xep-0515.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.6 of XEP-0066 (Out of Band Data) has been released.
Abstract:
This specification defines two XMPP protocol extensions for
communicating URIs, one for use in XMPP message stanzas and the other
for use in a structured request-response interaction via XMPP IQ
stanzas. Among other things, this enables one entity to inform another
entity about a file that is available at an HTTP URL.
Changelog:
Twenty years later, strike section 6's SI suggestion (dwd)
URL: https://xmpp.org/extensions/xep-0066.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.
Good morning
the 29th XMPP Summit is fast approaching. It is our first attempt at
an online only Summit and will be held on Friday 4 September and
Saturday 5 September 2026.
If you intent to attend please add yourself to the participants list¹.
Adding yourself might also motivate others to participate itself.
Please find the time to do so even if there is no "limited seating" or
other constraints.
We are also looking for topic suggestions. We will maintain the
unconference style of offline summits (meaning participants can bring
their own topics) but for time constraints we will do the topic
suggestions and topic sorting ahead of time.
Meaning what usually happens on the white board in the first hour of a
traditional summit will now happen on list.
Please go ahead and propose topics and include a short pitch.
Additionally please add the topic to the wiki.² (If you someone only
suggests it here I’ll try my best to add it to the wiki myself.)
I will close the topic suggestion round on Thursday 27th so we will
have about a week to vote on the topics. (which will determine the
order of the four topics we'll be discussing during the Summit)
cheers
Daniel
¹: https://wiki.xmpp.org/web/Conferences/Summit_29#Participants
²: https://wiki.xmpp.org/web/Conferences/Summit_29#Proposed_Topics
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
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
