XMPP vs. Matrix
I want to know everybody’s opinion on what’s better to use today, XMPP, or the Matrix protocol? Maybe also what’s easier to convert your friends and family to.
87 comments
In order to answer this question it is important to understand the fundamental difference between XMPP and Matrix.
XMPP was invented at a time, where communicating online meant sending a message from one device to another.
However, the modern expectations for messaging apps are much more than that. Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats, threads, and even managing communities are all things a modern messenger app should be able to do. The fundamental operating principle has shifted from mere message passing to synchronising a common state between all participants. If you think about it, nowadays, you're not chatting anymore. You're essentially collaboratively editing a shared chat history file, where the most common action is to add a message; usually at the bottom.
This is what Matrix is at its core. It's a protocol to synchronise state, and that's part of why Matrix is so complex and hard to administrate. I personally think its the better base for the future of communication than XMPP, and I havent even mentioned encryption yet.
Moving on to the practical part: Running a Matrix Synapse server is quite a commitment, but if all you want is talk to friends and family, then there are simpler options. Conduit and Dendrite are a bit easier to set up, and of course there are plenty of public homeservers you could sign up with.
If you do commit to running Synapse however, you have the option to install bridges to almost any other messaging service. This way, your friends and family can keep using what they're used to (WhatsApp, Telegram, Discord, Facebook, ...), and you just use one single Matrix client to talk to all of them.
That's what I do.
XMPP was invented at a time, where communicating online meant sending a message from one device to another.
However, the modern expectations for messaging apps are much more than that. Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats, threads, and even managing communities are all things a modern messenger app should be able to do. The fundamental operating principle has shifted from mere message passing to synchronising a common state between all participants. If you think about it, nowadays, you're not chatting anymore. You're essentially collaboratively editing a shared chat history file, where the most common action is to add a message; usually at the bottom.
This is what Matrix is at its core. It's a protocol to synchronise state, and that's part of why Matrix is so complex and hard to administrate. I personally think its the better base for the future of communication than XMPP, and I havent even mentioned encryption yet.
Moving on to the practical part: Running a Matrix Synapse server is quite a commitment, but if all you want is talk to friends and family, then there are simpler options. Conduit and Dendrite are a bit easier to set up, and of course there are plenty of public homeservers you could sign up with.
If you do commit to running Synapse however, you have the option to install bridges to almost any other messaging service. This way, your friends and family can keep using what they're used to (WhatsApp, Telegram, Discord, Facebook, ...), and you just use one single Matrix client to talk to all of them.
That's what I do.
Disclaimer: I'm an XMPP server developer and work on [MongooseIM](https://github.com/esl/MongooseIM).
> XMPP was invented at a time, where communicating online meant sending a message from one device to another. However, the modern expectations for messaging apps are much more than that. Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats, threads, and even managing communities are all things a modern messenger app should be able to do.
XMPP provides all of these features and manages to keep up with commercial products really well. Everything Slack or Discord offer is there in the XMPP protocol. And if it wasn't, it could be relatively easily added, thanks to it being extensible.
However, navigating the protocol and software supporting it requires a little bit of know-how. If the OP is interested in building a product incorporating instant messaging and the satellite features, I'd suggest partnering up with somebody with this know-how. Scalable servers would be MongooseIM or ejabberd, polished clients are Conversations or Movim.
If it's a question about which protocol to use for a homeserver, then maybe something focused on ease of setup would work best, like Prosody.
> The fundamental operating principle has shifted from mere message passing to synchronising a common state between all participants.
So it should all be based on blockchain, shouldn't it? ;)
> XMPP was invented at a time, where communicating online meant sending a message from one device to another. However, the modern expectations for messaging apps are much more than that. Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats, threads, and even managing communities are all things a modern messenger app should be able to do.
XMPP provides all of these features and manages to keep up with commercial products really well. Everything Slack or Discord offer is there in the XMPP protocol. And if it wasn't, it could be relatively easily added, thanks to it being extensible.
However, navigating the protocol and software supporting it requires a little bit of know-how. If the OP is interested in building a product incorporating instant messaging and the satellite features, I'd suggest partnering up with somebody with this know-how. Scalable servers would be MongooseIM or ejabberd, polished clients are Conversations or Movim.
If it's a question about which protocol to use for a homeserver, then maybe something focused on ease of setup would work best, like Prosody.
> The fundamental operating principle has shifted from mere message passing to synchronising a common state between all participants.
So it should all be based on blockchain, shouldn't it? ;)
I was an xmpp user back in the early 2000s and hosted a few instances myself. I think it would be an interesting experiment to leave xml behind and start using something like yaml to reduce message overhead. Never got far enough to implement it myself, though.
There used to be a "security-focused" project that configured easily XMPP projects but I don't recall its name. Last time I checked it was dead.
Conversations is Android (and maybe iOS) only, right? I still use gajim (not pidgin).
I miss the old gajim, before they redesigned it to look like every other multi-user chat instead of one optimized for 1-1 messaging :(
For those who still like the classic style of messengers, Psi [1] offers an old-school, extremely customisable interface, and is still actively maintained. It integrates nicely with all the desktop platforms as well.
[1] https://psi-im.org/
[1] https://psi-im.org/
Kinda. The normal version hasn’t seen a release in 4 years, only the experimental psi+ version is maintained, and it is unclear which features it actually supports as all (at least in the wiki in English) information is heavily outdated.
I agree, that takes me back. I miss a lot of old things. Some things haven't changed though, I still use irssi in XTerm!
Modern XMPP clients have all of those: Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats.
Your comment makes it seem like they don't.
Your comment makes it seem like they don't.
A lot of the features you mention were already there in XMPP 20 years ago. I've lost track of the standard a long time ago but I assume the rest have been added through extensions.
Synapse isn't as heavy as it used to be.
It's quite lite and very stable, I would pick it over any other server, matrix has issues as it is, you don't want to add compatibility issues to the mix.
[deleted]
> Running a Matrix Synapse server is quite a commitment
Commitment in what way? I found it fairly easily to set it up with a domain of my own.
Commitment in what way? I found it fairly easily to set it up with a domain of my own.
Maybe it’s gotten a ton better but a couple years back setting up and managing the whole stack had a “shitty on purpose so you pay for hosting” vibe. I noped out in a hurry—and I’ve built and managed some comms-related stuff that ought to be an order of magnitude more fiddly than just running a Matrix server.
Dealing with stuff like running a state compressor regularly, manually removing records it bails on. Also having fast enough resources to handle situations like someone joining the Matrix HQ channel (it's the biggest one) and pulling in like 70GB of database bloat. I hit a bug a month or two back where sliding-sync (the new protocol Element X uses) was causing huge amounts of database bloat, they fixed it but my instance was running something like 200GB on a server with less than 10 people.
This ansible playbook helps a lot but it's still periodic annoying maintenance and it's still way more resource intensive than it should be: https://github.com/spantaleev/matrix-docker-ansible-deploy
EDIT: I run it on a hetzner dedi, I have run it on Apple fusion drives in the past and consumer SSD's and it was a terrible time. Need high IOPS so things don't grind to a halt on intensive db operations (like joining HQ channel lol)
This ansible playbook helps a lot but it's still periodic annoying maintenance and it's still way more resource intensive than it should be: https://github.com/spantaleev/matrix-docker-ansible-deploy
EDIT: I run it on a hetzner dedi, I have run it on Apple fusion drives in the past and consumer SSD's and it was a terrible time. Need high IOPS so things don't grind to a halt on intensive db operations (like joining HQ channel lol)
I should have omitted the "I found it fairly easily to set it up with a domain of my own." part, because I do like the answers to the question, those are the sort of answers I was hoping for, so thank you.
the matrix server where i have my account, run by a small tech community with one admin recently had to switch from a blacklist to a whitelist approach in order to curb the amount of fake accounts and spam they were getting. as a side effect since that change i had to bother the admin multiple times because one of the groups i was participating in was not reachable. the amount of work the admin has in order to keep the server im shape is much more than i would be willing to tolerate.
on top of that not a month goes by where something doesn't break.
a security conscious friend who joined matrix because of me (well, he was interested before, but i finally gave him a reason) just deleted his matrix clients in disgust after some messages randomly could not be decrypted.
i suspect that there is still a problem on the server i am using, therefore more potential work for its already overworked admin.
on top of that not a month goes by where something doesn't break.
a security conscious friend who joined matrix because of me (well, he was interested before, but i finally gave him a reason) just deleted his matrix clients in disgust after some messages randomly could not be decrypted.
i suspect that there is still a problem on the server i am using, therefore more potential work for its already overworked admin.
Sounds like git + a file format
It's apples vs oranges. I selfhost and use both, ejabberd / conversations for xmpp and synapse / element for matrix.
XMPP is traditional IM. I use it exclusively from Conversations client on Android / GrapheneOS and it is really instant, supports presence (knowing whether contact is actually online), rings for audio and video calls, gives feedback about whether user read the message etc. I use it mostly for 1:1 conversations, it has all but replaced SMS and phonecalls.
I consider matrix more like 'fast forum'. Perhaps things changed but last I checked (from element on Android / GrapheneOS) there was no presence so I have no idea whether contact will get my message immediately or not. No confirmation that contact read the message. Audio and video calls not working, not even ringing when phone is locked. Quite laggy in message delivery.
So, after some years of using both, XMPP is best for replacing one-to-one SMS, video and audio calls, while I enjoy hanging in public matrix rooms, treating them like '(not really) instant forums'.
XMPP is traditional IM. I use it exclusively from Conversations client on Android / GrapheneOS and it is really instant, supports presence (knowing whether contact is actually online), rings for audio and video calls, gives feedback about whether user read the message etc. I use it mostly for 1:1 conversations, it has all but replaced SMS and phonecalls.
I consider matrix more like 'fast forum'. Perhaps things changed but last I checked (from element on Android / GrapheneOS) there was no presence so I have no idea whether contact will get my message immediately or not. No confirmation that contact read the message. Audio and video calls not working, not even ringing when phone is locked. Quite laggy in message delivery.
So, after some years of using both, XMPP is best for replacing one-to-one SMS, video and audio calls, while I enjoy hanging in public matrix rooms, treating them like '(not really) instant forums'.
Matrix has presence but not all public servers enable it.
https://spec.matrix.org/v1.11/client-server-api/#presence
https://spec.matrix.org/v1.11/client-server-api/#presence
I went from hosting XMPP to Matrix and then XMPP again in the last 10 years.
- I'm now sure that I will never convert anyone to Matrix or host a Matrix server again.
- Matrix big issues for me are that it's not really decentralized and this design impacts the server admin, the performances and the user's privacy.
- I'm still not happy with XMPP clients for Linux, most are missing Omemo or automatic turn/stun discovery and Dino is in in alpha and bugged.
- I'm sur that XMPP will have a community in 20 years, not sure about Matrix.
- I'm now sure that I will never convert anyone to Matrix or host a Matrix server again.
- Matrix big issues for me are that it's not really decentralized and this design impacts the server admin, the performances and the user's privacy.
- I'm still not happy with XMPP clients for Linux, most are missing Omemo or automatic turn/stun discovery and Dino is in in alpha and bugged.
- I'm sur that XMPP will have a community in 20 years, not sure about Matrix.
Could you elaborate your points?
I'm particularly interested in "Matrix isn't really decentralized" and on which XMPP client you're using on Linux.
Thanks!
Thanks!
I'm not the parent, but I use both XMPP and Matrix, and have some thoughts to both of these.
> Matrix isn't really decentralized
I think most of the concerns stem from the majority of the development in the ecosystem being driven by a single company. This manifests in a few ways:
matrix.org is by far the biggest server. Element is by far the most popular client. Both were (until recently) maintained by the same company, and the client selects matrix.org as the default server. This was done to make onboarding easier, but it centralised power into one organisation.
Theoretically, since Element does most of the development, if they want to push something into the protocol, the whole ecosystem really has to follow.
Because most people are on matrix.org, and the protocol works by replicating state between involved servers, matrix.org gets a lot of metadata even from conversations that are not hosted on their server (as long as one person in the chat is on matrix.org).
There are some flags which are enabled by default which automatically "phone home" to matrix.org even when you are running your own server. They are easy to turn off, but an annoyance for people who want to run completely separated instances.
The standard way to join a chat is via a "matrix.to" link. This leaks some information to matrix.org even if the server is completely separate.
By contrast, XMPP has no dominant player who drives most of the development, and no dominant server instance. I imagine this is because the protocol has been around for much longer (so there is more time for things to settle), and there is a very clear separation between the standards body and the software developers. There are popular clients that have some influence over the ecosystem, but nowhere near the extent as in Matrix.
Now, XMPP has its problems too, but few of these stem from having too much centralisation.
> which XMPP client you're using on Linux
I personally use Dino (https://dino.im/). It offers a simple, clean experience, and looks really nice.
There are also more fully-featured clients, like Gajim (https://gajim.org/)
> Matrix isn't really decentralized
I think most of the concerns stem from the majority of the development in the ecosystem being driven by a single company. This manifests in a few ways:
matrix.org is by far the biggest server. Element is by far the most popular client. Both were (until recently) maintained by the same company, and the client selects matrix.org as the default server. This was done to make onboarding easier, but it centralised power into one organisation.
Theoretically, since Element does most of the development, if they want to push something into the protocol, the whole ecosystem really has to follow.
Because most people are on matrix.org, and the protocol works by replicating state between involved servers, matrix.org gets a lot of metadata even from conversations that are not hosted on their server (as long as one person in the chat is on matrix.org).
There are some flags which are enabled by default which automatically "phone home" to matrix.org even when you are running your own server. They are easy to turn off, but an annoyance for people who want to run completely separated instances.
The standard way to join a chat is via a "matrix.to" link. This leaks some information to matrix.org even if the server is completely separate.
By contrast, XMPP has no dominant player who drives most of the development, and no dominant server instance. I imagine this is because the protocol has been around for much longer (so there is more time for things to settle), and there is a very clear separation between the standards body and the software developers. There are popular clients that have some influence over the ecosystem, but nowhere near the extent as in Matrix.
Now, XMPP has its problems too, but few of these stem from having too much centralisation.
> which XMPP client you're using on Linux
I personally use Dino (https://dino.im/). It offers a simple, clean experience, and looks really nice.
There are also more fully-featured clients, like Gajim (https://gajim.org/)
Care to explain what information is leaked via the matrix.to link and how it could be improved?
using matrix.to means:
* the webserver hosting matrix.to can see your browser’s IP and user agent as it connects to it. (this could be improved by connecting to matrix.to via an overlay network of some kind, or simply using matrix URIs instead)
* it cannot see the room/user being linked to, as this is deliberately hidden in a url fragment from the server
* it cannot see details about the room/user being linked to (eg the icon or room name); it optionally lets the client chose to grab this from a given homeserver, but the service itself never sees this data.
In other words, it was written with privacy in mind.
* the webserver hosting matrix.to can see your browser’s IP and user agent as it connects to it. (this could be improved by connecting to matrix.to via an overlay network of some kind, or simply using matrix URIs instead)
* it cannot see the room/user being linked to, as this is deliberately hidden in a url fragment from the server
* it cannot see details about the room/user being linked to (eg the icon or room name); it optionally lets the client chose to grab this from a given homeserver, but the service itself never sees this data.
In other words, it was written with privacy in mind.
same, would like to learn more!
I use XMPP and then Cheogram for people who don't want to figure it out.
That way for people who don't care everything just works and for people who do they get a rich experience with E2EE. Unlike eg iOS/imessage I don't force them to use a different OS for this and I can talk to everyone from my laptop. Everything is 100% self hostable.
I don't know why you would use Matrix. Self hosting is awful, the clients are a huge mess, and it was bootstraped by the Israel based company that runs US telephone surveillance (it's kind of insane that's done in another country.)
That way for people who don't care everything just works and for people who do they get a rich experience with E2EE. Unlike eg iOS/imessage I don't force them to use a different OS for this and I can talk to everyone from my laptop. Everything is 100% self hostable.
I don't know why you would use Matrix. Self hosting is awful, the clients are a huge mess, and it was bootstraped by the Israel based company that runs US telephone surveillance (it's kind of insane that's done in another country.)
> it was bootstraped by the Israel based company that runs US telephone surveillance
That argument, again.
It's been some 7 years since Amdocs withdrew all funding, forcing the devs to create their own independent thing. Since then, as far as I'm aware, the protocol has been developed in the open, with lots of external contributors. There's plenty of implementations, both client and server. How are its roots relevant? Are you going to say the internet is dubious because it was initially researched on by the US military?
Anyway, your other points are relevant, though it would be nice to have some more details.
That argument, again.
It's been some 7 years since Amdocs withdrew all funding, forcing the devs to create their own independent thing. Since then, as far as I'm aware, the protocol has been developed in the open, with lots of external contributors. There's plenty of implementations, both client and server. How are its roots relevant? Are you going to say the internet is dubious because it was initially researched on by the US military?
Anyway, your other points are relevant, though it would be nice to have some more details.
People certainly bring that up when they talk about TOR.
My friends and I all selfhost own matrix homeservers and we use it to chat.
It works reasonably well, but stil the administrative work required should not be underestimated, comparable to selfhosting e-mail.
Regarding features, matrix is promising and definitly innovative, but espacially the mobile apps don't have the same level of usability like WhatsApp or novel features like Telegram. Techsavvy friends can definitly use it, but you don't want to become a managed service provider for your broader family.
I use this ansible playbook to provision my server and related services (monitoring, bridges, ...) [0].
The bridges espacially make it fun to play around with.
[0] https://github.com/spantaleev/matrix-docker-ansible-deploy
Regarding features, matrix is promising and definitly innovative, but espacially the mobile apps don't have the same level of usability like WhatsApp or novel features like Telegram. Techsavvy friends can definitly use it, but you don't want to become a managed service provider for your broader family.
I use this ansible playbook to provision my server and related services (monitoring, bridges, ...) [0].
The bridges espacially make it fun to play around with.
[0] https://github.com/spantaleev/matrix-docker-ansible-deploy
Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ recently.
It's quite critical of some of the code quality of common implementations as well as the fracturing across different clients.
As for Matrix, probably element is the main client you want to use. I use Nheko on Linux.
It's quite critical of some of the code quality of common implementations as well as the fracturing across different clients.
As for Matrix, probably element is the main client you want to use. I use Nheko on Linux.
I have criticized omemo in the past -- it breaks backwards compatibility way too readily resulting in XMPP clients not being able to talk to each other in levels that I hadn't seen since the Jingle debacles. However I just can't stand this article's tone (the accompanying imagery doesn't help), and then he has the balls to complain about the rude response he gets from the spec authors (even showing it off as if to elicit empathy from the reader), when if anything my impression is that his article itself is way more disrespectful.
He keeps criticizing one client while trying to pass it off as criticism of the specification (said client doesn't even implement the latest version of the specification, either), complains about the protocol changing too much and the protocol changing too little, and to top it off seems to promote Signal as the better alternative, completely missing the elephant in the room -- Signal being centralized with its decisions even more whimsical at the hands of one group only. Curiously, he does that right after criticizing omemo's choice to follow Signal's choices as lacking justification.
He keeps criticizing one client while trying to pass it off as criticism of the specification (said client doesn't even implement the latest version of the specification, either), complains about the protocol changing too much and the protocol changing too little, and to top it off seems to promote Signal as the better alternative, completely missing the elephant in the room -- Signal being centralized with its decisions even more whimsical at the hands of one group only. Curiously, he does that right after criticizing omemo's choice to follow Signal's choices as lacking justification.
This sort of rant is unfortunately fairly common in the world of cryptography. Things can be mostly driven by what the writer feels about other people working in the same space. So they attack their technology as a way to attack them.
Note that the author of the linked article complains about getting the same sort of article in reply. That is also common...
Note that the author of the linked article complains about getting the same sort of article in reply. That is also common...
The main reason we won't list it on privacyguides.org is the encryption is not always on by default.
There are two major problems, the implementations and the fact the spec isn't specific. I'm not particularly bothered by the imaginary, the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things.
As for the reply from the spec author, I had a negative opinion of that. To me it looks like they just tried to copy signal's encryption so that people could claim that XMPP has E2EE, without any real design or thought of the implementation.
One of the other things I hate about XMPP (and you mentioned it above with the jingle debacle), but there are other cases where there's multiple XEPs for the same thing. Some of them are widely used despite being marked as "experimental". The documents are not cohesive and is a mess which is probably why the implementations are also bad (unlike the Matrix spec). Encryption is just another one of those things, just like file transfer.
If I was deciding on a new project to develop a client for XMPP would be the least attractive project for me to work on. Put it that way. Without enthusiastic developers that think this thing sounds cool there simply won't be any good software.
The other thing also not mentioned is that the OMEMO encryption only applies to text messages and not all the other things, ie VOIP, status changes etc.
There is a fair bit of metadata on the server side
https://web.archive.org/web/20211215132539/https://infosec-h...
and attacks like this are just downright scary
https://notes.valdikss.org.ru/jabber.ru-mitm/
I used to use XMPP but haven't in about a decade. Nobody I know uses it either. (Even the couple of evangelists I knew moved to Matrix long ago)
There are two major problems, the implementations and the fact the spec isn't specific. I'm not particularly bothered by the imaginary, the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things.
As for the reply from the spec author, I had a negative opinion of that. To me it looks like they just tried to copy signal's encryption so that people could claim that XMPP has E2EE, without any real design or thought of the implementation.
One of the other things I hate about XMPP (and you mentioned it above with the jingle debacle), but there are other cases where there's multiple XEPs for the same thing. Some of them are widely used despite being marked as "experimental". The documents are not cohesive and is a mess which is probably why the implementations are also bad (unlike the Matrix spec). Encryption is just another one of those things, just like file transfer.
If I was deciding on a new project to develop a client for XMPP would be the least attractive project for me to work on. Put it that way. Without enthusiastic developers that think this thing sounds cool there simply won't be any good software.
The other thing also not mentioned is that the OMEMO encryption only applies to text messages and not all the other things, ie VOIP, status changes etc.
There is a fair bit of metadata on the server side
https://web.archive.org/web/20211215132539/https://infosec-h...
and attacks like this are just downright scary
https://notes.valdikss.org.ru/jabber.ru-mitm/
I used to use XMPP but haven't in about a decade. Nobody I know uses it either. (Even the couple of evangelists I knew moved to Matrix long ago)
>and attacks like this are just downright scary
https://notes.valdikss.org.ru/jabber.ru-mitm/
That attack strikes me as generic. As in not anything to do with XMPP specifically.
https://notes.valdikss.org.ru/jabber.ru-mitm/
That attack strikes me as generic. As in not anything to do with XMPP specifically.
> the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things.
Lighten things? Are you saying that putting images of cartoon characters puking at the logos of your product lightens things and provokes healthy discussion? Don't try to make this into thinking I'm criticizing furriness -- it's definitely not about that.
> There is a fair bit of metadata on the server side
This is much less critical when the protocol is federated. Even E2EE itself may become second priority rather than first in such an environment.
> Without enthusiastic developers that think this thing sounds cool there simply won't be any good software.
This is a ridiculous statement.
Lighten things? Are you saying that putting images of cartoon characters puking at the logos of your product lightens things and provokes healthy discussion? Don't try to make this into thinking I'm criticizing furriness -- it's definitely not about that.
> There is a fair bit of metadata on the server side
This is much less critical when the protocol is federated. Even E2EE itself may become second priority rather than first in such an environment.
> Without enthusiastic developers that think this thing sounds cool there simply won't be any good software.
This is a ridiculous statement.
> Are you saying that putting images of cartoon characters puking at the logos of your product lightens things and provokes healthy discussion?
The image in question does not contain puking. That's a tongue, not vomit.
https://bunnypa.ws/sticker/CAACAgEAAxUAAWByYjqChwgli1QKv81yw...
Here's another from the same artist: https://bunnypa.ws/sticker/CAACAgEAAxUAAV91eRTulCrBXcKzxCrPY...
It contains a disgusted reaction. The logos in question are visually "muddying the waters", too.
The image in question does not contain puking. That's a tongue, not vomit.
https://bunnypa.ws/sticker/CAACAgEAAxUAAWByYjqChwgli1QKv81yw...
Here's another from the same artist: https://bunnypa.ws/sticker/CAACAgEAAxUAAV91eRTulCrBXcKzxCrPY...
It contains a disgusted reaction. The logos in question are visually "muddying the waters", too.
> This is much less critical when the protocol is federated
False. Federated protocols typically have a lot more, as there is routing data between servers. The same goes for things like Matrix.
The only thing that Matrix servers can see however realistically is the room id, and other participants. Unlike XMPP where they can copy your roster. In the case of ejabberd debug logs can include your password lol (or at least could in November 2021). I doubt that's changed.
False. Federated protocols typically have a lot more, as there is routing data between servers. The same goes for things like Matrix.
The only thing that Matrix servers can see however realistically is the room id, and other participants. Unlike XMPP where they can copy your roster. In the case of ejabberd debug logs can include your password lol (or at least could in November 2021). I doubt that's changed.
Routing data between servers and networks you literally control. There is simply no possible discussion on this point. A centralized service doesn't allow that choice. Leaking metadata to a centralized service is simply inevitable by pure physics.
> Routing data between servers and networks you literally control
This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting.
TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population.
> Leaking metadata to a centralized service is simply inevitable by pure physics
Not necessarily true https://signal.org/blog/sealed-sender/
Signal has a lot less metadata than XMPP.
This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting.
TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population.
> Leaking metadata to a centralized service is simply inevitable by pure physics
Not necessarily true https://signal.org/blog/sealed-sender/
Signal has a lot less metadata than XMPP.
https://simplex.chat/ has lesser metadata than Signal[1][2], Matrix and XMPP. SimpleX Chat is going to move to Groups V2[3] very soon to make the experience much better.
[1]: https://www.ndss-symposium.org/ndss-paper/improving-signals-...
[2]: https://arxiv.org/abs/2305.09799
[3]: https://github.com/simplex-chat/simplex-chat/issues/4620#iss...
[1]: https://www.ndss-symposium.org/ndss-paper/improving-signals-...
[2]: https://arxiv.org/abs/2305.09799
[3]: https://github.com/simplex-chat/simplex-chat/issues/4620#iss...
SimpleX looks really interesting. Will have to read on it. Seems somewhat like "magic", is there any gotcha?
See "We plan to add:"
https://github.com/simplex-chat/simplex-chat?tab=readme-ov-f...
but the first 2 points were already implemented as shown in their Roadmap[1], so they are going to probably remove them
[1]: https://github.com/simplex-chat/simplex-chat?tab=readme-ov-f...
https://github.com/simplex-chat/simplex-chat?tab=readme-ov-f...
but the first 2 points were already implemented as shown in their Roadmap[1], so they are going to probably remove them
[1]: https://github.com/simplex-chat/simplex-chat?tab=readme-ov-f...
XMPP largest deployments are in enterprises. I do not disagree with this. To go from there to "it is not designed to be a private protocol" is a stretch. And does that invalidate any of my points?
> Not necessarily true https://signal.org/blog/sealed-sender/
Yeah, no. Timing alone is enough to clearly distinguish a sender, and any attempts like these is pure astronaut engineering to obfuscate something that is trivial to recover by a million side channels.
There is just No. Way. to eliminate the problem of metadata leaks to a centralized server, other than making it practically distributed/P2P. The more time it takes for people to realize this, the worse society becomes.
> Not necessarily true https://signal.org/blog/sealed-sender/
Yeah, no. Timing alone is enough to clearly distinguish a sender, and any attempts like these is pure astronaut engineering to obfuscate something that is trivial to recover by a million side channels.
There is just No. Way. to eliminate the problem of metadata leaks to a centralized server, other than making it practically distributed/P2P. The more time it takes for people to realize this, the worse society becomes.
> And does that invalidate any of my point
Yes it does, because the threat model there is not the server itself. You trust that as it's your employer's server and you're using it for work related purposes.
> Timing alone is enough to clearly distinguish a sender
It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol.
Yes it does, because the threat model there is not the server itself. You trust that as it's your employer's server and you're using it for work related purposes.
> Timing alone is enough to clearly distinguish a sender
It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol.
> You trust that as it's your employer's server and you're using it for work related purposes.
Yes, that is the point. Or it is my home server sitting at my router serving my family. I have been arguing that if I can trust the server then the discussion about E2EE becomes less relevant.
> It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol.
And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it.
Yes, that is the point. Or it is my home server sitting at my router serving my family. I have been arguing that if I can trust the server then the discussion about E2EE becomes less relevant.
> It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol.
And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it.
> Or it is my home server sitting at my router serving my family.
That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet.
For a lot of people it wouldn't even be possible if they wanted to and that's not getting into the technical investment they would have to make in knowing how to do such a thing in the first place.
> And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it.
It's a lot easier than simply not having that data server side in the first place like Signal for example.
That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet.
For a lot of people it wouldn't even be possible if they wanted to and that's not getting into the technical investment they would have to make in knowing how to do such a thing in the first place.
> And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it.
It's a lot easier than simply not having that data server side in the first place like Signal for example.
> That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet.
Frankly, that works for the majority of XMPP users -- let's not forget about that. But yes, this is a problem today for many consumers. However, I see this as a much better direction for the Internet as a whole to take -- see efforts such as ownCloud and the like -- , rather than just conceding defeat and accepting a centralized Internet, or worse: the extremely dangerous idea that centralization increases security. Which should only be seen as the non-sense it is.
> It's a lot easier than simply not having that data server side in the first place like Signal for example.
You still do not get the point here at all. This is not about storage. This is not about the server implementation. As long as there is a communication at all between me and the server and then my contacts and the server, it is irrelevant if you are storing the roster or not. ANYONE (*anyone with access to that server) can easily pick it up. In fact, it is HARD not to leak it up, even by accident. Barring a P2P Freenet-like thing, this is _unavoidable_. (and even with P2P/Freenet/Onion/whatever it's not trivial) And due to the nature of IMs, metadata is practically as big an issue than protecting the payload itself.
Frankly, that works for the majority of XMPP users -- let's not forget about that. But yes, this is a problem today for many consumers. However, I see this as a much better direction for the Internet as a whole to take -- see efforts such as ownCloud and the like -- , rather than just conceding defeat and accepting a centralized Internet, or worse: the extremely dangerous idea that centralization increases security. Which should only be seen as the non-sense it is.
> It's a lot easier than simply not having that data server side in the first place like Signal for example.
You still do not get the point here at all. This is not about storage. This is not about the server implementation. As long as there is a communication at all between me and the server and then my contacts and the server, it is irrelevant if you are storing the roster or not. ANYONE (*anyone with access to that server) can easily pick it up. In fact, it is HARD not to leak it up, even by accident. Barring a P2P Freenet-like thing, this is _unavoidable_. (and even with P2P/Freenet/Onion/whatever it's not trivial) And due to the nature of IMs, metadata is practically as big an issue than protecting the payload itself.
> and attacks like this are just downright scary
> https://notes.valdikss.org.ru/jabber.ru-mitm/
With an up to date Conversations on a modern server we have a pretty good chance to detect or prevent that style of attack due to a mechanism called SASL Channel Binding.
> https://notes.valdikss.org.ru/jabber.ru-mitm/
With an up to date Conversations on a modern server we have a pretty good chance to detect or prevent that style of attack due to a mechanism called SASL Channel Binding.
While it's true OMEMO isn't used for voice and video, that's because voice and video are already e2ee with the more appropriate srtp
solid points!
> He keeps criticizing one client while trying to pass it off as criticism of the specification
Can you point out where this happens? I didn't come away with this impression at all.
Can you point out where this happens? I didn't come away with this impression at all.
> Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ recently.
Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.
Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.
>> "But there is a lot of FUD if not outright lies in that blog post. "
For example...
For example...
* Conversations uses two different OpenPGP implementations. (It doesn’t)
* The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely
* ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool)
* ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
* The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely
* ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool)
* ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
> * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202.
Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway.
"Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202.
Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway.
"Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Off-the-shelf verifier don’t have support for that.
I run Prosody XMPP server on a cheap VPS, and appreciate how it's a stock Debian package, greatly simplifying security updates. It's delightfully lightweight on the server.
I use Conversations as a client in Android, and Gajim in Linux.
The basics like OMEMO, file attachments, push-to-talk voice memos (in Conversations, but not Gajim) work well. All comms are at least client-to-server-encrypted, and the OMEMO-protected comms are end-to-end encrypted.
I use Conversations as a client in Android, and Gajim in Linux.
The basics like OMEMO, file attachments, push-to-talk voice memos (in Conversations, but not Gajim) work well. All comms are at least client-to-server-encrypted, and the OMEMO-protected comms are end-to-end encrypted.
actually, push-to-talk voice memos do work Gajim. An underrated feature!
Prosody allows voice and video calls - I have a TURN server all set up with it - but QOS rules (which are beyond my control, and are the fault of the ISPs I use) can sometimes squash calls made.
Gajim 1.9.3 (Flatpak) seems support voice and video calls to Conversations, but then it doesn't work. One Conversations smartphone can make voice and video calls to another Conversations smartphone.
Prosody allows voice and video calls - I have a TURN server all set up with it - but QOS rules (which are beyond my control, and are the fault of the ISPs I use) can sometimes squash calls made.
Gajim 1.9.3 (Flatpak) seems support voice and video calls to Conversations, but then it doesn't work. One Conversations smartphone can make voice and video calls to another Conversations smartphone.
XMPP + OMEMO (E2E encryption), no doubt. Open standards, multiple implementations, cross-platform and it mostly just works. Light on the server, "maintenance-free". Conversations on Android, Gajim or Dino-IM on desktop.
I tried Matrix but found it to be more complicated without adding significant functionality.
I tried Matrix but found it to be more complicated without adding significant functionality.
> more complicated without adding significant functionality
This simply is untrue. Having first class E2EE that covers VOIP and all features (eg Matrix, Signal etc) like that is obviously a benefit.
Essentially you can't "use Matrix/Signal wrong" and realize later your communications weren't E2EE, you certainly can with XMPP.
This simply is untrue. Having first class E2EE that covers VOIP and all features (eg Matrix, Signal etc) like that is obviously a benefit.
Essentially you can't "use Matrix/Signal wrong" and realize later your communications weren't E2EE, you certainly can with XMPP.
While that's certainly the plan, Matrix is still not at the "can't use it wrong" stage Signal has gotten to. Verifying multiple devices is still inconsistent and often requires multiple tries (may be an issue with the matrix.org server, dunno) and "Unable to decrypt" errors are still somewhat a common sight.
It has gotten much better in recent times, but not quite there just yet.
It has gotten much better in recent times, but not quite there just yet.
I'd say you're taking the problem backwards. Your friends and family will follow you probably because you ask them, rather than because of any intrinstic feature of the protocol.
So the real question is which one do you want to use?
In terms of server software, XMPP is lighter, easier to manage and scales better.
In terms of protocol, the Matrix protocol has an immense metadata problem. While encryption is sound, the metadata carried with every message is as good as plaintext. XMPP meanwhile provides pseudonymous rooms and minimal metadata leakage.
In terms of direction, I trust the XMPP foundation more. The Vector foundation comes from a multinational and is clearly a startup. I don't think anything good can come from the tight coupling between Vector and Matrix, no matter how much Matthew tries.
Vector also relicensed Element under a CLU (Contributor License Agreement). For me, it's a sword of Damocles.
In terms of community, it's pretty personal but I don't like the people on Matrix at all. The XMPP users seem more friendly. Your mileage may vary though. It may also not matter if you only want to talk to your already existing friends.
However, the best XMPP client is beautiful like the face of a dying man, and just as easy to use. Matrix is way ahead on client design.
So the real question is which one do you want to use?
In terms of server software, XMPP is lighter, easier to manage and scales better.
In terms of protocol, the Matrix protocol has an immense metadata problem. While encryption is sound, the metadata carried with every message is as good as plaintext. XMPP meanwhile provides pseudonymous rooms and minimal metadata leakage.
In terms of direction, I trust the XMPP foundation more. The Vector foundation comes from a multinational and is clearly a startup. I don't think anything good can come from the tight coupling between Vector and Matrix, no matter how much Matthew tries.
Vector also relicensed Element under a CLU (Contributor License Agreement). For me, it's a sword of Damocles.
In terms of community, it's pretty personal but I don't like the people on Matrix at all. The XMPP users seem more friendly. Your mileage may vary though. It may also not matter if you only want to talk to your already existing friends.
However, the best XMPP client is beautiful like the face of a dying man, and just as easy to use. Matrix is way ahead on client design.
> Maybe also what’s easier to convert your friends and family to.
You will need to pick a client that you can recommend to your friends and family, because they likely won't bother to look one up. If they are non-technical, then the client is what matters most for them and you need to decide what makes the most sense given their circumstances.
On the matrix side I can recommend Element (https://element.io/) which has a lot of eye candy. I'm not sure what to recommend for XMPP.
You also need to pick a server for them, because again, they won't bother to choose one themselves. If you can, host a XMPP or matrix server yourself!
You will need to pick a client that you can recommend to your friends and family, because they likely won't bother to look one up. If they are non-technical, then the client is what matters most for them and you need to decide what makes the most sense given their circumstances.
On the matrix side I can recommend Element (https://element.io/) which has a lot of eye candy. I'm not sure what to recommend for XMPP.
You also need to pick a server for them, because again, they won't bother to choose one themselves. If you can, host a XMPP or matrix server yourself!
Matrix if any of your friends and family are on iOS. As much as I'd like for XMPP to be more popular, only Android has a decent client. Element is far from perfect, but its shortcomings are platform-agnostic.
Have you tried Monal on iOS? It has made the iOS experience a lot better recently.
I'm curious if anyone has a setup for emacs for either of these that supports audio/video calls. Emacs seems to have basic support for text chats on both protocols, but I wish I could use XMPP JMP.chat as my phone from Emacs and initiate video calls from Emacs as well. Is there some kind of audio/video server protocol analog to the language server protocol that let's plaintext and command line enthusiasts talk to each other without having to open that giant insecure web browser thing or a monolithic chat client?
My own experience is a two years old, but interoperability seemed not to work great. Messages frequently disappeared and all that.
As long as you stayed on the same instance everything was dandy, but writing to someone one the matrix homeserver worked most of the time.
Matrix as a protocol is more exciting than xmpp, but using xmpp (without omemo unless you are all on Conversations) is boring in a good way.
As long as you stayed on the same instance everything was dandy, but writing to someone one the matrix homeserver worked most of the time.
Matrix as a protocol is more exciting than xmpp, but using xmpp (without omemo unless you are all on Conversations) is boring in a good way.
Also: what do we know about the people and institutions developing and promoting these standards and implementations?
We've seen the appointment of people with biographies suggesting affinity with US interests, for example Katherine Maher to the Signal Foundation (and the departure of the Moxie Marlinspike.)
I see a members list for the board overseeing the spec for Matrix, but does anyone know who they are[1]? And the spec is one thing, but who controls the development of the actually used clients and implementations?
Please note I am not imputing anything w.r.t. Matrix/Element etc, but if we're bothered to put effort into E2EE then it is probably worth thinking about this aspect in addition to whether the technical basis is sound. The historical record is clear on government attempts to influence things from that end.
I have the same sort of worries about GnuPG (and the SPoF that is the hard-working maintainer.)
Maybe E2EE is not of concern to the OP, in which case disregard the above.
1. https://matrix.org/foundation/governing-board-elections/
We've seen the appointment of people with biographies suggesting affinity with US interests, for example Katherine Maher to the Signal Foundation (and the departure of the Moxie Marlinspike.)
I see a members list for the board overseeing the spec for Matrix, but does anyone know who they are[1]? And the spec is one thing, but who controls the development of the actually used clients and implementations?
Please note I am not imputing anything w.r.t. Matrix/Element etc, but if we're bothered to put effort into E2EE then it is probably worth thinking about this aspect in addition to whether the technical basis is sound. The historical record is clear on government attempts to influence things from that end.
I have the same sort of worries about GnuPG (and the SPoF that is the hard-working maintainer.)
Maybe E2EE is not of concern to the OP, in which case disregard the above.
1. https://matrix.org/foundation/governing-board-elections/
I'm running an XMPP server for my family and have convinced most of my friends to get an XMPP address. I think XMPP is the more standard way to do messaging. I feel like all the projects that reinvent a basic thing such as instant messaging, instead of sticking to the internet standard are doing more harm than good.
Haven't used XMPP much so can't comment on that but in case of Matrix, I use conduit (server) + cinny (client) and it's much lighter and better setup than the synapse and element. Conduit isn't super feature rich nor cinny but if you aim for rich text messages it works well.
Cinny's latest update seemed really good and juicy, with lots of important features finally added. Haven't tried it proper yet tho.
My issue with anything not Synapse (for now), is migration and atability. Conduit is still somewhat a young project in comparison, and I'm not entirely confident in the upgrade paths yet. They also use RocksDB (or sled), which furthers this "fear", perhaps irrationally so. I'd love to host my conduit server with confidence though, but I'd also need Matrix to properly support account migration. IMO it's one of the key features still missing and it's damaging its "decentralized" image.
My issue with anything not Synapse (for now), is migration and atability. Conduit is still somewhat a young project in comparison, and I'm not entirely confident in the upgrade paths yet. They also use RocksDB (or sled), which furthers this "fear", perhaps irrationally so. I'd love to host my conduit server with confidence though, but I'd also need Matrix to properly support account migration. IMO it's one of the key features still missing and it's damaging its "decentralized" image.
Imo matrix is the better protocol, however the clients are still not great.
Element X is a big step up but element call is still in a kind of limbo where it's beta on desktop yet default on X.
The desktop client is capable but very very janky.
The desktop client is capable but very very janky.
If you want to develop fast, use neither and make your own protocol that suits your custom needs.
Totally the right answer, or maybe using Talk over SSH https://en.wikipedia.org/wiki/Talk_(software)
[deleted]