XMPP Service Operators - 2026-05-09

> Ideally if everyone you onboard wants the same experience you get them all on the same app. Then you have one thing to explain. > > A MUC csn absolutely refuse so-called “unencrypted” messages though That kind of defeats the purpose of XMPP. Also this also doesn't work because not one app supports all platforms, and I don't think they should. Otherwise it just becomes like element, a huge, slow, insecure electron app which runs on all platforms poorly. ↺

There is no single purpose of xmpp. It's totally cool if one operator wants to enforce encryption. There are prosody modules for it for example. Easily done with mod_firewall too.

Is E2EE on MUCs a thing now? Does that work with OMEMO?

Yes jaj, since the beginning of omemo

The server side doesn't care about it, (unless you write a module to enforce or deny it)

Yes but the client needs to encrypt for every participant and manage the keys

afaik it needs to be semi-private or private

indeed

and JIDs can't be hidden

In principle jids could be hidden but in practise I think all the apps assume they are not in a private room, which is the only place omemo makes sense

> Perhaps an opinion that's incompatible with the design of XMPP: but does anyone else wish there was a means of "requiring" certain features be enabled from the server side? Example, if I have an muc that's invite only, require a minimum version of OMEMO be enabled for participation. Or, not quite that extreme, but if a connected client supports DNSSEC/DANE enforcement then "suggest" to the client that it be enabled. > > The biggest one would be the encryption requirement. To me, things should be encrypted by default in 2026, but not every client agrees and, especially with new users, needing to walk them through enabling it, as well as different clients presenting it in different ways, is something that can make for friction. Makes sense to me that if I'm hosting the muc, whether it uses encryption or not would be something I could choose. 🤷‍♂️ for sure, google loves this idea and just rolled it out last week, now you can't even visit certain websites without proving you have an up to date unmodified iphone or android https://support.google.com/recaptcha/answer/16609652 https://cloud.google.com/blog/products/identity-security/introducing-google-cloud-fraud-defense-the-next-evolution-of-recaptcha/ we can start requiring this for anyone messagingus or our MUCs ↺

> Perhaps an opinion that's incompatible with the design of XMPP: but does anyone else wish there was a means of "requiring" certain features be enabled from the server side? Example, if I have an muc that's invite only, require a minimum version of OMEMO be enabled for participation. Or, not quite that extreme, but if a connected client supports DNSSEC/DANE enforcement then "suggest" to the client that it be enabled. > > The biggest one would be the encryption requirement. To me, things should be encrypted by default in 2026, but not every client agrees and, especially with new users, needing to walk them through enabling it, as well as different clients presenting it in different ways, is something that can make for friction. Makes sense to me that if I'm hosting the muc, whether it uses encryption or not would be something I could choose. 🤷‍♂️ you can already, I think mod_firewall lets you filter stanzas, look for omemo and the version identifier and then drop anything too old. ↺

> yup. "Best Practices" XEPs are the unsung heroes. I think I've got the server about as China-ready as it's going to get at this point, I'll likely set up I2P as a fallback too. All that's really left is to get the Chinese homie plugged in and see what happens 🤷‍♂️ wish tor/i2p/ygg federation were set up by more servers. more decentralization and being able to host behing cgnat ↺

i was hosting on tor

but no one was using it so i shut it down

i might bring it back

>> Perhaps an opinion that's incompatible with the design of XMPP: but does anyone else wish there was a means of "requiring" certain features be enabled from the server side? Example, if I have an muc that's invite only, require a minimum version of OMEMO be enabled for participation. Or, not quite that extreme, but if a connected client supports DNSSEC/DANE enforcement then "suggest" to the client that it be enabled. >> >> The biggest one would be the encryption requirement. To me, things should be encrypted by default in 2026, but not every client agrees and, especially with new users, needing to walk them through enabling it, as well as different clients presenting it in different ways, is something that can make for friction. Makes sense to me that if I'm hosting the muc, whether it uses encryption or not would be something I could choose. 🤷‍♂️ > > for sure, google loves this idea and just rolled it out last week, now you can't even visit certain websites without proving you have an up to date unmodified iphone or android > https://support.google.com/recaptcha/answer/16609652 > https://cloud.google.com/blog/products/identity-security/introducing-google-cloud-fraud-defense-the-next-evolution-of-recaptcha/ > we can start requiring this for anyone messagingus or our MUCs Googles doing too much. I hate how they have so much control over the web and android. Probably requires a valid play integrity result too 🙄 at least with what I'm talking about users whos clients don't support OMEMO wouldn't be able to read the other users' encrypted messages anyway. But to me, if your client doesn't support OMEMO in 2026, use a better client that's actively being developed because there's probably plenty of other issues with it. Not like I'd be requiring anyone to buy new hardware (windows 11 anyone?), just download a more actively developed app ↺

Hm. I could add a ygg AAAA record and use an srv record to point to that record for s2s.

> Hm. I could add a ygg AAAA record and use an srv record to point to that record for s2s. Yes I do this ↺

Likewise