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

21–30 of 92 posts

Re: XMPP vs. Matrix

#21

Post by AshamedCaptain »

dngray wrote: post #19
AshamedCaptain wrote: post #15

Earlier quoted context omitted.

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

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.

Re: XMPP vs. Matrix

#22

Post by wdkrnls »

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?

Re: XMPP vs. Matrix

#23

Post by dngray »

AshamedCaptain wrote: post #21
dngray wrote: post #19

Earlier quoted context omitted.

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

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.

Re: XMPP vs. Matrix

#24

Post by erszcz »

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…

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? ;)

Re: XMPP vs. Matrix

#25

Post by AshamedCaptain »

dngray wrote: post #23
AshamedCaptain wrote: post #21

Earlier quoted context omitted.

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

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.

Re: XMPP vs. Matrix

#26

Post by upofadown »

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…

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

Re: XMPP vs. Matrix

#27

Post by dngray »

AshamedCaptain wrote: post #25
dngray wrote: post #23

Earlier quoted context omitted.

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

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

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

Re: XMPP vs. Matrix

#28

Post by pantalaimon »

bjoli wrote: post #14

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.

Unable to decrypt message

Re: XMPP vs. Matrix

#29

Post by upofadown »

dngray wrote: post #18
upofadown wrote: post #17

Earlier quoted context omitted.

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

What does STARTTLS have to do with a MITM attack based on certificate substitution? What XMPP servers still allow unencrypted client connections by default?

Re: XMPP vs. Matrix

#30

Post by AshamedCaptain »

dngray wrote: post #27
AshamedCaptain wrote: post #25

Earlier quoted context omitted.

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

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

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

Post reply on HN