XMPP: The secure communication protocol that respects privacy | Hacker News Reader

XMPP: The secure communication protocol that respects privacy

notes.nicfab.it

284 pointsneustradamus156 comments

Hi! Glad to see XMPP on the HN first page this morning :)

I'm working on a social-network and IM web platform (for 12 years already!), fully built on XMPP https://movim.eu/.

Thanks to its extensibility and the PubSub XMPP standard (see https://xmpp.org/extensions/xep-0060.html) you can easily build social-network like features. The standard is pretty simple, it's Atom 1.0 transport within PubSub (see https://xmpp.org/extensions/xep-0277.html).

For those that likes RSS/Atom you can also easily publish Atom newsfeed to PubSub (see https://github.com/edhelas/atomtopubsub) and follow your favorite website using your XMPP account and with real-time pushed articles. Here is ArsTechnica as an example https://mov.im/?node/news.movim.eu/ArsTechnica

XMPP is not only for IM, but way more than that ;)

I've seen movim around but I have never actually tried it. This post gave me the push. So thank you for that. I do have a question though:

On https://mov.im/?login it says:

"Login using any XMPP account or create a new one"

But it only shows me a login form where I can enter my xmpp address and a password. This signals to me that I can log into my existing non-movim-xmpp account, but I have to enter my password on there? That can't be right. What am I misunderstanding ?

Movim is a social-oriented XMPP client, so yes, it needs to log in to your account. You don't have to use the mov.im instance - in an ideal world your own server can run a copy of Movim, but you can also self-host, or even run it locally on your system.

This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and publishing/updating related standards. That's the kind of thing Movim would be able to take advantage of so you can grant (restricted) account access to a remote Movim instance without sharing your password.

> This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and publishing/updating related standards.

So that I can do something along the lines of "Log in with XMPP" and then my client asks me "hey do you wanna allow movim.eu to access foo/do bar on your behalf" ?

That sounds very useful. Sharing my password like this does not seem a great idea.

This is already possible! https://xmpp.org/extensions/xep-0070.html

That's slightly different. XEP-0070 is about allowing someone to verify that you own a given XMPP address. That is indeed often all you need for a "Log in with XMPP" functionality. Just how many sites allow you to log in with an email + verification link today.

However it does not grant someone the ability to connect to your account and perform any actions. Movim is an XMPP client. It interacts with the XMPP network as you, not as a third-party. That's very different to what XEP-0070 is for.

Currently the only practical way to allow someone access to your XMPP account is to give them your credentials. But if you do that, there's no way to restrict, monitor or revoke their access (apart from changing your password - something they would also be able to do!).

Many XMPP server implementations already implement some of the building blocks for something better (e.g. Prosody and ejabberd both support OAuth in some form already). But there are a number of important missing pieces before we can get it usable and adopted, and that's what I will be focusing on this year.

Again, in Movim's case it's fully open-source. You can self-host it or run it on your laptop, so you're never forced to hand over your credentials to any third party today. But many people would find a mechanism to grant a third-party limited access to their account an acceptable solution, so they can use Movim instances hosted by others.

Oh i was not aware you're working on proper authorization/delegation for XMPP. That's really cool! Can't wait to see your blogpost on this topic on HN front page :)

I wanted to try it out, but this is annoying:

- registration happens on https://api.movim.eu/register and firefox provides me a way to generate a password and save it linked to that domain.

- now I want to log in at https://mov.im/?login but firefox has no idea that it should use my api.movim.eu account for that.

Yes this is perfectly normal.

The XMPP account (so movim.eu) is decorelated from the mov.im pod we deployed as a public instance to show up the project.

You can connect on Movim (and mov.im, the official pod/instance) using any XMPP account. movim.eu is just one amongs all the others.

You have to differenciate Movim as a project that particular instance deployed as mov.im and the Movim XMPP server that we deployed from the project. I know it might be a bit confusing so if you have some ideas to clarify things up do not hesitate :)

I think this is the same problem matrix has: you end up entering your login details on foreign domains. There's really nothing stopping them from capturing that login via malicious javascript and using it for some malicious mitm, or just saving it to try on other services (you can't expect everyone to use a randomly-generated password). I don't see why you couldn't just enter 'server.com' (your xmpp server) and have an OIDC flow performed (the same complaint goes for matrix).

Login should happen on a single domain (same one that was used for sign up). Just redirect from mov.im to movim.eu and back, same as Oauth.

I have my own XMPP server ;-) and I understand the underlying problem here. I mostly wanted to point out that for a new person to quickly try out Movim this might be a stumbling block. As another comment suggested using something like OAuth to smooth this out might help.

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messen...?

Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for your account. What about all of the cleartext data and metadata that can be accessed by parties on the XMPP server, like the XMPP server admin, see https://infosec-handbook.eu/articles/xmpp-aitm/?

This logic implies that e-mail is also secure and privacy respecting.

I await future articles "Saudi Arabia: The resource poor country with a thriving democracy", "Bears: These vegetarians are too shy to defecate outdoors" and perhaps soon, "Popes: The married women who are rarely seen in church".

But maybe they've just never seen a protocol more secure than telnet or more privacy respecting than the News Of The World ? Nobody show them Signal or their head might explode.

Thanks for the laugh, you should write news title it would be fun!

Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example.

As the ex boss of NSA said "We Kill People Based on Metadata".

> Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example.

Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"?

And how about looking at more than just an isolated property of a competitor?

> As the ex boss of NSA said "We Kill People Based on Metadata".

XMPP servers are a gold mine when it comes to metadata.

> It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved.

Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place. How many of your contacts who use Signal used their real phone number?

> XMPP servers are a gold mine when it comes to metadata.

Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP.

> How many of your contacts who use Signal used their real phone number?

Most of them; however, there is no obligation to provide any personal data when registering a SIM card in my country. Even if providing personal data would be mandatory and if we assume that telcom providers track us all the time, then it doesn't mean that this data is accessible to the organization behind an instant messaging service.

> Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP.

This ignores that Signal and XMPP don't process the same amount of metadata in the first place, and the de-facto centralization of the XMPP network (also stated in our article -> the majority of XMPP users only uses a small number of public XMPP instances, and these XMPP instances are hosted by a tiny number of companies in mainly three countries on this planet).

> Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place.

I believe the real reason Signal requires a phone number is that it is a pretty good anti-spam filter

But I already have a phone number. My friends already know my phone number. If I instead got a "nickname" it would be tialaramex of course, which is even more identifying than my phone number. If I chose a deliberate random pseudonymous "nickname" to avoid "metadata" - then nobody can contact me, what use is that?

The NSA may "kill people based on metadata" but XMPP produces far more metadata for such decisions than Signal.

XMPP encourages people to build clique servers, which fail a key security requirement "Don't Stand Out". The six other users of "Bob's 100% Preparedness Militia and True Patriots Server" may be quite sure Bob is trustworthy and won't rat on them, and maybe one of them only uses it to post funny GIFs of cats, but the loose metadata association between this group and a plot to kidnap a State Senator means all seven of them are targets anyway.

But if you try not to stand out by using a popular server, that server's operators have far more insight into you than Signal's server operators do. Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. I know, because I decrypted the message, but Signal does not. That's a bunch of heavy cryptographic lifting, but from their point of view it was worth it to improve privacy.

> Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that.

This seems wrong. How could the Signal server have relayed the message from Steve to you if it does not know the recipient?

They have a feature called "sealed sender"[1]. Your Signal client authenticates to a Signal service that verifies you, and then signs and issues a certificate that you can use to vouch for your identity.

Then, you can encrypt this certificate as part of your message. Then ask Signal to deliver your message to the recipient. The Signal server won't be able to tell the recipient the account that the message is from, but after the recipient decrypts the message they will see the signed certificate and know it was you.

