XMPP vs. Matrix | Hacker News Reader

XMPP vs. Matrix

wiki.404.city

30 pointsMYEUHD25 comments

This is very heavily biased. Many of the points "against matrix" aren't very well elaborated on or plainly wrong or outdated, such as the one stating that you can't viably run your own node. There's many things happening at the moment to make that easier, as well as a push to move off server nodes into p2p "device nodes" that contain your user data.

Matrix' federation isn't weak, Matrix.org just hosts the biggest node. If Matrix.org would disappear today, all that would be lost is users and chat for people on that node, the rest of the network would continue working as usual. A few friends of mine and me all host our own nodes, so we wouldn't even notice it, basically.

XMPP doesn't have this as all the big implementations are proprietary and incompatible.

The problem I have with matrix is more that it’s a real pain to write your own client that supports E2EE and such

Is it easier to write an xmpp client which supports E2EE?

I've been writing my own client (for kicks) from scratch by just following the specs, including E2EE. I have to agree - the documentation is terrible. It's split between [1], [2] and [3] and probably many more, but [2] is "unstable" (see [4]) and [3] is informal (see [5]). All the docs are also full of broken intra-links, so I've been even afraid of having `// Ref: https://matrix.org/docs/...` comments in my code just because I expect they'll become broken some time later.

The docs are often written from a JS perspective. For example, every mention of PBKDF2 talks about using "using SHA-512 for the hash function", but PBKDF2 uses a two-input PRF, usually an HMAC. What they mean is that it uses HMAC-SHA512, but I assume they keep saying "using SHA-512 for the hash function" because that's what the JS window.crypto.subtle API uses. [6]

Also, God the keys, so many keys. Keys used to encrypt other keys used to encrypt other keys, with different kinds of encryption and formats each time...

[1]: https://matrix.org/docs/spec/client_server/r0.6.1

[2]: https://spec.matrix.org/unstable/client-server-api/

[3]: https://matrix.org/docs/guides/implementing-more-advanced-e-...

[4]: AFAICT there is no stable version of [2]. [1] is not it; [1] and [2] have completely different content. Eg [2] explains how "m.secret_storage.key.<key_id>" events work, but this information is not present in [1].

[5]: As a concrete example, I've been working on deriving secret keys from passphrases for a few days, but it always derived the wrong key. I finally figured out why this morning - [3] implies the salt is base64-encoded but it's actually utf8-encoded, so I was decoding it incorrectly.

[6]: https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Param...

I believe that [1] is indeed the stable version of [2] - [2] contains things that [1] does not because it has new bits merged into it that have not yet been in a stable release. I think some of the confusion stems from them also swapping to a new version of the webpage in [2] that hasn't rolled out to the stable spec in [1] yet.

Good warning on the JS stuff, I actually just started reading through the E2EE docs again to prep for my client, and I appreciate the heads up!

It is impossible to implement E2EE without the information in [2] that is not present in [1]. [2] is how you get access to the storage key that Element etc used to store encrypted secrets in your account data.

So if anyone's goal is to build a Matrix client that's actually useful, [2] is unavoidable.

It took me an afternoon to get a Matrix server running. There's a PPA for it, it's in the Arch community repo... I don't know how much easier it could get.

There's also https://github.com/spantaleev/matrix-docker-ansible-deploy which can basically set up an entire matrix "ecosystem" including telephony, bridges and bots with one command and some basic configuration.

This is a very poor comparison - just off the cuff, most of the big negatives listed for Matrix are plainly untrue. The most irritating probably being it saying that Matrix is not an open extensible protocol, where it very much is. The core protocol undergoes evolution through an open, standardized process that anyone can participate in, shepherded by a separate foundation. The protocol itself, based around JSON, allows clients to define new event types (for instance, the Telegram bridge uses a special event type for when someone on Telegram replies to a message with an image) without the server having to understand them.

Also, why is its encryption yellow? It's a solid design that's undergone paid independent review, based upon Signal's e2ee.

There's more, but I since editing isn't open to the public I don't suppose its worth expending more effort to fix and argue with.

A process that defines how to build a single, core, monolithic protocol is not extensible.

No matter how open the development process.

Ultimately to advance Matrix you need to get the Matrix devs to check off on your work and it has to be built in to the Matrix protocol. The whole point of extensibility is permissionlessness & ability to work off core. For some reason Matrix advocates keep thinking they have some claims to say Matrix is extensible, and they're wrong.

This is false. The specification allows for you to define custom event types and fields in most places, and even specifies the naming conventions for doing so. There exists no requirement for it to be absorbed into the Matrix specification itself.

This is really no different than for XMPP. XEPs are also centrally managed, and you are expected to implement any proprietary extensions outside of that process.

