XMPP Council - 2026-06-01

I'm surprised to see that OMEMO is still experimental. Why's that?

there are very few implementations of the current version

Is it in shape to advance to Stable? That is the signal to plz moar implementations, is it not?

alternatively, can we revert to the previous version, advance it, then revert the revert? ;)

For the third time?

double-alternatively, revert to v0.3 that everyone implements, then submit the previous latest as a new XEP because why not have more XEPs and A/B race them!

I'm experiencing the old 'this is making us look bad' argument around this specifically. I'm not in ernest suggesting to bypass the process, but OMEMO-based end-to-end-encryption is supported in a non-trivial manner. That should be reflected.

Maybe resubmit 0.3 as a historical XEP?

> Is it in shape to advance to Stable? That is the signal to plz moar implementations, is it not? OMEMO as a whole becoming stable? Or just the ratchet and fundamental stuff about OMEMO ↺

Algorithms come and go

OMEMO is tied to the algorithms. If you wanted to change the cryptography it would be a different thing / new XEP

The latest omemo version is the objectively better version. Making it stable and/or signaling will not magically create more implementations

What's holding it back is lack of underlying crypto primitives / a crypto library

It does signal that we deem the XEP as more mature.

Is there a reasonable path to advancing the XEP, without the availability of those underlying primitives?

At this point I don't see a good reason not to advance it to stable. There are several implementations of the newest version with more on the way, and many of the learnings from 0.3.0 impls are also relevant for modern OMEMO and have been fed back over the years to make the XEP more mature. I've actually had a bunch of reports of OMEMO "just working" that made me very happy after all the years of instability. And I am not aware of any remaining rough edges that might cause significant changes or namespace bumps. The library economy has also improved even though it's not _great_ yet. The only potential argument to keeping it experimental is that I think SCE (0420), which is a core requirement, might have a few rough edges still that might prompt changes.

yes, SCE clearly has a bunch of TODOs and we must introduce a pattern how w make it interact with other specifications. §9 has an incomplete list of elements that can't be encrypted and shouldn't be accepted from encrypted payload, but it's probably not the best idea to make this in the SCE XEP and rather have that specified in each XEP how it interacts with 0420 (I guess)

I guess some of that may shake out with the OX work Daniel has a grant for