Our great sponsors
-
Signal-Server
Server supporting the Signal Private Messenger applications on Android, Desktop, and iOS
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
nostr
Discontinued a truly censorship-resistant alternative to Twitter that has a chance of working [Moved to: https://github.com/nostr-protocol/nostr] (by fiatjaf)
https://github.com/signalapp/Signal-Server
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.
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.
https://github.com/matrix-org/dendrite
/aside: this is a curious comment in their readme:
"A PostgreSQL database engine, which will perform better than SQLite with many users and/or larger rooms"
>What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
This is actively discouraged: https://github.com/libresignal/libresignal/issues/37#issueco...
Between inefficient and bad for privacy P2P DHTs and completely centralized or federated models from which you can be banned very easily, there exists a solution that takes the best of both worlds: https://github.com/fiatjaf/nostr.
Basically it works like this:
> Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.