This is all a bit depressing, speaking as the project lead for Matrix.
1. It's true that Synapse can use a lot of RAM.
- The biggest cause of this is due to spikes in RAM during state resolution (the merge resolution algorithm used to converge your server's view of a room with the other servers in a room), which Python doesn't always recover nicely. We fixed the main cause of this in Synapse 1.26, which was released on Wednesday: https://github.com/matrix-org/synapse/issues/8622 is interesting reading on the details.
- Another cause is that by default we cache a lot of data in RAM in order to avoid hammering the DB. Currently you have to manually tune the size of that cache, which should be done automatically - we're hoping to get to this shortly.
- The other main cause is that the resource requirements depends on the complexity of the rooms its users participate in, not the number of users on the server. So a single user server can use serious RAM if that one user goes and joins a bunch of busy rooms with hundreds of thousands of users in them. This can be surprising to sysadmins, and we haven't figured out a good way of solving it other than just keeping making Synapse go faster.
- Finally, even though we're continuing to polish Synapse hard, we're also working on Dendrite, which uses roughly 5x less RAM than Synapse (thanks to relying on the DB for caching, using a smarter DB schema; passing all strings around as enums called NIDs, and Go's GC being smarter than Python's). For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users. It's still beta, but progressing fast.
2. In terms of choosing a Matrix server: "Well, you could just tell a person to use matrix.org. But then it spent a good portion of last year unable to federate with other popular nodes due to Synapse limitations." - yes, at the beginning of 2020 we hit a performance ceiling on Synapse on matrix.org which caused federation to fall behind during heavy traffic. *So we fixed it*. https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-sca... has the details. Meanwhile, more and more other folks are spinning up reliable Matrix providing services.
3. In terms of "Voice and video calling are not there yet in Matrix", again: we've been working our asses off to fix this. Since September we've had a dedicated fulltime VoIP team going through reworking 1:1 VoIP, implementing the work at https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... This has been landing over the last few weeks (although there's still some stuff left), but it should already be noticeably more robust. Meanwhile, integration to Jitsi for video conferencing has also improved a bunch - we're counting on it for running FOSDEM next weekend, after all. In terms of NAT: yes, you have to correctly set up a TURN server. We're building https://github.com/matrix-org/voip-tester to help folks test that they've got it right.
4. "Matrix is so hard to set up on a server that there is matrix-docker-ansible-deploy". This is bogus, imo. The ansible project is useful if you want to quickly run tonnes of bridges without understanding how to admin them, but for a typical Matrix server you should be able to `pip install matrix-synapse` and off you go. It's a fair point that Synapse doesn't yet ship with an admin tool, just an admin API, but there are folks filling this gap (https://github.com/Awesome-Technologies/synapse-admin is good).
5. "Encryption isn’t mandatory in Matrix". This is because, unlike Signal, Matrix supports public chatrooms. It makes *NO* sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world. All it would do is waste significant CPU on the clients, and hit up against resource limits given how large public chatrooms can get. Meanwhile, all private conversations are E2EE by default, assuming your client supports E2EE.
TL;DR: It feels like we're being judged on Matrix as it was in early 2020, ignoring all the sprinting we've been doing throughout the last year to address these criticisms, so it's all rather frustrating.
> For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users.
That's impressive, congrats!
I hear your frustration, and I think only time can solve this problem, and it does eventually. It's the same with Signal and the initially poor user experience.
> It makes NO sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world.
Even if you don't want encryption, authentication is still good to have, so quick question: who authenticates messages when you deactivate E2EE in Matrix? In the case of a public room hosted on server S, A sends a message M1, then sends another M2. Assuming that S is not actively MITM until after the first message (so any initial key exchange can happen), can I be sure that the second message will not be tampered with?
IIUC a Signal group where a client would then broadcast all messages to the world would still provide such a guarantee. Is that the case as well for Matrix?
So you’re right that (a subset of) E2EE in a public room could be used to provide sender authentication; atm you trust the sending server not to be spoofing it. Full E2EE would be overkill.
An interesting aside as a casual observer (thank you for all your work, I see you post here a lot) I found it very interesting that the new Rocky Linux project stood up Mattermost (chat.rockylinux.org) instead of Matrix. When I Google "Mattermost vs Matrix" (because I'll be honest, they seem the same to me as a casual) the insta-Google popup result/excerpt inline is this article:
That's a year old, so Google isn't doing y'all a service by highlighting that as it's insta-hit, we need something updated out there for 2021 for Google to latch onto.
I've created a Mattermost account for Rocky stuff and honestly, as a casual I can't tell why I'd want one vs. the other, they seem pretty much the same to me (even the UI is kinda the same). Matrix touts a lot of extra privacy stuff I think, that's about it...
$0.02 from the peanut gallery! :) I'm just using web clients and not the mobile clients (per my preference for this stuff) and use app.element.io as a comparison.
I'm the guy that wrote the blog article that got posted here. So, I'm dusting off my really old HN account, to step up and say that I am very sorry it felt depressing to you, because that was not my intent.
In fact, as I said in the post, I use Matrix, I love Matrix, I evangelize Matrix (especially to Discord people), it has made a lot of strides lately. I had a previous post on distributed offline-capable IMs at https://changelog.complete.org/archives/10205-roundup-of-sec... and I got so much feedback to "don't let people use Signal, switch to Matrix!" that I specifically was addressing Matrix as a Signal replacement in the post. (I regret it wasn't super clear that's what I was doing.)
I'm going to address your points in a sort of different order, starting with:
#5, encryption. The benefit to Signal here is that encryption is NOT optional. A user just knows everything is going to be encrypted. 1-to-1 chatting, group chats ("rooms" to Matrix), voice and video calling, attachments, EVERYTHING is E2E encryption and user error can't result in things being sent in plaintext.
Now as you say there are reasons that, say, #fx-desktop-community:mozilla.org with its 1100 users shouldn't be using E2EE. However, when talking about Matrix *as a Signal replacement*, the fact that E2E is only default but not mandatory for 1-to-1 chats, and optional but not default for multi-user chats (in Element), this makes it a lot easier for non-tech-savvy end users to goof and send messages in plaintext. A secure replacement for Signal needs to not have that option. Perhaps a "secure everything" mode in Element would help.
2. Fundamentally, there is a deeper issue here: for every Matrix user, there exists at least one, and possibly more, single points of failure. As far as I know, Synapse itself isn't clusterable, so for every Matrix homeserver, the failure of, say, a single CPU will render everyone on that server unable to communicate. I say "possibly more" because many people probably will run a singleton PostgreSQL instance also, though PostgreSQL can be clustered. Or even an upgrade to Synapse there would take people offline, etc.
For me to be able to recommend an IM to people, it must pass the "I can rely on this thing to get help if my car breaks down at night" test. Right now, Matrix doesn't give me that level of comfort. Yes, it's getting better. Yes, various hosting options exist. But still, if the homeserver you're using has a bad CPU or Synapse OOMs it or whatever, your messages aren't going through in a timely manner.
3. I am glad to hear that voice and video calling are getting so close. However, I want to still add that having two different VOIP systems -- one that can handle precisely 2 participants and another that can handle more -- is jarring for end users and admins alike. People are used to being able to tap "add participant" to their calls and this is a UX issue for people coming from other IM systems.
1. I'm glad to hear these RAM issues are getting better. I've spent a fair bit of time tuning that cache parameter, from its default of 0.5 down to 0.2 (which resulted in drastically unacceptable performance) up to the other recommendation of 2.0 (which still resulted in OOMs). I am in some large Debian, Firefox, and Matrix rooms, with over a thousand participants each -- though some of those, at least, are gated from IRC where such a scale is a non-issue.
I've been following Dendrite's "are we Synapse yet?" page with interest and excitement. I am looking forward to it being ready to use! But as I stated in my post, and as you are surely aware, it's not there yet, at least based on the "are we Synapse yet?" page.
4. It's not actually that simple. A person is most likely going to want at LEAST Synapse and Element Web. Most are probably also going to need coturn, Dimension, Jitsi, synapse-admin, and maybe an identity/directory server. The downloading of the software is the easy bit. The hard bit is getting all the bits talking to each other properly, with various JSON config files, keys, DNS entries, SSL certs, well-known files, ports, etc.
I set up my own Matrix server due to difficulties with the integrations at t2bot, some limitations in the IRC bridge I had to work around, etc.
Also to those wondering why Matrix and not XMPP: I used to run ejabberd and an XMPP service. XMPP has (or at least, HAD) a real issue when being used with multiple clients - delivering messages to the wrong place, not syncing history, etc. Matrix is far better with those things. Also Jingle in XMPP land barely ever worked, last I checked.
An aside: I try not to comment on non-federated corporate-control sites (of which HN is an example), but hopefully if you reply I'll get an email or something. You are also welcome to engage me on my blog or on Mastodon, where I first surfaced many of these ideas (and did tag the Matrix Mastodon account). Or email me.
Once again, thanks for what you do. Matrix is great for many use cases and will be great for more in the future. But I want to be clear-eyed about how it compares to Signal for the secure IM use case, today.
1. It's true that Synapse can use a lot of RAM.
- The biggest cause of this is due to spikes in RAM during state resolution (the merge resolution algorithm used to converge your server's view of a room with the other servers in a room), which Python doesn't always recover nicely. We fixed the main cause of this in Synapse 1.26, which was released on Wednesday: https://github.com/matrix-org/synapse/issues/8622 is interesting reading on the details.
- Another cause is that by default we cache a lot of data in RAM in order to avoid hammering the DB. Currently you have to manually tune the size of that cache, which should be done automatically - we're hoping to get to this shortly.
- The other main cause is that the resource requirements depends on the complexity of the rooms its users participate in, not the number of users on the server. So a single user server can use serious RAM if that one user goes and joins a bunch of busy rooms with hundreds of thousands of users in them. This can be surprising to sysadmins, and we haven't figured out a good way of solving it other than just keeping making Synapse go faster.
- Finally, even though we're continuing to polish Synapse hard, we're also working on Dendrite, which uses roughly 5x less RAM than Synapse (thanks to relying on the DB for caching, using a smarter DB schema; passing all strings around as enums called NIDs, and Go's GC being smarter than Python's). For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users. It's still beta, but progressing fast.
2. In terms of choosing a Matrix server: "Well, you could just tell a person to use matrix.org. But then it spent a good portion of last year unable to federate with other popular nodes due to Synapse limitations." - yes, at the beginning of 2020 we hit a performance ceiling on Synapse on matrix.org which caused federation to fall behind during heavy traffic. *So we fixed it*. https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-sca... has the details. Meanwhile, more and more other folks are spinning up reliable Matrix providing services.
3. In terms of "Voice and video calling are not there yet in Matrix", again: we've been working our asses off to fix this. Since September we've had a dedicated fulltime VoIP team going through reworking 1:1 VoIP, implementing the work at https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... This has been landing over the last few weeks (although there's still some stuff left), but it should already be noticeably more robust. Meanwhile, integration to Jitsi for video conferencing has also improved a bunch - we're counting on it for running FOSDEM next weekend, after all. In terms of NAT: yes, you have to correctly set up a TURN server. We're building https://github.com/matrix-org/voip-tester to help folks test that they've got it right.
4. "Matrix is so hard to set up on a server that there is matrix-docker-ansible-deploy". This is bogus, imo. The ansible project is useful if you want to quickly run tonnes of bridges without understanding how to admin them, but for a typical Matrix server you should be able to `pip install matrix-synapse` and off you go. It's a fair point that Synapse doesn't yet ship with an admin tool, just an admin API, but there are folks filling this gap (https://github.com/Awesome-Technologies/synapse-admin is good).
5. "Encryption isn’t mandatory in Matrix". This is because, unlike Signal, Matrix supports public chatrooms. It makes *NO* sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world. All it would do is waste significant CPU on the clients, and hit up against resource limits given how large public chatrooms can get. Meanwhile, all private conversations are E2EE by default, assuming your client supports E2EE.
TL;DR: It feels like we're being judged on Matrix as it was in early 2020, ignoring all the sprinting we've been doing throughout the last year to address these criticisms, so it's all rather frustrating.