The matrix.org home server is spectacularly overloaded right now, causing messages to take several seconds to be delivered at a minimum. It isn't terribly surprising considering my own federated home server with under 20 users sits around 4gb of memory utilization with a single core (the server is single process/single threaded by default) pegged.
There's some work that can be done to proxy some of the load off into separate workers, but Synapse is pretty darn awkward to work with.
The problem isn't the number of connected or registered users on the server - the problem is the complexity of the rooms they are participating in. So if those 20 users join hundreds of rooms with tens of thousands of users participating, spread across thousands of servers, with large numbers of joins/parts or messages sent a second... you shouldn't be surprised that it takes a few GB of RAM.
HOWEVER, we have been working incredibly hard at optimisation over the last few months, and we have order-of-magnitude algorithmic performance improvements on the horizon over the coming weeks. https://twitter.com/matrixdotorg/status/979049079568240641 etc. There's also a port to python3 happening which should improve RAM by 2-3x given python3 stores strings in utf8 rather than python2's utf32.
I certainly don't mean to throw any shade on the project -- if anything, the RAM utilization was less of a surprise for me than being bound to single-core performance by default. Sure, it's possible to split Synapse up into workers, but it definitely feels like there's some voodoo involved (my first attempt at setting just a Synchroton worker failed miserably this week)
It isn't necessary, and we don't do it. What I've described is what happens if you type '/join #matrix:matrix.org' and your server starts participating in a large room which spans tens of thousands of users and hundreds of servers. Rooms are only replicated over the servers which participate in them. So if you don't join massive rooms, your server can be have fine. (And in the near future massive rooms should be usable too).
Have you tried leaving any giant rooms you may be in? Like Riot/Matrix HQ? I use my personal homeserver for my friends/some IRC channels and my load is nonexistent. May not be the answer you're looking for, but those huge (10,000+ users) rooms are a huge strain on homeservers right now. Look for performance updates in the next version of synapse.
Yup -- that's exactly what the end solution was. Unfortunately reaching out to those 20 users and saying "hey, could you be judicious about which federated rooms you join? otherwise you're gonna hose us all" kinda sucks.
from the bit I learned at a phoenix/elixer meetup - it seemed that it may be the most well suited for multiple chat streams. I am really interested in this.
I have a single non-federated synapse server with 10 users and 25 client devices, and the python process is using 135MB (RES in top). Load average is 0.00. There's 2 main rooms and probably around 10 chats. The homeserver.db is 26MB.
I tried this recently. I really wanted it to work. However, it was a complete mess, mainly frequent (and prolonged) disconnects on the bridge. For folks who primarily use Matrix but would like to occasionally pop into IRC channels, it's probably OK. For folks that need a reliable IRC connection, don't bother.
You are probably using one of the IRC bridges that is on the matrix.org server. The matrix.org server is having a lot of problems with being DDoSed as well as not being able to keep up with the normal traffic. The next generation homeserver written in Go is supposed to help with this a lot.
There is nothing inherently broken with Matrix <-> IRC bridges, it is just that one server. Other servers are bridging to IRC perfectly fine and you are welcome to host your own.
Agreed. Also another issue was that I Tested and trained a number of NGOs on it and the general feedback was that there were too many options on it when it came to rooms, sharing etc. As a techie I love it, but the general response was that it was too complex to use.
The UI could definitely be improved, but the core team has recently hired a UI designer, so hopefully this will improve in the future. If you have any other feedback that you've heard from your trainings, I'm sure the core team would love to hear about it either in their issue tracker (e.g. github.com/vector-im/riot-web/issues for Riot web), or in the Matrix rooms (#riot:matrix.org or #matrix:matrix.org).
Last I checked there was no Signal client for most Linux or BSD distros. IIRC they did something silly like a Debian-only package or something.
But as many others have stated, its inability to work without exchanging phone numbers is a show stopper for many uses cases. Especially now that my country requires SIM registration with valid IDs.
There's been one a couple in the AUR for a long while, too. Signal Desktop is not too bad. The aesthetics are clunky, and it didn't seem to scale well last time I used it, but decent overall.
I've been using Signal for a couple of months. Even though it works it has some quirks (slow to load up on macos, sometimes message lifetimes don't seem to be working, messages taking time to arrive to a second device although both have the application running). WhatsApp was better in that regard, but I'd prefer to use something a little more independent :)
Ah, and will try Keybase soon, although the downside of these switches are that I need to convince people around me to use them too..
Is the encryption for Riot.im out of Beta yet? Last time I've looked, about 4 month ago, it came with a big warning. Besides that it had no real concept of identity tied to account or so but generated a new key each time someone opened it in a browser or installed the app on a new device with out prompting, leading to people having as much as 30(!) keys, which of course nobody ever verifies.
it's less in beta than it was 4 months ago. we're at the stage of putting telemetry in the app to get it to phone home ever time encryption fails so we can see just how broken it is in the wild, as it seems pretty good for us. Cross-signing keys is next up and we're working on it over the next few weeks.
Matrix.org + Riot.im are a pretty solid combination. Plus, you can bridge to IRC.