synapse-admin

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.