FOSSDLE PieFedBest apps for private messaging
submitted by
Manuwww.privacyguides.org/en/real-time-communication/
Hello. I am looking for an alternative to Telegram and I prefer an application that uses decentralised servers.
My question is: why is the xmpp+omemo protocol not recommended on websites when it is open source and decentralised?
The privacyguides.org website does not list xmpp+omemo as a recommended messaging service. Nor does this website include it in its comparison of private messaging services.
https://www.privacyguides.org/en/assets/img/cover/real-time-communication.webp
Why do you think xmpp and its messaging clients such as Conversations, Movim, Gajim, etc. do not appear in these guides?
I've personally used 4 encrypted communication apps, here are my thoughts:
Signal: huge downside that it required a phone number (not sure if it still does), and the centralized nature of it makes me very wary of it. It worked reliably when I did use it, but I no longer use it.
Matrix with Element: As others mentioned, it leaks meta data. It wasn't very reliable in my experience with encrypted group chats. Messages would constantly not be readable by other users in the chat, requiring frequent re-sending to finally get through. Overall I found it very frustrating to use.
XMPP: Experience can somewhat vary depending on the app used. With the Movim desktop front-end, I can sometimes have issues with encrypted messages not getting unencrypted (possibly just user error on my part), but with mobile apps like Conversations or Monocles, its been pretty much 100% reliable. Doesn't drain my battery either. Would recommend.
Deltachat: I've used this the least, but I really like it. Super easy to connect to friends and join a group chat, its all encrypted by default so no real chance of encountering an unencrypted message, very nice UI, is available on all platforms as one app, and has been 100% reliable with low battery drain. Highly recommend if you don't need to make voice calls (it can do texts, images, and supports voice/video files you can send and play within the app).
Self host your matrix server, use Continuwuity not Synapse, and do not enable federation.
Then why bother with Matrix at all if that's not for the federation? You give yourself the trouble and inefficiencies of an over-engineered protocol you won't even use.
Because matrix has the bet bridges so I can centralize all other protocols on my matrix server (Continuwuity) and have whatsapp, telegram, Signal all accessible from one single app.
All those bridges rely on some community-made libraries developed by few individuals unrelated to Matrix, so, not only there isn't much Matrix-specific to them, but it's reproduced for other protocols, JFYI: https://slidge.im/
Good to know...
Well I am on matrix now, so no need to switch, but will keep in mind.
At least you are on the continuwuity side of it, which is much more sane than hosting synapse (but you are missing out on many features I guess. If you get tired of this eventually, give ejabberd a shot, it's self-contained with all features, including VoIP/AV calls.
Why not Synapse?
Super heavy, and overkill unless you need to run matrix.org itself.
It runs like shit, at least when I tried it. Never heard of Continuwuity, will looks into it thanks.
Its the rebirth of Conduit -> Conduwuit -> Continuwuity. Built with rust, it's a community project that is pretty stable and finally free of drama.
Wait a sec, I run Conduit on my test machine and seems fine so far. What drama did I miss?
Conduit has been dead in development for years now. Conduwuit was the successor, then some drama got it shut down and reborn (new maintainers) as Continuwuity.
Conduit saw no up grades in years IIRC and its basically abandoned I guess.
Thanks for explaining. But unless I'm missing something, Conduit doesn't seem to be quite dead just yet. I got upgrade notifications throughout 2025, the latest two being in December; one for v0.10.10 and the other for v0.10.11.
Deleted by moderator
I share your concerns with the matrix organization. Most of the other concerns on that article don't apply to a private instance with only just less than a handful of users who anyway live together or share more than an online existence.
Deleted by author
Here is a blog post by a widely respected cryptographer on why XMPP+OMEMO is not secure: https://soatok.blog/2024/08/04/against-xmppomemo/
This post is 1.5 years old and outdated.
Do you know if there is a more up to date description of xmpp e2ee without having to read the spec. Specifically interested in stuff like how much metadata is leaked.
What has changed?
They updated OMEMO
Did that fix any of the underlining issues with OMEMO use across XMPP clients, such as odd/opaque choices by the OMEMO maintainer, or the fragmentation of OMEMO versions used by clients (most being very out-of-date)?
Let me be clear: I am NOT anti-XMPP (or even OMEMO). I would love to see it succeed because I much prefer it over Matrix and other alternatives. My problem isn't with the technology, just the implementation.
This blog post has been debunked as fallacious (posing as evidence what's unsubstantiated), and in bad faith (some comments, including by the protocol developers, were removed from the blog's comments section). That aside, if you are left unimpressed by the crypto jargon, all you take away from it is that Soatok really likes Signal and this isn't Signal. There have been several independent audits on OMEMO, it's used today by serious institutions and governments, it's been under more scrutiny than soatok gave it, and there's nothing knowingly insecure about it.
OMEMO leaks plenty of metadata; most things other than message contents are left unencrypted. Many of the mature XMPP use different OMEMO versions (which can be hard to tell when the client doesn't clearly state the XEP versions, like Snikket). I spent 40 min scouring Snikkets website and source repo without any clear way to determine what version of OMEMO they bundle. I said OMEMO+XMPP because no matter how secure your protocol is, the actual implementation by your largest userbases determine real-world security.
And lastly, just because "serious institutions and governments" use it doesn't make it more secure. Many European governments use Matrix, and that has even worse security, breaks forward secrecy, doesn't encrypt basically anything other than message content, etc. Many governments have critical systems that run unpatched Win 7 or older. My point is that security is independent of adoption.
Could you even cite an example of such leaked metadata? I'd like to also remind you that metadata leaking to your own server (which you can chose, which you can self-host) isn't as big a deal in XMPP as it is with other services. Which is also why I can't take Soatok's opinion about and obsession for Signal seriously: when all accounts are hosted by a single actor, you have a much bigger metadata problem, and all obfuscation attempts (sealed senders being one) are ultimately defeated by simple timing and packet correlation attacks.
You were probably looking at a rebrand/spin of https://xmpp.org/software/conversations/ . All major XMPP clients and servers declare their compat via DOAP: https://xmpp.org/extensions/xep-0453.html
Correct, but in this case OMEMO is secure and is used in contexts where security actually matters. There have been multiple audits of it over the years:
https://conversations.im/omemo/audit.pdf
https://raw.githubusercontent.com/hardenedvault/vault-docs/master/report/lurch-audit.pdf
https://www.scribd.com/document/568512285/chiffrement-messagerie-instantanee-fmaury-anssi
https://download.igniterealtime.org/smack/docs/smack-omemo-audit-1.0.pdf
From the OMEMO XEP specification under section 2.1 "Threat Model" https://xmpp.org/extensions/xep-0384.html#reqs-threat-model
Off-topic, I would also like to add that the spec says " It has been demonstrated, that OMEMO provides only weak forward secrecy (it protects the session key only once both parties complete the key exchange).", citing https://www.cypherpunks.ca/~iang/pubs/dakez-popets18.pdf
The specification only seems to say that message content are encrypted, making no mention of encrypting any other data than message content. Look under sections 1.2 and 4.4 to see what I mean about there being no mention encrypting other data (eg. recipients and room names). This means that sender/receiver are (most likely) not encrypted. I don't think (though I don't know for sure) that room names are encrypted either.
What happens if you communicate/participate in an encrypted chat/user on another server? Could the server owner now see the other unencrypted data and metadata?
Also, just because you self host it doesn't make the unencrypted (meta)data any less dangerous. That just makes your server the point of failure. By your logic, why encrypt at all? It all lives on your* server, it is only a problem if someone has access to *your server. Networking is encrypted with TLS anyways, so why bother. /s
Correct, what's not encrypted are things like typing notifications, read markers, recipients. Which was my whole point: this is inferred easily by the server anyway: it hosts your account and your contacts list already, it routes your messages to recipients and across the whole network. You can't really operate without this level of trust. Neither in XMPP nor in Signal.
You seem to hold a very naive take on all of this. This is the basis of federation. In a centralised system (Signal), everyone must trust that the one provider to act (and keeps acting) in good faith. Federation loosens this by having you trust a provider of your choice, and by giving you the ability to move on otherwise. Zero-trust is only theoretically achievable with peer-to-peer, but we have yet to come-up with a system that is performant and efficient enough at scale to be deemed usable. P2P networks often resort to edge gateways to do some caching or connection brokering, and at that point you are back to the same tradeoffs as with federation, only with more steps and worse results.
Always was, always will be. Like I said, remove the server and you are onto something… Make it work well, and you will be the first, and do the world a great service.
E2EE is one mitigation against one type of threat. Not a silver bullet.
Some thoughts from "Asahi Lina" that sums it up: https://phanpy.social/#/vt.social/s/116054925440220855
Misleading title.
The freenet/futo devs are working something called river (https://freenet.org/). I don't think it's mobile yet and cannot attest to it's call quality. It's fully decentralized though, so it should work even if they abandon the project.
Here's a video on the protocol https://youtu.be/3SxNBz1VTE0
Mostly goes over the introductory docs that're on the site.
reason for them not appearing is that xmpp is a largely relaxed platform, that is, all implementations are not equally strict. some may implement certain extensions, others may implement other. encryption (omemo) is a common one that most implement, but then client (the user apps like gajim) may or may not implement them correctly, or they may have a fallback (first communication between 2 clients maybe is not encrypted), and other different problems with encryption being flaky (firstly, it is not perfect forward secrecy, it is a bit prone to failure (messages unable to decrypt), etc.), hence it is not recommended much.
That's the nature of any federated protocol, and also what makes them highly desirable: there's no central authority to dictate what is a compliant client or change the deal overnight and enshitify your user experience. That said, XMPP+OMEMO is as universal as things get, so there's no real concern there.
For the first communication not encrypted there's an easy solution: force encryption on your side and block unencrypted communications.
Theres snikket as a solution to that
I've hardly used it so far, but simpleX seems promising from my limited knowledge. I highly suggest checking it out.
I know it's not the most popular, but I've genuinely been happy with Matrix for the last few years.
Obviously there are problems, but it really has gotten fairly stable. At least...for me...
+1 for matrix
No idea. I use the app Conversations (XMPP+Omemo) and it works great. Only downside ist that you have to somewhat trust the server you are on, because of metadata. But thats basically every chat app.
Prosody XMPP + Pidgin/(Monal|Xabber) has always worked for me. It is not hard to setup or manage, has E2E encryption too.
Right now, the open source community has so many different ways to communicate.
The problem is what is the goal, privacy or security.
All seem to have benefits and problems.
I use conversations and delta chat. I don't know what is best. But it is better that anything that is owned by big corps.
Deleted by author
They specifically asked for decentralized
SimpleX is decentralised, isn't it? https://rickcarlino.com/2024/simplex-chat-bots.html
Uhhh I mean kinda? SimpleX is just a network and the servers are just relays. So, is TOR "decentralized"? It's definitely not centralized.
removed comment:)
If you don't like Signal, SimpleX is also an option.
Tox, where is TOX ? Why it's not mentioned in the article ? It's te most private messaging app, no other app can be more secure.
Didnt tox development stop a while ago?
It's a very slow development but still active https://github.com/TokTok/qTox
A thats cool. I used it for a while as a skype(hah!) alternative, but call quality is very low and it has no noise cancelling. Chat works though.
You should check out "keet" or "Jami" for privacy message app.
Jami is nice in theory, but it was very buggy for me when I tried it and Jami calls had no noise cancelling at all. Other than that, it does work.
I cant find the "keet" git repo, I think its proprietary. So thats a no go for privacy.
https://github.com/holepunchto/keet-appling-next
Here is the github link, note that, this is the "shell" of the desktop.
There is another repo specifically for android app.
https://keet.io/ is the official website
Developer is holepunch and uses "pear" peer-to-peer protocol.
Yeah, I saw that too, that not the full source code. I found another repository for the android releases: https://github.com/holepunchto/keet-mobile-releases
Again, no source code, just binaries. Rather shady I think...
Yeah Keet (and Pear in general) are doing some open washing, branding their apps as open source while using very restrictive licences, at least that's how I feel about them. It's closer to source available to my eyes.
What licenses are these? I only found apache licenses for the stuff they released. But yes, it kinda looks like open washing, since it looks like keet is open source, but its not.
Yes, that's the real issue