That's good, & goes a long way, but it's still a fixed protocol defined in a monolithic spec.

XEPs are different in that they are independent (except explicit depedencies) of each other & not a part of the core spec. If someone wants to start adding new transports, add Link Local xmpp: they can. Just write the XEP (XEP-0174).

Whatever custom event types & fields there are in Matrix, it has no where near this level of extensibility.

I'm not sure that the existence of a core spec negates this though - you could similarly write an MSC for whatever thing you wanted, like a new low-bandwidth transport using CoAP and CBOR (MSC3079 - https://github.com/matrix-org/matrix-doc/pull/3079) and it may or may not end up being accepted into the core spec, but the MSC exists regardless and people can implement it. (and indeed, people often implement MSCs that they like before they land in the core spec, and before something lands you generally want an implementation or two anyway)

I've been using Matrix with non-standard events to communicate between bots. Works nicely. Between that and the standardization process, what else would you want?

As others have said, this really seems like a hatchet job on Matrix.

- Complains about no "authoritative and independent source" for a count of Matrix servers or clients or users, but I'm not aware of any such thing existing for XMPP either

- Cites WhatsApp and Zoom as XMPP implementations, which may or may not be true, but is pretty much meaningless w/o federation or the ability to use a different client

- As far as I can tell, it's not any harder to test experimental extensions to the Matrix protocol as it is to XMPP - the author makes up several extended forks of Matrix here that as far as I know, do not and have never existed

- Seems to regard corporate sponsorship as inherently suspicious, which seems at odds with citing WhatsApp and Zoom as proponents of XMPP

- They're right that Synapse is much more resource hungry than something like Prosody, but they exaggerate things to quite an extreme degree. I know of several successful Synapse deployments on Raspberry Pi, one hardly needs a "supercomputer"

- Seems to be very confused about how Cloudflare and Let's Encrypt work, there is nothing stopping you from using either or both or neither with both XMPP and Matrix

XMPP is a very, very strange protocol. well its not strange, its just the logical representation of what happens when you use XML for everything. It gets hilarious when start sending JSON over it.

However, I would still take it over matrix for any kind of chat protocol if I was going to start a commercial service.

My impression of matrix is that its was a slack/IRC clone with the protocol tied partially to the webgui. I understand that lots of work has happened to try and change that.

But, given that whatapp can handle a ~10m connections on one server in 2014, I suspect that it can't be a difficult protocol to scale, compared to something that runs over websockets

To be fair, Whatsapp's architecture is very well done. There are some slides on how they achieved very low latency and extremely high throughput with some cool BEAM optimizations

Oh indeed, whatsapp server was a thing of wonder, but even if a "normal" person could implement a server that was 100x less efficient, that would still be pretty spectacular.

In my experience, Matrix is largely a protocol for defining groups of users across federation and sharing structured data in near real time between these users, with or without encryption. The main use case is definitely a chat protocol, but there's nothing preventing you from using this as a tuple-space-style database (I kind of am at the moment), or as a transmission layer for pretty much anything.

I don't know about the current performance per server. I'm looking forward to seeing the Go and Rust implementations to compare performance :)

I doubt that go or rust is going to speed things up. Its not the language that causes slowness, its the implementation.

Personally if I wanted fast, high scale and secure authentication I'd either use oauth, or ldap. (ldap allows federation, oauth, not so much)

Seems very biased towards XMPP. Regarding mobile support, why is it more challenging to make a video call app on iOS than on Android?

As someone who uses XMPP nearly daily for actual chat purposes: The value sources seem all over the place.

The XMPP column counts Google and Apple totals to reach 2 billion users, but that's just push notification use (and might not even be current information), not chat use. One could point at the 1 billion total from the XMPP instant messaging page that is also linked, but that is based entirely on Zoom and Whatsapp, neither of which interoperate. The one source further down detailing a large interoperable server has the population of that server approaching 900k accounts, and an order of magnitude active users.

Later, XMPP is dinged for having poor iOS support and poor video support, but Whatsapp and Zoom are on iOS. Do they count or not?

My present theory is the page is oriented towards getting people to put money towards supporting XMPP, rather than being purely pro-XMPP.

Hi,

https://etke.cc developer is here. As the guy who setups matrix servers for customers I can tell you that a lot of information in topic link is a lie or controversial.

Example: Matrix is not extendable - seems the author didn't read any basic guide of Matrix protocol - you can and SHOULD extend it if you develop any new primitives and/or events. Even naming convention of matrix events encourages you to do that.

https://web.archive.org/web/20210625201040/https://wiki.404....

For future reference as a backup in case page is taken down

IRC > *

Reply on news.ycombinator.com