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?

all 58 comments

sorted by: hot top controversial new old
[–] 18 points 9 months ago

Misleading title.

  • source
  • [–] 12 points 9 months ago* (last edited 9 months ago) (1 child)

    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).

  • source
  • hideshow 1 child comment
  • [–] 9 points 9 months ago (14 children)

    Self host your matrix server, use Continuwuity not Synapse, and do not enable federation.

  • source
  • hideshow 14 child comments
  • [–] 4 points 9 months ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 9 months ago (3 children)

    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.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 9 months ago (2 children)

    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/

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 9 months ago (1 child)

    Good to know... Well I am on matrix now, so no need to switch, but will keep in mind.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 9 months ago

    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.

  • source
  • parent
  • [–] 2 points 9 months ago (7 children)
  • [–] 1 point 9 months ago (5 children)

    It runs like shit, at least when I tried it. Never heard of Continuwuity, will looks into it thanks.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 7 points 9 months ago (4 children)

    Its the rebirth of Conduit -> Conduwuit -> Continuwuity. Built with rust, it's a community project that is pretty stable and finally free of drama.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 9 months ago (3 children)

    Wait a sec, I run Conduit on my test machine and seems fine so far. What drama did I miss?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 5 points 9 months ago (2 children)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (-1 replies)
    [–] 24 points 9 months ago (11 children)

    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/

  • source
  • hideshow 11 child comments
  • [–] 4 points 9 months ago (4 children)

    This post is 1.5 years old and outdated.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 9 months ago (2 children)
  • [–] 2 points 9 months ago (1 child)
  • [–] 7 points 9 months ago

    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.

  • source
  • parent
  • [–] 0 points 9 months ago (5 children)

    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.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 11 points 9 months ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 9 months ago (3 children)

    OMEMO leaks plenty of metadata

    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.

    I spent 40 min scouring Snikkets website and source repo without any clear way to determine what version of OMEMO they bundle.

    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

    My point is that security is independent of adoption.

    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:

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 9 months ago (2 children)

    From the OMEMO XEP specification under section 2.1 "Threat Model" https://xmpp.org/extensions/xep-0384.html#reqs-threat-model

    The OMEMO protocol does not protect against attackers who rely on metadata and traffic analysis.

    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

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 9 months ago (1 child)

    The specification only seems to say that message content are encrypted, making no mention of encrypting any other data than message content.

    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.

    Also, just because you self host it doesn’t make the unencrypted (meta)data any less dangerous.

    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.

    That just makes your server the point of failure.

    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.

    By your logic, why encrypt at all?

    E2EE is one mitigation against one type of threat. Not a silver bullet.

  • source
  • parent
  • hideshow 1 child comment
  • [+] 7 points 9 months ago (2 children)
  • [–] 1 point 9 months ago

    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.

  • source
  • parent
  • [–] 7 points 9 months ago (1 child)

    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.

  • source
  • hideshow 1 child comment
  • [–] 5 points 9 months ago

    I've hardly used it so far, but simpleX seems promising from my limited knowledge. I highly suggest checking it out.

  • source
  • [–] 8 points 9 months ago (1 child)

    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...

  • source
  • hideshow 1 child comment
  • [–] 4 points 9 months ago

    Prosody XMPP + Pidgin/(Monal|Xabber) has always worked for me. It is not hard to setup or manage, has E2E encryption too.

  • source
  • [–] 3 points 9 months ago

    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.

  • source
  • [+] 10 points 9 months ago (5 children)
  • [–] 8 points 9 months ago (3 children)

    They specifically asked for decentralized

  • source
  • parent
  • hideshow 3 child comments
  • load more comments (1 reply)
  • [–] 2 points 9 months ago

    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.

  • source
  • [–] 3 points 9 months ago* (3 children)

    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.

  • source
  • hideshow 3 child comments
  • [–] 1 point 9 months ago (2 children)

    Didnt tox development stop a while ago?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 9 months ago (6 children)

    You should check out "keet" or "Jami" for privacy message app.

  • source
  • hideshow 6 child comments
  • [–] 6 points 9 months ago (5 children)

    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.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 2 points 9 months ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 3 points 9 months ago (3 children)

    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...

  • source
  • parent
  • hideshow 3 child comments
  • [–] 4 points 9 months ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment