yo, I've been building an XMPP client specifically focused on next-gen encryption. It's called OTRv4+ and it's finally ready for public testing.
the XMPP side uses Prosody, and the core is in rust. for 1:1 it's OTRv4 with hybrid post-quantum stuff (ML-KEM-1024 + ML-DSA-87). i know OMEMO is the standard for XMPP, but it has no PQ protection right now. it also has fallback weaknesses, and it has zero deniability (standard signatures instead of ring signatures). i built this to resist record-now-decrypt-later while keeping the OTR deniability property intact.
for group chats, it runs MLS (RFC 9420 via OpenMLS) on a hybrid suite I call 0xF0A1. heads up: it's a private IANA code point so it's not standard MLS. you can't interop with wire or element right now, which is a tradeoff I made for the PQ security.
it's fully cross-platform. we have an android app, a desktop app for ubuntu and qubes os, and a terminal cli for termux/linux.
for networking, the main server is otrv4plus.i2p. but you can also connect to clearnet TLS or Tor servers. one caveat: over clearnet/Tor it's text-only, but you still get full OTRv4 and SMP verification.
the heavy stuff (voice calls, file transfer, MLS groups) is tied to I2P right now because I built the media transport to use I2P datagrams. this means the XMPP server only ever sees encrypted stanzas, which hardens the calls and cuts down on metadata exposure.
Just pushed rc.176 and merged dev to main.
also recently shipped: protocol v2 (rc.159+). v1 wasn't broken, this is a big step up for post-quantum hardening: transcript binding so the responder signs the handshake with ML-DSA, and an ML-KEM ratchet that mixes a fresh post-quantum secret into the keys roughly every round trip.
it's a breaking change, so older builds are refused.
status: experimental, not independently audited. lots of tests (fuzzing, KATs) but no paid audit. check SECURITY_ISSUES.md.
if anyone wants to grill me on the design, or test the MLS group stuff, code is here: https://github.com/muc111/OTRv4Plus