The problem with this is, Signal is centralized and they see the both the IP address (and other metadata) when you contact them to obtain the certificate and they they also see the IP address you send the message from. Correlation between the two Signal-operated services would reveal your identity. Unfortunately we, as users, have no way to know that this is not happening.

[1]: https://signal.org/blog/sealed-sender/

At the time of reception, the Signal server knew that there was a message from a certain IP to a certain recipient. If the message was put in the queue, the originating IP was forgotten. Once the message is delivered, the recipient is forgotten.

EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal. As neighbor comments have said it still knows at that moment that a message from you is sent.

> EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal.

For a centralized service like Signal, your IP doesn't matter, they own your account, literally. You can randomize it as much as you like, and your peers may too, in the end it will not hide from them who sent a message to whom and when.

Nope. As we already discussed, Signal has no idea who sent messages with Sealed Sender. The recipient finds out who sent them a message, but Signal does not.

> Signal has no idea who sent messages with Sealed Sender.

Sorry to deceive you, but "Sealed Sender" is just an empty promise.

Even if you could assess that this is indeed what is being done server-side (and you won't, because Moxie will neither let you, nor will ever federate his server with yours in case you wanted to run your own Signal instance), this does nothing against the fact that every message still enters and exits Signal's walled garden. No amount of indirection in the middle will change that. You are back to trusting all intermediaries' good faith (which extend beyond Signal, btw, Amazon also controlling every packet that enters/exits its cloud on which Signal runs).

> Sorry to deceive you

Deceive implies bad intent, which you are not doing in this case. What you are actually doing is educating whereas Signal is the one technically doing the deceiving.

It does know the recipient it doesn't know the sender. They call this "Sealed sender" and it is enabled by default for your friends (but you can change who gets this facility).

So instead of a message from Steve to tialaramex, it's just a message to tialaramex. Well, duh, of course tialaramex gets messages, why else have message software?

My Signal client prepared some "stamps" which are good for one message to me. It gave Steve (and all my friends, or maybe only Steve, or maybe everybody except one troll, Signal can't tell and doesn't want to know) some of the stamps when sending them other things, and so Signal just sees the message has a stamp on it, no need to know who sent it.

Your Signal client is at this moment logged into a Signal account on the Signal server. Sealed sender does nothing to protect against this - Signal knows that tialaramex is at that IP address.

The server fully aware where Steve is logged in from, and sees a message come from there to tialaramex. On top of even that: you then reply back, server sees a message going to Steve, going straight back to the IP address where it already knows he's logged in from.

Another thing people don't consider is that Signal's core server infra is hosted at AWS... so Amazon can also peek into both this network traffic and also dump out that it's your Signal account (ie. phone number) tied to that IP from the EC2 instance's memory.

These folks showed that this sealed sender stuff is broken last year: https://www.ndss-symposium.org/ndss-paper/improving-signals-... (and there's an acknowledgment from the Signal team on page 3 of the PDF).

You think you're making an argument against Signal, but you're in fact making the argument for it. The reason Signal deals in your phone number is precisely to keep them from managing databases of metadata about who's talking to who; the phone numbers keeps the social graph on the clientside.

Go look at RFC6121 Section 2 for one example of this. The point of Signal's design is that the server can't facilitate this kind of transaction, because it's unsafe for the server to keep that data in plaintext.

> Nobody show them Signal or their head might explode.

Most popular XMPP encryption is literally signalprotocol, so I'm pretty sure the community is aware :)

Hard to believe someone compares proprietary centralised silo service like Signal to an open federated protocol.

What would be your alternative? I agree there's a lot to research and improve in the XMPP ecosystem ( see also https://joinjabber.org/faqs/security/ ) but "admin in the middle" is not exactly a bug but a property of federated systems.

If your alternative is to use a centralized platform (which potentially requires a phone number to sign on) that's a trade-off i'm not willing to make. I'm personally very happy with my not-so-insecure pseudonymous communications (but always interested in constructive criticism).

> What would be your alternative?

A good starting point would be more balanced articles also talking about downsides or not-so-secure/-private defaults; not only in case of XMPP but in case of any instant messaging protocol or ecosystem.

Instead of claiming, "XYZ is secure because it supports TLS," articles should also mention what this means in terms of limitations (e.g., TLS protects data in transit, so server-side parties can still access the data) or defaults (e.g., only a subset of servers/clients support certain security features). While such things might be obvious to tech-savvy users, non-technical people don't understand this. They only read, "secure" and "private" and then assume, "Oh, it's secure and private, so I migrate to XYZ." In reality, "secure" and "private" aren't fixed states that you can identify by looking at some features.

XMPP leaks less metadata than alternative like Matrix, but it still very vulnerable to traffic correlation attacks from an external observer, server compromise and malicious server admin. Far from ideal.

Briar mitigates[1] these risks by using p2p messaging over Onion Services.

[1] mitigates: it's well known that even Tor cannot protect from correlation attack from a global observer but mounting such attack requires billions (see PRISM). Correlating traffic from/to an XMPP server is trivially easy for any person that has access to logs from a network device or can run a tcpdump on an hypervisor.

Traffic correlation attacks are very difficult to mitigate. Even Tor is not immune to this (see research such as [1], and the Tor project's own statements that the design is not resistant to analysis by a global network observer). Also Briar may be unsuitable for some use cases where you want to remain anonymous to people you communicate with[2].

Some research has been done into communication networks that are resistant to traffic analysis, such as Vuvuzela[3]. Unfortunately most such solutions requires permanent connectivity and bandwidth utilization, which makes them impractical for battery-powered mobile devices.

I'm firmly of the belief that no communication tool is suitable for all use-cases, but that we need to build open interoperable ecosystems that fulfil a range of needs, and help educate people about them.

[1]: https://nusenu.medium.com/the-growing-problem-of-malicious-r...

[2]: https://code.briarproject.org/briar/briar/-/wikis/FAQ#does-b...

[3]: https://vuvuzela.io/

tor isn't perfect, but if that's good-enough for your use-case, you can use/host a server over it: https://gist.github.com/dllud/a46d4a555e31dfeff6ad41dcf20729...

I already responded to your "admin in the middle" article here: https://news.ycombinator.com/item?id=29104983

I run my own XMPP server (Snikket) for my family, and I have no fear of the metadata it (I) can theoretically see if I run tcpdump. Snikket has a short retention period (7 days by default), and it uses end-to-end encryption for message contents and files.

It's much more important to me that I know where my data is - or rather, know where it isn't. I'd rather have that than be forced to entrust my metadata to a third party such as WhatsApp/Facebook, Telegram or Signal.

Disclaimer: I'm an XMPP developer (as I know you know, but others may not).

> I already responded to your "admin in the middle" article here

And we already responded here: https://news.ycombinator.com/item?id=29106376, and here: https://infosec-handbook.eu/news/2021-11-06-xmpp-aitm/, and somewhere on Reddit.

> I run my own XMPP server (Snikket) for my family

Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server? Can we agree that most non-technical XMPP users use a public XMPP server on the internet, where they might not know the individual or organization running the server? Where it remains unclear whether the XMPP server is set up and operated in a "secure" and "private" way? Where some XMPP server admins even fail to provide a privacy policy or try to hide their identity? Is this unique to XMPP? No, we never said this. Is this then a reason to ignore these issues? Also no. We should openly discuss pros and cons instead of highlighting isolated properties of a protocol that might be better in some situations than the same properties of a competitor.

> Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server?

Yes. The majority of people cannot, and will not ever, run their own server. However my ideal is that the remaining "10%" of people who can, do so. Just as I do for my non-technical family members. I believe that there should be a trust relationship between service operators and their users, whatever form that takes. I work daily to try and make self-hosting XMPP easy and accessible to more people, so we can increase this "10%" fraction.

For a similar perspective see: https://staltz.com/some-people-want-to-run-their-own-servers...

Of course using public XMPP services anonymously (burner accounts, randomly-generated username, connect via Tor/VPN, etc.) is a thing that many people also do, but I think that's a minority use-case (that should still be supported). Tools such as Briar also cover many such use-cases adequately or better.

You mention IP address, location based on IP addresses, timestamps, bytes transmitted and number of packets as metadata which is disclosed to the server admin. What alternative messenger do you suggest which does not disclose this metadata to the server operator?

> disclosed to the server admin

Please read the article before and after these items. The first finding isn't about the server admin but about external parties such as law enforcement (not the user, not the admin). The reason for this finding: Some people claim XMPP traffic can't be censored as nobody can identify XMPP traffic from outside. This isn't true as this finding shows. You can easily detect and filter XMPP coming through network devices.

This finding might be the most unsurprising one in the article from a technical perspective, and we are well aware of this.

XMPP supports additional security if the server and client support it, however some of the extension proposals (XEPs) are deferred or experimental. My hope that the Special Interest Group (SIG) for encryption pulls these together into new high-security client and high-security server profiles.

* https://xmpp.org/extensions/xep-0380.html - Explicit Message Encryption

* https://xmpp.org/extensions/xep-0429.html - Not a XEP really, but the formation of a SIG to explore a more robust end-to-end encryption support

* https://xmpp.org/extensions/xep-0420.html - Encrypting content specific to certain extensions

* https://xmpp.org/extensions/xep-0290.html - Digital signatures in XMPP

Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party.

Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.

Matrix supports encryption out-of-the-box without any strange key exchange problems. Most of the time the way key exchange is done in XMPP is very insecure.

> Most of the time the way key exchange is done in XMPP is very insecure.

How so?

> Most of the time the way key exchange is done in XMPP is very insecure.

We have OMEMO now, key exchange is paranoia-level secure.

How resistant to MITM is it though?

Currently, verification seems to work on a session basis and not just per user, which makes it very tedious to have everything verified e.g. a group chat. If it is not almost impossible given peoples sessions change with time.

Add a new session in the browser -> meet every contact to verify their sessions with your new browser session? Doesn't seem very practical, and reminds me of the old times in [matrix].

This opens room for MITM attacks

Security is always a tradeoff with convenience. How should a "per user" verification work in your opinion? A single master key that signs subkeys? Would the master key be secured with yet another password? What happens with already signed keys if a user loses access to the master key? Will I have to explain to my auntie over the phone that her master key password is somehow different to her account password and that it's very important she remembers both? Will I have to tell my uncle to sign his new key in the browser session with his master key that was generated on the phone and now has to be transmitted to the computer because it wasn't password protected and thus can't be stored on the providers server for syncing? When existing keys are used to sign new ones, what happens when the old one gets dropped? Will the conversation just break out of nowhere?

Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key.

In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident.

> This opens room for MITM attacks

Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.

> How should a "per user" verification work in your opinion?

The server could keep an append-only log of published keys, and then you could require m-of-n signatures of other published devices/keys to register a new one, in which case no further verification would be verifiable if you already trusted your peer's other keys. In addition, you could introduce peer keys in private rooms automatically and/or employ some form zero-knowledge proofs in public venues.

XEP-0450 Automated Trust Management is a first exploration in this direction. There a lot to explore and I only wished skilled cryptographers spent more time researching these issues on federated networks instead of advancing yet-another-centralized-messenger-of-the-month.

> Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that.

Also known as a keyserver. But you could also employ cryptographic challenges like OTR does, like a shared password to establish the session.

That sounds significantly more complex and worse than how Matrix just works out of the box.

Omemo just works out of the box as well. You don't have to check the key fingerprints, noone forces you to. For people who aren't interested the chat opens and they can start writing and sending, the encryption is completely transparent.

I wouldn't say that it's completely transparent, at least not when you use multiple clients (eg. a PC and a phone). I frequently get messages that some device cannot decrypt.

Why not do crosssigning like matrix?

> Matrix supports encryption out-of-the-box

that's not true for most clients, though (AFAICT, only riot works with itself).

I might even say that the situation is better/more sustainable in XMPP where more diverse implementations of the encryption protocol are available, with all mainstream clients supporting it: https://omemo.top/

FluffyChat and Syphon are doing pretty well. I don't think any of the clients are mainstream

Riot doesn't exist anymore. It's been Element for a while now

from https://github.com/movim/movim/issues/63

>"edhelas commented Nov 26, 2021

As OMEMO is now part of Movim master and that the main working features are working I'm considering this ticket as solved. There is still a lot of small things to fix but the main is done.

It took 6 years but Movim is finally having end to end encryptio edhelas commented Nov 26, 2021

As OMEMO is now part of Movim master and that the main working features are working I'm considering this ticket as solved. There is still a lot of small things to fix but the main is done.

It took 6 years but Movim is finally having end to end encryption."

Well, matrix does a lot of things different. A rewrite seems pretty unavoidable with hat many and significant changes

What's so different about it? Historically XMPP was more geared towards message-passing without server-side archival, but that ship has long since sailed to support multi-client. As it is, i don't see any significant change except for the consensus algorithm for decentralized rooms which could very well be an extension to the XMPP s2s protocol.

https://matrix.org/faq/#what-is-the-difference-between-matri...

Yes i understand that Matrix is a consensus-assembled JSON database. For the sake of argument, this could have been developed as an XMPP extension. In real life, you don't need or want a distributed consensus for simpler federated chat: it's been the cause of so many troubles across the Matrix ecosystem (room version incompatibilities, room takeovers due to netsplit, bad performance) that it's actually an argument against that building block. Except of course for censorship-resilient public rooms where it shines, which goes back to my point that "decentralized rooms" as an XMPP extension would have made sense.

room versions are incompatible naturally and room takeovers were a bug. So saying it's the cause for these things, is misleading.

At this time there are 9 room versions. Once the room version had to be incremented because of a bug in the consensus algorithm, which required a new algorithm, i.e. room version.

That's it. Bugs happen when you create new tech...

> Except of course for censorship-resilient public rooms where it shines, which goes back to my point that "decentralized rooms" as an XMPP extension would have made sense.

There are many more reasons for wanting decentralized rooms, e.g. autonomy, reliability, availability, anti-takeover - and it works for private rooms as well. Prospectively, it enables things like P2P and multi homing

I would never want to go back to the XMPP like it is today. And XMPP today is not Matrix, even if you could turn it to Matrix, but what is the point of doing that? Matrix is already there!

If you want Matrix to be an XMPP extension, I suggest creating a new XEP pointing to spec.matrix.org and call it XMPP v2. No idea what you would gain from it though.

XMPP and matrix solve related, but somewhat different problems. The Matrix approach is that everything is a stateful chatroom with history in which users can join or leave, while for XMPP there are only users (entities) which exchange objects that may or may not be text messages. It doesn't really care what happens after the fragments have been delivered.

It still would be nice if Matrix was built upon the existing Internet Standard for instant messaging.

How would it be even possible to build Matrix, as it is today, on XMPP?

And, more importantly, why would you want to do that? What would be the benefit if that was done?

The benefit would be that history would be kept and be viewable from different accounts. The problem would be that the history would have to be MITM'd on the matrix-xmpp-server-bridge because the encryption models aren't compatible. The server would need to manage omemo keys for the user and would thus need ultimate trust.

That's an issue with any cross-protocol accounts, and will only be solved the day something like MLS comes up.

XMPP has pubsub nodes, which in practice can be used as a general key-value datastore with a push when a key is updated. So it can be done, but at this point it will only be the same functionality with a different API. It doesn't make a lot of sense.

> How would it be even possible to build Matrix, as it is today, on XMPP? And, more importantly, why would you want to do that?

Glad you asked! There's two main components to Matrix: the client-to-server (c2s) and server-to-server (s2s) APIs.

The c2s API on matrix is of little to no value and could have been implemented as an HTTP API to XMPP servers: the way this is done in the XMPP ecosystem is with BOSH so we wrap the XMPP protocol inside an HTTP-based bidirectional stream, but there's no reason you can't make a "native" HTTP API for your XMPP server.

The s2s protocol is the interesting part of matrix because it has a genuinely-useful property of treating a room as a single state handled by a consensus of varied servers. The usual XMPP protocol MUC is ill-suited for that, but the "new" (~2015) MIX specification is based on a pubsub model very similar to Matrix and building a consensus algorithm on top of that would certainly not be harder than to develop an entirely new protocol from scratch.

Now as for why you would want to do that: to avoid fragmenting the ecosystem. XMPP was developed to address technical limitations of IRC, which is not an extensible protocol (does not use namespaced trees for messages) ; implementing a new feature in IRC is always at the risk of breaking clients and the IRCv3 working group spends a lot of time trying to work around that. XMPP was from the start conceived to be extensible and so there was little reason to reinvent a new protocol and software ecosystem just to add a single feature (decentralized rooms).

After all, matrix and XMPP have the exact same selling points (over a decade apart): federated and interoperable communications with bridges to 3rd party protocols. Now we have two protocols to address the same use-case, each with their up and downsides but certainly both further away from their goals than they would be if they mutualized efforts instead of reinventing the wheel. I have criticisms of XMPP just like i have criticisms of HTTP/HTML. But i personally do not understand the appeal to reinvent an entirely new markup language and browser/server ecosystem just because i'd like support for a new HTML element.

As someone who selfhosts Matrix and XMPP (thanks, Snikket!) I don't understand why Matrix is so terrifically burdensome to maintain if it is indeed competing. I've had three Matrix deployments all go wonky in various ways. I'm finally fed up with the Python implementation and hoping that the Rust implementation will solve all my woes.

XMPP clients running on a tiny VPS just feel very fast in comparison to Matrix clients running through a much larger VPS. Rooms still take ages to join whereas Snikket joins almost instantly. I've spent truly astounding amounts of time debugging Matrix's Postgres database, to video calls to Discord bridges. Snikket just keeps on ticking no matter what I throw at it.

It's starting to feel like the spec itself might be to blame but I welcome the input of experts, such as yourself.

Without too much difficulty. Just needed some XEPs. But matrix devs had a severe case of NIH syndrome.

Depending on when you last tried xmpp you might have experienced the OTR hell, which was never really codified 100% and spawned subtle incompatibilities between clients leading to weird and nondescript errors that never got addressed. Nowadays the popular clients support omemo (https://conversations.im/omemo/), which makes encryption just work™ out of the box and without hassle. The only exception to this is xabber, who are apparently afraid of law enforcement destroying their lifes should they implement proper encryption and also feel no need to support it anyways: https://github.com/redsolution/xabber-android/issues/540

> just work™

YMMV™

We have yet to manage not getting any OMEMO issues in a 2 users, 5 clients situation (2 Conversations on android, 1 Gajim on win, 2 Pidgin on linux)

If you care to elaborate, i'm sure that'll be of interest to maintainers. Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.

> Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.

Quality of Implementation matters. If Pidgin "doesn't exactly have the reputation" and yet it's still notionally part of your ecosystem, then your whole ecosystem doesn't exactly deserve the reputation you thought it did.

Here's my unsolicited recommendation: Block Pidgin. Not just Pidgin, any time the XMPP community finds itself having to explain that oops, that client doesn't work so good, please use a different one, just block the client, permanently instead, from all popular and well known servers, tell anybody who will listen that's not a real XMPP client, not any more.

Any time the community just can't bring itself to block a client, cross off the features that don't work across the ecosystem due to that client. Those aren't really XMPP features any more since they exist only for some users and the community is apparently OK with that.

And each year, stand back and look at the resulting two steps forward three steps back juddering "Progress" and reconsider - was this the way to get where you wanted to go? Or are you all wasting your time on an exercise that would be easier done a different way.

Since there is nothing one can do to identify a specific client, you cannot just block them. If they violate the spec that should be reason enough to consider them not real clients. I personally have no experience with pidgin and xmpp, but I can recommend https://dino.im for linux. It uses omemo by default and works like a charm.

Of course you can identify clients (although they could lie, it's just a user-agent string). You can even have nice graphs on some servers about it: https://stats.jabberfr.org/d/000000002/jabberfr?orgId=1&refr...

Pidgin is not listed as supporting OMEMO [0] and is not recommended for newcomers on joinjabber.org [1]. There may be reasons you want to use Pidgin and i don't want to block you: also pidgin is not exactly abandoned so there's hope it will continue to improve.

When a web browser fails to display a certain page, would you recommend the site operator to block it? Maybe we could allowlist specific clients and send a warning message to others just in case they're not aware they're using something niche.

[0] https://omemo.top/

[1] https://joinjabber.org/

the omemo support in pidgin is just through a plugin, as with many recent XEPs. i think people tend to forget that pidgin's focus is being a multi-protocol messenger. it ships with XMPP support, but that mostly includes the base.

i wrote that omemo plugin and tbh I am pretty burned out. so many moving parts, it's hell to debug and i'm not even sure where to go next with it. (plus people keep talking badly about pidgin anyway and i am not sure if it's even worth continuing.) i am very thankful for all the contributions so far, especially the help with packaging it. sorry if someone feels let down.

i feel like this is the right moment to ask: if anyone reading has an idea how to improve the state of things, i'd be happy about some suggestions. the project page is https://github.com/gkdr/lurch

> i think people tend to forget that pidgin's focus is being a multi-protocol messenger.

That's what's great about it and part of the reasons i think blocking Pidgin would be very wrong.

> i wrote that omemo plugin and tbh I am pretty burned out.

Thanks for that work! Maybe you could start by writing about your burnout on the README to encourage other people to contribute/maintain, or at least be less demanding of you?

> it's hell to debug and i'm not even sure where to go next with it.

Do you think this is specific to your plugin? To OMEMO? Or to pidgin plugins in general? Personally, i find it very challenging to write correct code in C, and i can only imagine the pains pidgin developers have to come through to make so many networks/protocols inteoperate. If you have some reading about your experiences, what lessons we can learn, and maybe some project (whether internal to pidgin or not) to implement them, i'd be interested to read.

> sorry if someone feels let down.

I don't think anyone feels really let down. Some people are not aware of just how experimental certain things are and so they get disappointed but life goes on. You however should take care of your mental health and not let maintenance burden and heartless cyber-ranters like me affect your mood and taste for computing <3

>Thanks for that work! Maybe you could start by writing about your burnout on the README to encourage other people to contribute/maintain, or at least be less demanding of you?

you're welcome! :D that sounds like a good idea, at least so people know i am not planning to abandon it even if i'm slow. i don't think people are demanding, i just feel bad that despite my best efforts it just doesn't work for some.

>Do you think this is specific to your plugin? To OMEMO? Or to pidgin plugins in general? Personally, i find it very challenging to write correct code in C, and i can only imagine the pains pidgin developers have to come through to make so many networks/protocols inteoperate.

in fact it's mostly related to your last point. there's just so many moving parts to this decentralized system: the os, installed libaries, exact version of the plugin, exact version of pidgin (or rather the underlying libpurple), the version of the used xmpp server, the version of the module implementing the XEP on the server, the version of the client on the other end, and how exactly that client implemented OMEMO and other XEPs in combination (e.g. the order of elements or their attributes in the received or sent xml).

right now there is a persistent bug that some omemo xml element cannot be parsed, and based on the input taken from the debug log i cannot reproduce it in unit tests, and i don't even know where to begin, and why it doesn't seem to affect other clients. also, persistent discovery issues that from my end don't look like a problem, and yet this plugin is the only one having these problems. i believe other clients must spam those discovery messages just in case, i didn't verify that yet though :)

>If you have some reading about your experiences, what lessons we can learn, and maybe some project (whether internal to pidgin or not) to implement them, i'd be interested to read.

i don't, but maybe i should write it down! venting in this reply already helped a lot, thank you :D

>I don't think anyone feels really let down. Some people are not aware of just how experimental certain things are and so they get disappointed but life goes on. You however should take care of your mental health and not let maintenance burden and heartless cyber-ranters like me affect your mood and taste for computing <3 aww, thank you! well, it's not like i don't get it, what i do can barely be called maintenance and libpurple's XMPP implementation isn't exactly modular, so you need to install 5+ plugins to get a "modern" messaging experience alone. i don't think i let some ranting get to me, don't worry about that! what i do feel bad for, aside from the people who are disappointed that it doesn't work, are the people who have actually contributed already, or were trying to contribute but i didn't look at the PRs in time and now the codebase just moved along too far.

i got some helpful lessons out of it either way, so i definitely don't regret it. a big part of it is what i already tried to say in my last post: i'm mostly not sure where to go with that project.

Having built upon your work and used it as a reference myself, I appreciate the effort dude :)

i'm glad to hear it was helpful to you! what kind of project did you make?

Not the OP, but I also keep running into issues with OMEMO. It's bad enough that I usually just disable it for all conversations.

My problem is that I'm using several clients (mostly profanity on several machines, occasionally dino) for the same account and it seems that my contacts keep forgetting some of my OMEMO keys, so I often receive messages that some of my clients can't decrypt and I have to start multiple machines just to find one that can decrypt the message.

So far I haven't figured out how to debug this.

XMPP is based on XML exchange so opening the XML debugger of your client should answer all your questions. Notably, if your server replies with an incomplete list of keys, it may be that a client of yours overwrote the list dismissing previous keys? Just a wild guess, but don't hesitate to drop by XMPP chatrooms if you need help debugging that one!

Pidgin maintainer here... I would love to hear what you mean by this...

Hello, sorry i don't mean to be rude, i'm only judging by reputation. I heard from various hearsay that the codebase is in shambles and full of security holes, and i know for sure despite being one of the top3 most popular XMPP client OMEMO encryption is still not fully supported more than 5 years after the first spec was published (2015).

This is why some security-oriented distros such as Tails are looking for Pidgin replacements (Pidgin is arguably the widest attack surface for Tails RCE), and why in most public channels i hang around in people recommend to stay away from Pidgin if you're looking for an XMPP client that supports "modern" extensions.

Personally, i have a lot of admiration for Pidgin as a concept but i can only imagine how hard it is to interoperate with so many networks in a memory-unsafe language. I wish the situation keeps on improving thanks to devoted people like you and i'm interested if you have some more detailed reads (blogposts, issues) about the future of Pidgin or other such multi-network clients.

Thanks for your hard work and take care!

Perhaps the real distinguishing factor of Matrix isn't its technology, but its governance. Instead of an extensible, plugin-based approach like XMPP, Matrix has just a single "official" spec that can only be extended by amending the spec itself. IIRC this was one of the motivations behind Matrix's inception.

As to whether one approach is better than the other is left as an exercise to the reader :) But having each approach belong to separate projects allows them to carry on as they see fit, and means they don't have to participate in a zero-sum game.

Most things in matrix are namespaced. The official spec namespace is 'm', as in 'm.text', but you can extend it very liberally by just adding keys like 'com.github.mr_johnson22.matrix.foo'

It angers me so much when my browser tries to connect to a port other than 80 or 443 and the firewall pops up [0] and even more if I decline the request and it keeps popping up because the page doesn't understand that I don't want to accept this.

Other than that, I absolutely love XMPP. It's the platform my servers and applications use to inform me of events, and with Conversations [1] there's a really nice Android app as a client.

[0] https://matrix.cactus.chat:8448/_matrix/client/r0/register?k...

[1] https://conversations.im/

I'm not going to say that you can't build a secure messaging system with XMPP, but you should be skeptical of any analysis that suggests that XMPP is secure because it uses TLS, and "engineers are working on E2EE to add even more security". The security you get from TLS in these systems is not meaningful, and by the "it uses TLS" definition, virtually every messaging system is "secure".

> The security you get from TLS in these systems is not meaningful

I don't like that phrasing, because it suggests that having TLS is equally good than not having TLS.

Otherwise, you are right.

On XMPP, encryption is optional and not even the default.

I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it.

> I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it.

Which are they? Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)?

Federated and P2P networks are the only true alternatives for the privacy/security conscious.

> On XMPP, encryption is optional and not even the default.

OMEMO encryption is widespread/practically universal these days. You are pretty much guaranteed to be able to establish an E2EE session would it not be the default for any reason.

>Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)?

