# Why not XMPP? **URL:** https://discuss.privacyguides.net/t/why-not-xmpp/13792 **Category:** Questions **Created:** 2023-08-29T07:49:22Z **Posts:** 28 ## Post 1 by @anon11391324 — 2023-08-29T07:49:22Z I see almost everywhere XMPP is good, secure, etc. And I personally love how it works. But it’s not recommended on PrivacyGuides. Is it because it’s not easy for beginners or is there a security flaw I missed ? --- ## Post 2 by @dngray — 2023-08-31T05:57:13Z The main reason is there is a massive differing in quality of clients, and what XEPs they support. Many actions are not E2EE, and it really depends on what client you’d be using. The protocol itself was never really designed for privacy, and a lot of those features have been shoehorned in afterwards, [XMPP: Admin-in-the-middle · InfoSec Handbook – your friendly and open-minded InfoSec community](https://web.archive.org/web/20211215132539/https://infosec-handbook.eu/articles/xmpp-aitm/) This was our previous reasoning: - [https://github.com/privacytools/privacytools.io/pull/1500#discussion\_r350414878](https://github.com/privacytools/privacytools.io/pull/1500#discussion_r350414878) - [Cleanup 2.0 instant messenger page by dngray · Pull Request #1836 · privacytools/privacytools.io · GitHub](https://github.com/privacytools/privacytools.io/pull/1836) --- ## Post 3 by @Used0259 — 2024-02-29T19:04:16Z To be honest, I don’t quite understand why Matrix passes this hurdle and XMPP does not. Matrix is just as little designed for privacy as XMPP. Metadata is also generated, is also not E2EE (as far as I know) and is also distributed further by federation than in XMPP. The quality of the clients is also very differing. I also see the advantages of Matrix and use it myself, but I find it quite interesting how an extra category was recently created to keep Matrix in the recommendations, although it does not support PFS, while XMPP was removed for reasons that also apply to Matrix to a large extent. --- ## Post 4 by @anon97654407 — 2024-02-29T19:31:18Z > [@Used0259](#): > > not E2EE (as far as I know) It is, maybe it depends on the client though, but Element does have E2EE : > **[End-to-end encryption (E2EE) | Collaboration and messaging](https://element.io/features/end-to-end-encryption)** > > Element is secure collaboration and messaging app designed to protect users and their privacy by using the highest grade end-to-end encryption by default. Messages can only be decrypted by participants in the conversation. --- ## Post 5 by @Used0259 — 2024-02-29T20:29:51Z I know that Element and many other Matrix clients support E2EE for messages, but not for metadata as far as I know. XMPP also has many clients that support E2EE for messages, but the criticism here was that metadata is not E2EE. --- ## Post 6 by @exaCORE — 2024-02-29T20:33:32Z > [@Used0259](#): > > is also not E2EE (as far as I know) It is E2EE as long as you enable encryption on the room. With regards to the PFS issue see this: [So... can PFS be enabled in Matrix at all? - #4 by exaCORE](https://discuss.privacyguides.net/t/so-can-pfs-be-enabled-in-matrix-at-all/12036/4) --- ## Post 7 by @Used0259 — 2024-02-29T20:41:11Z > Profile pictures, reactions, and nicknames are not encrypted. > Group voice and video calls are [not](https://github.com/vector-im/element-web/issues/12878) E2EE, and use Jitsi […] This is from the PrivacyGuides recommendations. I run a Synapse server myself and can retrieve a large amount of unencrypted metadata about users. --- ## Post 8 by @exaCORE — 2024-02-29T20:43:33Z The call thing is correct for the time being, native Matrix E2EE calls are coming very soon (i think it’s implemented in Element X currently…). Regarding the metadata, that is true, hence why people should use trusted homeservers. --- ## Post 9 by @Used0259 — 2024-02-29T20:50:46Z > coming very soon The same could be said about features for XMPP, many things are being developed (i think “coming soon” is an XMPP trademark since 2000). However, in my opinion, the current state of these two protocols is assessed differently here. > trusted homeservers With XMPP, a trusted server can actually protect more than with Matrix, since Matrix distributes the metadata much more generously to all other servers involved. In both cases, however, these are federated systems and the own server is not the only one to be considered with regard to metadata. --- ## Post 10 by @dngray — 2024-03-02T11:37:33Z The main reason with XMPP is that direct messages aren’t necessarily encrypted, it depends on the client. In regard to metadata they’re both in terms of federated data. There is also quite a variety of XEPs that implement encryption in some places and not in others, and it’s really a mixed bag of what your client actually is. We can recommend element, and know that DMs will be E2EE as will VOIP calls, in 1:1. --- ## Post 11 by @anonymous159 — 2024-03-02T23:45:02Z > There is also quite a variety of XEPs that implement encryption in some places and not in others, and it’s really a mixed bag of what your client actually is. Why not recommend just a client like Conversations then? I think it ticks all the boxes, except for an audit --- ## Post 12 by @anon63378630 — 2024-03-02T23:53:22Z @anonymous159 Conversations can do OMEMO for message content, sent images/files, and can negotiate the DTLS-SRTP encryption for calls over that same OMEMO channel, but everything else is not encrypted. The only client right now doing additional encryption for things like typing state and read marker events (via XEP-0420/SCE) right now is Kaidan, and that is very WIP. Additionally and not necessarily that bad is that very few clients right now even implement the latest version of OMEMO because there is no interop/migration between the newer and older implementation of it. The following is all not encrypted: - user vcards - user nicknames - user profile pictures - user rosters - MUC names - MUC descriptions - MUC profile pictures - MUC member list - MUC member affiliations - etc. Also not all clients give sent files random names even when encrypted, which can allow the server to infer what it is. (That being said I do still believe that XMPP does a lot of things really well, but my decade+ using it biases me to it.) --- ## Post 13 by @dngray — 2024-03-04T05:36:25Z Also we don’t really want to be recommending a protocol based on the fact there might only be one mature client out there, especially over Matrix which as far as privacy goes negligible differences. To put it another way, if Matrix only had Element on Android, we probably wouldn’t recommend that either. If Conversations was available on other platforms with equal maturity then the inclusion would have more relevance. --- ## Post 14 by @Used0259 — 2024-03-05T09:07:27Z Thank you for your answer. The argument that Element is available for all platforms in almost the same quality makes sense. I wrongly assumed that Matrix would be recommended. With that in mind, the exclusion of XMPP (clients) makes more sense to me than the sources linked at the beginning of the thread. --- ## Post 15 by @Cyber-Typhoon — 2024-08-27T15:57:11Z > [@anon63378630](#): > > The only client right now doing additional encryption for things like typing state and read marker events (via XEP-0420/SCE) right now is Kaidan, and that is very WIP. Isn’t Kaidan backed by the KDE development team? Also, even with all its flaws and limitations, isn’t this client/XMPP an interesting commendable real time messenger as much as some other options? > [@dngray](#): > > To put it another way, if Matrix only had Element on Android, we probably wouldn’t recommend that either. If Conversations was available on other platforms with equal maturity then the inclusion would have more relevance. Isn’t Kaidan available in other platforms? Including Linux, Windows, macOS, Android, Plasma Mobile and Ubuntu Touch. Notably missing iOS. Not sure if there are more XMPP clients that deserves a look. There is this [AstraChat](https://astrachat.com/) that seems to be available in multiplatforms. Edit: I don’t think there are other clients that deserves a look other than Kaidan. Like @anon63378630 mentioned it is the one along with Moxxy client offering the XEP-0420/SCE and Moxxy is Android only. --- ## Post 16 by @anon63378630 — 2024-08-27T17:13:45Z @Cyber-Typhoon because the version of OMEMO that Kaiden uses is not backwards compatible with the one most other clients implement. --- ## Post 17 by @Cyber-Typhoon — 2024-08-27T17:27:51Z I think this point may not be necessarily that bad, like you mentioned previously: > [@anon63378630](#): > > Additionally and not necessarily that bad is that very few clients right now even implement the latest version of OMEMO because there is no interop/migration between the newer and older implementation of it. I mean, it isn’t good but well others clients needs to catch up maybe? --- ## Post 18 by @anon63378630 — 2024-08-27T17:32:23Z @Cyber-Typhoon it is a very difficult problem and more deployment will fragment the ecosystem it was already fragmented once during the transition from OTR to OMEMO, going from OMEMO (0.3.x) to OMEMO 2 (0.8.x) will do just the same if it was easy it would’ve been done already. like you can’t just make a chat OMEMO 2 because everyone and all of their clients need to support it otherwise they’ll lose messages. furthermore there are more important issues like proper key management which even fewer clients properly implement. going even further it’d be nice to see better authentication or 2fa support or new device notifications. Conversations is the dominant app on mobile and serves as the basis for forks like Cheogram, Snikket, and Monocles. Kaidan _cannot_ compete with its level of polish, functionality, and reliability right now. edit: also of note is their (OMEMO 2 / 0.8.x clients) status: - Moxxy hasn’t been updated since September 2023: [Release v0.5.0 · PapaTutuWawa/moxxy · GitHub](https://github.com/PapaTutuWawa/moxxy/releases/tag/v0.5.0) - Kaidan ~~hasn’t been updated since May 2023~~ : [Kaidan 0.9: End-to-End Encryption & XMPP Providers - Kaidan](https://www.kaidan.im/2023/05/05/kaidan-0.9.0/) - edit/correction: it had a minor update a month ago: [v0.9.2 · Tags · Network / Kaidan · GitLab](https://invent.kde.org/network/kaidan/-/tags/v0.9.2) - UWPX hasn’t been updated since December 2022: [Commits · UWPX/UWPX-Client · GitHub](https://github.com/UWPX/UWPX-Client/commits/master/) whereas (OMEMO / 0.3.x clients): - Conversations was updated two weeks ago: [Making sure you're not a bot!](https://codeberg.org/iNPUTmice/Conversations/commit/b2ea164b41fcd447c654afc2a40b6a244bf84ce8) - Gajim was updated a month ago: [Gajim 1.9.3 - Gajim](https://gajim.org/post/2024-07-29-gajim-1.9.3-released/) - Dino was updated two months ago: [Release v0.4.4 · dino/dino · GitHub](https://github.com/dino/dino/releases/tag/v0.4.4) another edit just because people are hyperfocused on omemo 2 for whatever reason: - moxxy doesn’t support channel binding, conversations does - cheogram is the primary client supporting dane/tlsa verification --- ## Post 19 by @Cyber-Typhoon — 2024-08-27T18:50:09Z > [@anon63378630](#): > > Kaidan hasn’t **been updated since May 2023:** [Kaidan 0.9: End-to-End Encryption & XMPP Providers - Kaidan](https://www.kaidan.im/2023/05/05/kaidan-0.9.0/) Isn’t the current version the 0.9.2? > **[Files · v0.9.2 · Network / Kaidan · GitLab](https://invent.kde.org/network/kaidan/-/tree/v0.9.2?ref_type=tags)** > > Modern chat app for every device Fedora adds a dash in the end, e.g. 0.9.1-4 and 0.9.2-1, maybe a patch? > **[kaidan - Fedora Packages](https://packages.fedoraproject.org/pkgs/kaidan/kaidan/)** > > View kaidan in the Fedora package repositories. kaidan: A XMPP client based on KDE Framework Anyways, I followed the fragmentation point and I’m still on the fence with this argument. I know that you didn’t said anything along those lines but if Kaidan’s interface may not be that user friendly and have the features that the other clients has for users to communicate then it may become a problem of usability and not sure if it could be the driving factor for not be recommending Kaidan. --- ## Post 20 by @dngray — 2024-08-28T07:31:08Z Also regarding conversations: > **[Against XMPP+OMEMO - Dhole Moments](https://soatok.blog/2024/08/04/against-xmppomemo/)** > > XMPP is a messaging protocol (among other things) that needs no introduction to any technical audience. Its various implementations have proliferated through technical communities for decades. Many… imo XMPP was never really a “private” protocol, and people have tried to shoehorn things in there hoping it will be good enough. It is never going to be widely used and there is way too much quality disparity between clients. For that matter I haven’t met someone who uses it in the last 10 years. I think people really need to let XMPP go. --- ## Post 21 by @anon48875053 — 2024-08-28T07:47:35Z Agree, both Matrix and XMPP shouldn’t be used for 1:1. But for communities, Matrix is clearly a better choice, so there isn’t much use for XMPP out there. SimpleX, Signal, and maybe Threema? For 1:1 chats. Matrix for communities. --- ## Post 22 by @dngray — 2024-08-28T07:52:35Z > [@anon48875053](#): > > Threema? For 1:1 chats I don’t really see a whole lot of use case for Threema that isn’t covered by the other two. Also: [Threema: Three Strikes, You’re Out - Dhole Moments](https://soatok.blog/2021/11/05/threema-three-strikes-youre-out) . --- ## Post 23 by @crossroads — 2024-08-28T15:59:21Z I think they fixed most of those issues or working on it. Threema is more user friendly than SimpleX (and less private), and has server in CH instead of USA. But yes, there’s no much need to use anything but Signal for 1:1 and small/medium groups Anyway, I tried Kaidan recently and was surprised encrypted chats are not compatible with other clients (Gajim, Dino). And then realized this OMEMO2 issue. It really makes no sense to use it if there are no other clients supporting it. I actually like XMPP, but it’s true not so many people use it, it’s not so secure and private as some other services, it’s not so user friendly, lacks some features, and clients differ a lot in implemented extensions. I suppose it is still used in large organizations, at least it’s suitable for that use case. As I know, it easier and needs less resources for self-hosting than Matrix. --- ## Post 24 by @anon63378630 — 2024-08-28T16:18:40Z @dngray I made some points above specifically about that writeup’s hyperfocus on OMEMO. see also an XMPP related follow up to it: [moparisthebest.com - Against Silos+Signal](https://www.moparisthebest.com/against-silos-signal/) and a response from one of the OMEMO spec authors: [https://www.moparisthebest.com/tim-henkes-omemo-response.txt](https://www.moparisthebest.com/tim-henkes-omemo-response.txt) --- ## Post 25 by @asanyan — 2024-08-28T16:25:35Z Question: wouldn’t it be possible for a client to support both versions of OMEMO, and phase out support for the older one as other popular clients also decide to also switch to the newer version? --- ## Post 26 by @anon63378630 — 2024-08-28T16:29:10Z yes, but like I mentioned and will say again: there are far more critical issues that need to be solved that aren’t OMEMO related. --- ## Post 27 by @Cyber-Typhoon — 2024-08-28T21:08:58Z I think at this point I’m convinced that the disorganization of XMPP is what prevents it to progress. It is probably wise to keep it out of recommendations like was discussed here. --- ## Post 28 by @anon23293884 — 2024-08-29T09:17:18Z I enjoyed your analysis of the situation. Indeed, time has leapt forward and technology has moved along with it. It turns out that I was lucky that being in a younger generation and late coming to understand tech has kept me away from such tools.