Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XMPP vs. Matrix

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 92 posts

Re: XMPP vs. Matrix

#11

Post by AshamedCaptain »

dngray wrote: post #6

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.

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.

Re: XMPP vs. Matrix

#12

Post by jacooper »

Fell wrote: post #7

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, gr…

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.

Re: XMPP vs. Matrix

#13

Post by dngray »

AshamedCaptain wrote: post #11
dngray wrote: post #6

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.

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 el…

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)

Re: XMPP vs. Matrix

#14

Post by bjoli »

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.

Re: XMPP vs. Matrix

#15

Post by AshamedCaptain »

dngray wrote: post #13
AshamedCaptain wrote: post #11

Earlier quoted context omitted.

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 el…

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,…

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

Re: XMPP vs. Matrix

#16

Post by dngray »

the_third_wave wrote: post #9

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.

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

Re: XMPP vs. Matrix

#17

Post by upofadown »

dngray wrote: post #13
AshamedCaptain wrote: post #11

Earlier quoted context omitted.

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 el…

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,…

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

Re: XMPP vs. Matrix

#18

Post by dngray »

upofadown wrote: post #17
dngray wrote: post #13

Earlier quoted context omitted.

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,…

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

> As in not anything to do with XMPP specifically.

The fact that STARTTLS is even possible with that protocol is bad.

Re: XMPP vs. Matrix

#19

Post by dngray »

AshamedCaptain wrote: post #15
dngray wrote: post #13

Earlier quoted context omitted.

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,…

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

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

Re: XMPP vs. Matrix

#20

Post by rglullis »

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.
Post reply on HN