No. Matrix and Tox come to mind.

Agreed about Matrix and Tox qualifying (not being centralized).

I can't vouch for Tox from a security standpoint (haven't looked at the details), but I can guarantee that it's not ready for widespread use (esp. on mobile where P2P messaging still needs a breakthrough).

Matrix is fine. In my biased opinion, it's just XMPP with more steps, more overhead and a less diverse ecosystem. Also, its security story is no better than XMPP so it's funny that we came to that from "XMPP, encryption is optional and not even the default", where that's practically truer for Matrix than it is for XMPP.

It is very unlikely to recommend anyone products with default end to end encryption.

Few people really need that, as proven by Telegram: it became by far more popular and usable over their competition precisely because unlike whatsapp you can log in on any device and have your chat history right there, with all your endless pictures! And users love that.

You just can't do that on WhatsApp or Viber precisely because of end to end encryption and the necessity to drag the keys along everywhere and have problems adding new devices.

It's time to end this "E2EE must be everywhere" propaganda promoted by privacy-ticked nerds. Real encryption either greatly reduces UX, or it is a security theater. Security chats should be an option, when you need to have a really secret conversation. Most chats don't need that at all.

How about XMPP performance on low-performance networks like mobile ones?

I believe poor networking performance was one of the reasons XMPP had to be customised in WhatsApp and overall didn't become as widely used as I'd like it to be :)

