Drawbacks of P2P and a defense of Signal

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.

That's the cool thing with Threema. If you verifyed the contact is so prominent, everybody want to verify each others key, even people who don't understand the concept. In Threema it is not hidden somewhere, it's just allways visible on each single contact with green or red dots.

Notice how the load balancers, databases, and caching layers at those places are _not_ written in Python. They then have to run a wasteful amount of instances to keep their Python services afloat. Modern computers can do an amazing amount of work in a given time slice, but it's a shame when so much of that is thrown away because someone decided to implement it in Python.

> But what would happen if Signal would ever stop being benevolent?

You fork it.

The software is free...?