Modern XMPP project discussion - 2026-02-23

This sounds a lot like how we ended up with most clients still only supporting an ancient version of OMEMO despite _several_ more modern iterations existing and bringing cryptographic improvements

The only reason for that it, that there are no libraries for omemo2 in many langs. It has nothing to do with what's written above. There is no fallback for encryption in any client.

Apologies I wasn't trying to point to fallback, but the clients doing whatever they want

I assumed for compatibility purposes, but honestly I could be mosinformed there.

> The only reason for that it, that there are no libraries for omemo2 in many langs. It has nothing to do with what's written above. > There is no fallback for encryption in any client. Hey distaza , can you take a look at OMEMO2 support for your client?

Absolutely, I can.

Clients always do what they want. Even with the much stricter matrix protocol. As soon as there are two people there are two opinions. But I don't think this has anything to do with omemo.

As long as one doesn't have an issue to, to disable omemo or not talk to some people, one can implement omemo2 without the older one. It's only on some OS, like android and ios, we don't have it. (I confess I didn't yet try this moxxxie client for android)

starkzarn, the deployment of new features and changes to an open ecosystem is an interesting and difficult problem. When everything is centralized and you have one entity in control, it's fine. They can coordinate feature roll-out across all relevant software. In open ecosystems such as ours (and others include Matrix, email, etc.) it's more tricky. Literally anyone can turn up and write an XMPP client as a weekend project, and nobody can stop them. Likewise, nobody can force them to implement anything by any deadline. Add to that the dynamics of something like end-to-end encryption, where it's 1) non-trivial to implement, 2) both ends have to be compatible with each other, it only makes it harder.

I wrote a blog post covering some of this topic for the Snikket blog: https://snikket.org/blog/products-vs-protocols/

I did at some point suggest possibility of OMEMO-2.1 (or OMEMO-3 if you will) based off Noise, the Signal protocol derivative underpinning Wireguard, WhatsApp encryption and a version of I2P. It seems to have a lot of implementations to pick from.

But I think putting that time and effort into MLS would be more benefitial.

However I don't think MLS is as widely implemented yet, so make of that what you will.

Oh, forgot the linky: https://noiseprotocol.org/

I have the vague impression that Noise is something on a similar level as with TLS, but I could have misunderstood

It handles authenticated encrypted delivery of messages/packets, so that's about the same thing. But yes it's generally more lowlevel with more options that aren't relevant to us. See https://www.latacora.com/blog/2018/07/18/factoring-the-noise/ on why won't care for most of it's modes

Since public keys are know to servers mediating the transport (as they are stored in unencrypted pubsub nodes) it'd be Noise_IK as we'd have no benefit from the modes with extra roundtrips that would try to hide them.

Maybe KK since responder can and should probe for the initiator's public keys too, but I don't think there's any benefit to that mode.

I saw fluux as a new client and its in a good position to target discord refugees, but personally I'd love to see some e2ee-first solutions that are meant to compete with signal, Deltachat, etc.

starkzarn: the paradox I see in that is that discord isn't about e2ee, so discord refugees probably wouldn't mind so much. And signal/deltachat refugees have Conversations & al. already.

> starkzarn: the paradox I see in that is that discord isn't about e2ee, so discord refugees probably wouldn't mind so much. And signal/deltachat refugees have Conversations & al. already. 100% agreed. I just want to have my cake and eat it too. ↺

I came back from believing that large MUCs and community chats should be e2ee as a default. If you have a large chat, there's probably no secrecy involved. All the while e2ee comes with huge UX penalties like no server provided search through messages histories

Yup it's just a lot of added complexity for no real benefit

And a false sense of security

☝️

*ratcheting* e2ee and wikis do not mix.

PKI encryption is still just fine for that.

I do keep thinking there is lot of semantic confusion about what's considered chat. Just now I've been told the main use is "sending obscene amount of media".

What's that, does someone need to make a chat system D&D alignment chart? :)

If you separate the two needs, 'I want a *secret* conversation' and 'I want a *publicly searchable wiki*, it makes it so much easier to tell what kind of cryptographic hammer to use and where the correct nails are.

We are in a position to do both - a PKI ring (think PGP or S/MIME, age, etc etc, for those who don't like PGP) for public, both sign *and* encrypt. OMEMO for DMs and secret groups. Easy. Done.

Yes. With our xmpp clients we can choose between: Super secret with forward secrecy, pgp style e2ee and only transport encrypted, choosable per chat or even message

No other system I know of has this flexibility.

We have the programs and libraries to do this work - the cryptography sensitive ones, and the programs to do transport, it's just glue that's needed to make them operate in the correct state and order, which is a really good place to be at.

> starkzarn: the paradox I see in that is that discord isn't about e2ee, so discord refugees probably wouldn't mind so much. And signal/deltachat refugees have Conversations & al. already. That's exactly what I think we need, too. There are *multiple* public communities that I am an admin of that are longing for a good platform to go to. We don't need E2EE because joining the group is quite easy - public links and a quick admin check, and you're in.

I highlighted this in a blogpost I wrote earlier, specifically about how I think of Discord more of a Community Organization tool and less of a chat platform. I don't think XMPP is that misaligned from these needs, but the clients and some special organization could be better.

Discord's main appeal is locating and facilitating communication over multiple mediums and determining who gets to see it.

That's all it actually takes to do access control.

We can implement the 'who gets to' by just sending a request from a client to a socket, attaching an arbitrary access control program to the socket which can also check any of the relevant server data, and return the appropriate response. ✏

You can make an is_joined program that takes an XMPP stanza from the client, extracts the requester JID and room URI, and produces a yes/no/maybe signal.

Make a lot of small programs like that that accept a stanza and you have resilient and simple access control levers.