Is it still the case? Or was that problem addressed at standard level somehow?

Some extensions like XEP-0352 Client State Indication have been developed to fit the mobile world. XMPP on mobile is nowadays very reliable, except for iOS preventing 3rd party notifications.

That is a situation documented by people years ago, and has been wrong for years. See https://gultsch.de/xmpp_2016.html. Unfortunately the legend lives on because "it doesn't work" is a better soundbite than "it works"

I first started using XMPP heavily in 2014 when I was thru-hiking the Appalachian Trail. Much of the trail has extremely limited cell coverage (even if you can get Edge some of the towers are so bad you can literally only get a few bytes per second). I evaluated several different protocols and apps for communication with family, and XMPP beat them all hands down every time. The long lived TCP connections meant that once a connection was established I could keep it up and it would sit there slurping up the bits as it came. That experience later led me to get involved with the community and even write a spec about using XMPP on high-latency low-bandwidth networks.

It may have been bad at this at one time, I don't know, but at least since I've been using it's been fantastic with poor network quality, I suspect the people saying otherwise are just repeating something they learned in the early 2000s that's no longer true.

XMPP is routinely used on HF radio and SATCOM networks field-deployed by militaries. It's deployed with channel compression (so the links themselves are compressed), but it routinely operates down to way way below mobile. In general, the really bad links are used for federation (s2s) rather than client connections which demand lower latency for user interaction. I've personally watched it operate on HF radio modems down to single-figure bits per second - those are simplex links with a 30 second turnaround. It's slow of course, but it does work - and this is on the base standard. Any server can do this, there's three I know of in use.

