Ask HN: Preferred chat program compromise between security and UX?

1. it is an open standard based on free software

2. it is based on history synchronization between servers instead of message transmission between clients, so you can send messages seamlessly from any device and have access to your conversation history (think git vs sms)

3. you can use your own server to host your conversations (the conversation history is replicated on the server of each participant)

4. it has end-to-end encryption

5. there is only one type of conversation, so the are no differences between a one-to-one chat and group chat: a one-to-one chat is simply a group chat with only two participants

i have my own personal server (old laptop at home), and the rest of my family uses another dedicated server (other old laptop at my cousin’s home). friends and coworkers use the matrix.org homeserver. the matrix.org homeserver can be slow sometimes (because it hosts many rooms and has many connected users), but messaging between our own servers is instant.

sure, it’s not (yet) as polished as mainstream apps. for example, currently, with end-to-end encryption, one need to verify each device of each other person on each of their own devices, which is not very user friendly (but this is being worked on, so only one verification per person will be needed in the future).

this said, it has nevertheless the most needed features. it has even some features that mainstream apps lack. for example, if you’re a little technical you can start using bridges. this allows to receive and send messages from/to other messaging systems (irc, xmpp, slack, telegram, discord, sms,…) all from within your matrix client.

For instance, as of a few days ago we have a tentative fix for one of the biggest causes of high RAM usage in Synapse (the reference server implementation): https://github.com/matrix-org/synapse/pull/5480. If this tests out okay in the wild it should land in the next release.

Meanwhile, my personal server idles at around 600MB of RAM (across a few hundred conversations, some in quite large rooms), although there's room for us to reduce that by at least a factor of 10.

It's important to understand that Matrix is effectively a system for replicating chat history - it's more like USENET or Git than (say) XMPP or IRC. As a result, the resource utilisation depends entirely on the complexity/size of the rooms you participate in. A single person server where that user joins thousands of public chatrooms with hundreds of thousands of users is going to use a lot more RAM than a 10,000 person server where everyone is in small private chats.

Finally, a lot of Matrix's reputation for bad performance comes from the fact that the default sqlite database is not remotely optimised at all, and performs horrifically badly as soon as you start federating with the rest of Matrix. You have to use Postgres these days. Also, if you do end up with a heavily used server, you have to manually increase the cache sizing in the config; it doesn't autotune the caches yet.

So to conclude:

* Run Python3

* Run PostgreSQL

* If your users are joining lots of large rooms, you'll need to manually increase the cache factor to avoid hammering the DB. Alternatively, you can now cap the size of rooms your server is allowed to participate in (https://github.com/matrix-org/synapse/issues/5069)

...and you should be relatively fine.