WhatsApp decided, at some point in the past, that XML was too verbose and compressed it using a technique borrowed from WAP - essentially a fixed-dictionary compression. Newer WhatsApp systems don't ever bother decompressing to XML, and it's likely it can't be anymore, but it's fundamentally the same traffic patterns even now. Your WhatsApp account still has a jid (with a very short, fake domain) and so do your groupchats (also a very short fake domain). The WAP compression choice was unfortunate, as it only really had an effect back in GPRS/EDGE days, only on certain networks, and only on certain traffic patterns, because it's the number of packets that matter in most cases, not the number of bytes. There'd still be some rare benefit on 3G, but by 4G the benefit had all gone.

Meanwhile, clients like Siskin and Conversations work just fine on modern mobiles. Conversations (an Android client) does work better when given permissions to keep the sessions live rather than rely on push notifications, but testing has consistently shown that battery life in unaffected. There's a number of extensions that are widely deployed that help efficiency, for sure, and I'd not want to run without for preference - though it is possible, and not as bad as you'd think.

So I'd say that XMPP has no performance problems at all on "long thin" networks way beyond mobile.

To get the same performance out of anything based on HTTP, you need to recode to use the parallel protocols of CoAP and friends. Matrix have done this, but it means specialist clients and servers are needed, and as far as I'm aware there's only a single implementation.

As a former XMPP fan, I think XMPP is extremely interesting in light of Moxie's recent web3 post [1], and most specifically the part:

> A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year.

You could replace email with XMPP in that sentence. (In fact, I'd bet Moxie was specifically thinking of XMPP when he wrote that.)

I remember when Google introduced voice/video, and provided a library (libjingle) to help other clients add the feature. It never really got picked up. Perhaps it was the state of the driver ecosystem at the time that made it hard for clients to reliably support such streams (PulseAudio was still new at the time, and GStreamer wasn't as mature), that was in excess of what open-source maintainers could provide.

Google eventually decided (reasonably, in retrospect and IMHO) it was easier to turn its chat into its own platform than try and drag a protocol with it. They were certainly dealing with problems that no-one else did. For example, they were very late to enable federation, much to the annoyance of the community, because Google had to deal with spam at a scale no-one else did, and wanted to make sure they had the protocols to deal with that, which no-one else in the community wanted to deal with.

(Of course after that I cannot give Google any credit for their chat client merry-go-round, and they've burned any goodwill I had for them on that front! [2] )

Perhaps we'll reach a point where the feature-set for a chat client will settle, and once again a federated protocol can emerge. I no longer believe XMPP is it.

[1] https://moxie.org/2022/01/07/web3-first-impressions.html

[2] https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...

Edit: that said, I think XMPP had a lot of great ideas, and I'm glad it still pops up now and again.

A particular subset of the XMPP story I want to share is that back in the mid-00's, the XMPP folks were trying to make it the protocol of the real-time web. I think that was a laudable goal.

One thing they particularly feared was for the web to become HTTP-only, with all the overhead that entails.

How prescient.

I'd bet he was thinking of this whole back and forth (blog posts, conference talk) with Matrix: https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom

The story of E2EE on Matrix seems like a pure vindication of Moxie's concerns about protocol ecosystems, since it took years for them to get from an E2EE design everyone agreed on and that was working in clients to a point where they could default that E2EE on for users, because of popular straggler clients.

No, the reason why it took from 2016 to 2020 to turn on E2EE by default in Matrix was because we wanted to get UX parity with unencrypted in Element before we turned it on by default. It had absolutely nothing to do with straggler clients, popular or otherwise.

XMPP is many thing, but I doubt it could be described as secure. Yes it has SASL auth, TLS and you can run it on an intranet, but thats not the same as secure.

XMPP has had e2ee for years. What are your criterias for calling it not secure ?

XMPP is as secure as Signal nowadays, it implements the same encryption scheme and is still completely federated: https://conversations.im/omemo/

Omemo is a relatively recent effort though and many people still remember the days when gpg and otr where the sad state of the art in the xmpp world.

XMPP leaves a lot of metadata and user information around, so it does have a privacy issue that's probably not solvable. Whether it's a security issue is a completely different discussion though.

That's got nothing to do with the security problems OP complained about though. Are there even working solutions to those metadata problems apart from sending dummy decoy messages and purposeful delays on the server side to make correlating message relaying hard?

The metadata leaks are more about correlating pseudonymous identities to the same accounts than network leaks (for which we employ VPN/SSH tunnels or Tor). If you'd like to know more about the threat model of XMPP: https://joinjabber.org/faqs/security/ (critique welcome)

> XMPP is as secure as Signal nowadays, it implements the same encryption scheme

Signal enforces E2EE, you can't disable it. If XMPP supports E2EE depends on the XMPP clients and servers, so it isn't enforced and can be disabled. Server admins can even inject XMPP messages that look like coming from the legitimate sender. This is far from "secure as Signal."

> Server admins can even inject XMPP messages that look like coming from the legitimate sender.

How should that be possible if OMEMO is enabled (which is the default in more modern clients)?

> How should that be possible if OMEMO is enabled (which is the default in more modern clients)?

See https://infosec-handbook.eu/articles/xmpp-aitm/#t5

TL;DR: XMPP clients can't distinguish between legitimate and injected messages, even if OMEMO is enabled. The XMPP client just displays injected messages as an unencrypted message from the sender.

In Conversations unauthenticated messages are displayed with a red background, whereas OMEMO authenticated messages are displayed in green. They do not look the same.

Nobody claimed that they look the same.

As mentioned in the linked article, the behavior upon receiving an injected message is client specific. In any way, the injected message is somehow presented to the (non-technical) user who might then be targeted. We all know the same problem exists in the e-mail world.

Signal operators can also inject messages to people. So this is a strange comparison.

What holds true in both systems is that if someone does this, it's detectable thanks to E2EE. Which is the entire point of E2EE.

> Signal operators can also inject messages to people.

Did you check this, and can you demonstrate a server-side message injection so that the Signal clients display the injected message correctly, leaving the recipient vulnerable to spoofed messages? Would be nice to see for the security community.

> What holds true in both systems is that if someone does this, it's detectable thanks to E2EE.

What also holds true: One system enforces E2EE; for the other system E2EE is optional, depends on the client, and while spoofing could be detected thanks to E2EE, all clients we checked didn't detect it (Gajim, Conversations, Psi+, Profanity).

If you start with an argument 'non trusted server admin can do things to my xmpp', it's strange that you don't apply same logic to Signal admins, who control the server and ship an app to you which you can't really verify.

> If you start with an argument ..., it's strange that you don't apply same logic to Signal admins

Where is this 1-to-1 comparison you demand in the OP's original article?

Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Signal wins as these security features aren't optional but enforced and more mature.

Privacy: This section in OP's article addresses distinct things to then somehow claim XMPP is private. Let's compare them:

XMPP is an open standard -> Doesn't this apply to Signal, too? Some developers claim not to track users -> Same applies to Signal. OMEMO adds security -> explained above, already in Signal. Decentralized -> The first difference, and here we can write another article on why decentralization doesn't magically add any security or privacy. Users can choose a username, doesn't need phone number -> Second difference, which doesn't apply to all XMPP clients as some may require your phone number, and if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number. User may not be identifiable -> Another vague statement without any explanation that we can just assume the same way for Signal. Presence status shared with others (without mentioning that server admins can see this, too) -> Signal comes without this feature. Only nicknames exposed in MUCs (again without mentioning what MUC admins and server admins see) -> Signal lets users decide if they want to share their phone number and username with groups. User is the only one deciding about/controlling their account and personal data (how can this be ensured if this data is exposed to the server and other users) -> Again a vague statement without any explanation. So Signal users can also decide about their data.

Then, OP's article suddenly ends without going into any details. The article finishes with "phone numbers, centralization bad; username, decentralization good." This isn't balanced at all.

> Signal admins, who control the server and ship an app to you which you can't really verify.

If we write exactly the same about XMPP, people immediately state, "XMPP clients and servers are open source, everybody can look at their code." So let's apply the same logic to Signal. If you don't want to apply this logic, then yes, we can't also verify if we connect to a malicious/manipulated XMPP server even if its source code is open. The same applies to apps. And Reproducible builds don't come with this guarantee, too.

> XMPP is an open standard -> Doesn't this apply to Signal, too?

The Signal protocol is neither an open (you cannot propose changes or extensions in an open process) nor has it been submitted to an standards body.

> Some developers claim not to track users.

With Signal you have to trust a single entity not to track you. With XMPP you have the freedom to choose that entity (including choosing yourself).

> if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number

This is just dishonest. It's a lot harder to obtain a non-identifiable phone number than to think of a random username.

> The Signal protocol is neither an open (you cannot propose changes or extensions in an open process) nor has it been submitted to an standards body.

Who defines "open standard" in the first place? There is no global definition for this.

> With Signal ... With XMPP ...

Another person just claimed comparing both is silly. There are already other comments addressing the rest of your statement.

> non-identifiable phone number ... random username

You compare distinct properties in your own statement. "non-identifiable" isn't the same as "random". If you want to get a random phone number, you can just buy any SIM card. Is this nitpicking? Maybe, but nitpicking is also including in dozens of "XMPP is better than Signal" statements in the comment section. There are already other comments addressing the rest of your statement.

> Who defines "open standard" in the first place?

Most people on here would say: https://en.wikipedia.org/wiki/Internet_Engineering_Task_Forc...

I'm arguing with your comments, not the article. Comparing Signal with XMPP is silly. It's like saying 'Firefox is more secure than XML'.

Signal is a product, XMPP is a protocol. That said, XMPP can be potentially used to build communication products that are far more secure than Signal because of a simple virtue of being able to control all components of a service instead of relying on someone else to run a server for you.

And no, this is not the same as verifying the code of Signal, because with your custom XMPP deployment you need to verify your code once, and not worry about the server admin adversary, while on Signal you will have to verify updates every single time.

> Comparing Signal with XMPP is silly.

Could you please add your statement to any other comments by XMPP proponents that state "XMPP is better than Signal because ..."?

Plus, could you also consider this for all of your own comparisons of XMPP and Signal?

> XMPP can be potentially used

Again, a lot of guessing and assumptions what could be in a perfect XMPP world, but nobody finds nowadays.

> with your custom XMPP deployment

This isn't a unique property of XMPP.

> Again, a lot of guessing and assumptions what could be in a perfect XMPP world, but nobody finds nowadays.

The German police and British health service would say that their XMPP implementations are pretty secure implementations:

- https://twitter.com/inputmice/status/1203611711967813633

- https://hellopando.com/ / https://www.erlang-solutions.com/case-studies/pando-health-c...

> XMPP is an open standard -> Doesn't this apply to Signal, too?

Signal is the opposite of an open-standard, there's a single server implementation and basically three clients (Android, iOS, desktop) and they discourage people from using other clients. Best way to think about Signal is that it's just WhatsApp with some marketing on top.

Meanwhile, I can link a raspberry pi anywhere in the world to my XMPP server with a few lines of Python and some libraries.

> Some developers claim not to track users -> Same applies to Signal.

Both cannot be verified by the users, but as an admin, I can verify that my server isn't tracking users.

> Decentralized -> The first difference, and here we can write another article on why decentralization doesn't magically add any security or privacy.

It does certainly help not to have all of your eggs in a centralized basket, both in terms of privacy and reliability.

> Users can choose a username, doesn't need phone number -> Second difference, which doesn't apply to all XMPP clients as some may require your phone number

Do not know of a single XMPP client that requires a phone number - some random server out there, maybe.

> and if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number. User may not be identifiable -> Another vague statement without any explanation that we can just assume the same way for Signal.

You'll find most people will tell you that you need ID these days to get a SIM card. Creating a new XMPP account takes less than 5 seconds.

> Presence status shared with others (without mentioning that server admins can see this, too) -> Signal comes without this feature.

The user can disable these, personally I find them useful on my server and miss it sometimes when I use Signal.

> Only nicknames exposed in MUCs (again without mentioning what MUC admins and server admins see) -> Signal lets users decide if they want to share their phone number and username with groups.

Signal doesn't, all phone numbers of group members are visible to people within the group.

> Do not know of a single XMPP client that requires a phone number

Here is the only one I know: https://quicksy.im/

Yes, Quicksy from the Conversations developer who bragged about copying main features of WhatsApp and Signal.

Another one is Kontalk, https://www.kontalk.org/.

Both XMPP clients require a phone number, and both present the phone number as a benefit in comparison with other XMPP clients without this requirement.

It's a trade-off. If you are unwilling to provide a phone number you can choose any other XMPP provider and still can communicate with friends who use Quicksy/Kontalk. You simply don't have this freedom if you use WhatsApp or Signal.

> I can link a raspberry pi anywhere in the world to my XMPP server with a few lines of Python and some libraries.

Once again, "I, as a tech-savvy person, can operate my highly-customized XMPP setup everywhere", while ignoring that most people do not run their own servers.

> they discourage people from using other clients

This was discussed numerous times various platforms and proven wrong.

> I can verify that my server isn't tracking users

As discussed before on this page, most XMPP users don't run their own XMPP server but use a public XMPP server on the internet. Nobody can check whether this public XMPP server tracks its users without accessing the server itself.

> all of your eggs in a centralized basket, both in terms of privacy and reliability.

So, do you assume the Signal network infrastructure consists of a single server?

> Do not know of a single XMPP client that requires a phone number

At least Quicksy (from the Conversations developer who bragged in a public video about copying WhatsApp/Signal) and Kontalk require a phone number. They even market the phone number requirement as a benefit in comparison with other XMPP clients.

> most people will tell you

I could just claim the opposite. Without any sources, it remains an assumption.

> Signal doesn't

Signal does. You wrote, you use Signal. Did you ever join a Signal group? There is a dialog when entering a group the first time.

> Once again, "I, as a tech-savvy person, can operate my highly-customized XMPP setup everywhere", while ignoring that most people do not run their own servers.

I said "my server", but the exact same code could be pointed at a different server by simply changing the username/password. Compare this to having to port a codebase from Signal to WhatsApp/Slack/whatever.

I'm also just using a standard ejabberd-based deployment, nothing highly-customized about it. Have you tried a Signal server deployment? I have, and THAT is the definition of highly-customized.

> This was discussed numerous times various platforms and proven wrong.

Alternative clients exist, but they are heavily frowned upon by the community - as a lot of the functionality they add (disappearing messages, view once media) depend on people using the official clients and not custom ones that could simply ignore this functionality.

> As discussed before on this page, most XMPP users don't run their own XMPP server but use a public XMPP server on the internet. Nobody can check whether this public XMPP server tracks its users without accessing the server itself.

That's fine, same thing applies to Matrix/Signal/WhatsApp/pretty much any messaging service out there.

> So, do you assume the Signal network infrastructure consists of a single server?

Functionally - although it is clustered - it is a single server, run by a single team - and it has gone down multiple times in the past few years.

And when it does go down: good luck using that Signal client to talk to anyone over it (SMS doesn't count as it has zero security on Signal and isn't even available on the iOS client). At least with XMPP, I can point the same client to some other server and potentially continue a conversation with someone somewhere else, with the exact same OMEMO/PGP encryption.

That is why decentralized/federated is better than "all your eggs in one basket" centralized. Centralization provides one with convenience, right up until it stops working and then it becomes a massive inconvenience.

> At least Quicksy (from the Conversations developer who bragged in a public video about copying WhatsApp/Signal) and Kontalk require a phone number.

The whole point of Quicksy is to allow people to try XMPP and find contacts easily with their number before they then move on to using actual JID-based accounts.

And he's more than free to brag about what he does - he's the one that spent the time; writing code and extensions and then released the thing to the public as free and open-source code.

> Signal does. You wrote, you use Signal. Did you ever join a Signal group? There is a dialog when entering a group the first time.

This is your Signal PROFILE name, not a username. You can quite clearly see this described in Settings -> tap the top bit with your number and read the text at the bottom.

People can still see your phone number by simply clicking on your user in the group member list. Signal, at the current time[0], has zero username functionality.

[0]: https://twitter.com/moxie/status/1480643863970816001

Just one question as the rest was discussed numerous times before:

> At least with XMPP, I can point the same client to some other server and potentially continue a conversation with someone somewhere else, with the exact same OMEMO/PGP encryption.

How do you just "continue a conversation with someone somewhere else" when your XMPP server goes down?

Typically, you register an XMPP account on an XMPP server. If this server is offline, your account is unreachable as the account is managed by the XMPP server not by your client. Therefore, you can't use this account anymore. So you need to go to another XMPP server, register a new XMPP account, and then try to find your contacts again (which may be cached by your client or not). Finally, you have to convince "someone" that this is just you with another account on another server. There is also no verified E2EE anymore. If "someone" uses the same now-offline XMPP server, "someone" also needs to find another XMPP server.

How is this different from "when Signal goes down one uses a completely different instant messaging system", apart from using another client?

> That is why decentralized/federated is better

And we already explained (also several times) that XMPP is de-facto centralized as the vast majority of users only use a tiny number of XMPP servers hosted by an even smaller number of hosting companies. Which means: If one of these hosting companies blocks XMPP traffic (e.g., if a rogue state starts censoring) or one of these XMPP servers goes down, a huge part of XMPP users is affected.

> then try to find your contacts again (which may be cached by your client or not)

You can save XMPP account IDs in any mobile address book.

> Finally, you have to convince "someone" that this is just you with another account on another server. There is also no verified E2EE anymore.

I'd pretty much just do a video call at that point.

> How is this different from "when Signal goes down one uses a completely different instant messaging system", apart from using another client?

You don't have to use another client software.

> Which means: If one of these hosting companies blocks XMPP traffic (e.g., if a rogue state starts censoring) or one of these XMPP servers goes down, a huge part of XMPP users is affected.

Equally applies to most messaging apps out there. Some XMPP apps have the benefit of also supporting using Tor and hidden services - Signal/WhatsApp/etc, don't.

Don't want to use the Internet at all and your friends live close by? You can even go wild and do something like:

- https://github.com/ddamianus/Lora-Chat-Device

- https://github.com/jgoerzen/ax25xmpp

I realize this is something most people would not do, but XMPP's _flexibility_ allows this to be an option if it was something people wanted. Can't do Signal over LoRa.

> You can save XMPP account IDs in any mobile address book.

... while the rest of the XMPP account remains on the XMPP server, inaccessible. There is no benefit as you can also store other primary IDs like phone numbers in your address book.

And the rest comes down to "continue a conversation with someone somewhere else" isn't so easy but the same pain as with any other messaging system, minus you may use the same XMPP client, plus you may need to search a while until you find an XMPP server that comes with the fitting XEPs for your use cases.

> Signal enforces E2EE, you can't disable it.

Exactly!

It seems like there is a combination of tenuous assertions being made about XMPP security here, followed by naive questions from people who apparently don't understand the basic feature set of something like Signal. Any clue why this is happening?

XMPP is about choice.

I use OMEMO everywhere. However, I do know of people out there who simply do not see the point of OMEMO as, when they are the server admin, OMEMO adds no value over TLS. OMEMO also doesn't make sense in large public groups, cause you're not going to go and verify 100+ people's encryption keys one by one.

OMEMO and end-to-end encryption are also incompatible with keeping a reliable server-side archive of your messages - which will be accessible to all future XMPP clients that you add to your account - which apparently some people want. You can see this at the table at https://conversations.im/omemo/

Meanwhile, you occasionally find people on the Signal subreddit bemoaning that they lost their entire message history with a loved one because some backup file got corrupted and failed to restore or; they lost some device. Here's an example: https://www.reddit.com/r/signal/comments/rbtdtb/

As I said: XMPP is about choice.

Signal admins too can ship you an app version that would show injected messages like coming from legitimate sender. [1]

However, while you can be your own xmpp server admin, you can't be Signal admin.

[1]: And for god's sake pls don't even start on reproducible builds, nobody really verifies every app updates.

You just wrote it is "silly" to compare XMPP with Signal while constantly doing it yourself.

> Signal admins too can ship you an app

Or I could just use my own Signal client since it is open-source and there are several working forks such as https://molly.im/. How do "Signal admins" (whoever this is) manipulate these open-source forks?

Instead of providing any proof or details, you just post one assumption after another to distract from obvious problems with current XMPP servers and clients. As soon as we debunk a myth, the next assumption comes up.

Thanks for the article! Just to nitpick:

> Moreover, the protocol has been audited by a third party.

Some implementations have been audited, unfortunately far from all! There's a lot of things to audit and/or improve related to privacy and security in the XMPP ecosystem: i would personally recommend to read this FAQ: https://joinjabber.org/faqs/security/

> Also, on this page, you can track the progress of OMEMO integration in XMPP clients (applications)

This is true, but based on estimated progress not something measured by a test suite. For example poezio is marked 100% but i keep having OMEMO problems with it (not blaming the poor poezio-omemo maintainer who's working on it alone mostly).

> Only the nickname is displayed if you participate in a group chat or a channel (here, the XMPP extension called MUC, the acronym for Multi-User Chat, is used).

Except for the room operators! The MUC server admins have access to all addresses, as well as room admins. Also, some rooms are public in which case everyone can read everyone's address (like a mailing list).

Was waiting for this after two top posts about IRC.

I am not seeing the value in discussing privacy at the protocol level. Sure I share what I want to share with the other party but that is not where the privacy violations occur. The host of the service (like FB) will suck up all data and use it to mine info on me. That is where the leak is.

I can't even convince security professionals to install Signal, let alone something that requires installing a specific client configuration that may not be identical across platforms. If it's not e2ee by default I'd rather just stick to my current social graph.

XMPP is dead and I'm very happy about that.

The only people who still use XMPP in a significant capacity are the likes of Nintendo (for the Switch push notifications system) and it is pretty out of reach for any average citizen.

XMPP as a protocol for engineering and science is fantastic. As a set of standards it's well designed. Performant, flexible, and powerful. As a general, average Joe software however it fucking sucks big time. And it is precisely this flexibility that makes it suck. It's not just flexible, it's a mess. And mobile support in 2021 is atrocious.

There's a reason why Telegram's very shitty protocol is vastly more popular for average Joes than XMPP ever was.

XMPP was designed by engineers, for engineers. Which is good for this very specific set of engineering problems and essentially useless for everyone else.

Want secure communication? Use Signal, Threema, hell even Telegram is more secure in its default canonical protocol implementations than XMPP. And stop beating the dead horse XMPP is.

> XMPP is dead and I'm very happy about that.

Quoted this on XMPP for the irony.

> And mobile support in 2021 is atrocious.

I'm curious to hear of any specific mobile issues you are aware of. Most of our customers use XMPP exclusively from mobile and I have not heard complaints so far, but it's only been 5 years so far...

How can accounts be distributed? What would prevent impersonation?

Same as the rest of the modern internet, XMPP relies on the DNS network. Your account is basically `nick@service.tld`, just like email.

Isn't that Jabber? Haven't heard of XMPP in a while.

It's the same thing! XMPP usually refers to the protocol and Jabber the open federation, but since Cisco acquired the Jabber trademark some people have been reluctant to use that name.

And some people think a protocol name is irrelevant and would rather build a consistent product based on open standards: https://snikket.org/blog/products-vs-protocols/

It's trivially easy to log messages and content on an xmpp server. It's not a secure protocol at all, just because it uses tls in transport.

Reply on news.ycombinator.com