I use between some friends and family and I'm also connected to massive channels like the official "Element Android" and "Element Web/Desktop".
And it runs... just fine. The server can be a bit performance hungry but I also host plenty of other services on my VPS (email, HTTP server, Seafile, VPN, etc) and I never noticed any degradation in performance in any of them.
They have been making a lot of progress in improving the performance of the Synapse server and it is very usable now. And it is not difficult to configure at all, it's easier than configuring Prosody.
I would say that the bottleneck now is more about improving the UX and the Voip capabilities of the clients.
The federation API on matrix is a little too chatty for my taste. But that in itself causes no problems. The problems start when a user on your homeserver joins a massive room on any other homeserver. Most commonly these are the bug rooms on matrix.org. Once someone joins one such room, synapse will start slowing down and taking tons of RAM. This has significantly improved in the last year, by huge leaps and bounds. It however does remain a memory hungry process.
VoIP / video on the other hand has been a success story for me. 1:1 calls run smoothly after installing a TURN server. Me and my users use the calling functionality multiple tines a day and don't seem to have any problems with it.
These days it's mostly fine. The database is about 15GB (including media), there are scripts around the net to clean it up (rooms you've left, etc). Joining big, federated rooms is ram-expensive with synapse, though you now can specify a maximum complexity on your server to prevent joining those. Other small federated rooms are completely fine to join, and don't cost much more than a local room (IMO, there's little point in hosting a non-federated matrix server).
I use yunohost to simplify deployment, though it has some limitations. I did give access to a few friends, but I feel like I cannot guarantee uptime even though it has been pretty good so far. Once profiles-as-rooms land, that might change, as a user could just hop on another server if mine is down.
Every part of setting up a server that will federate/host repeats again and again that you need a TURN server (and they recommend coturn) - which is another 26,000 character config file - in order to do VOIP. If you've ever run or used a pbx before, STUN is needed 100% of the time for nat traversal between clients. Coturn even says it won't run if it's NAT'd (it will, but that's irrelevant to most people.)
This is the fourth concurrent tech trial of chat daemons, with rocket.chat and mattermost being a couple of the other ones that we're testing. synapse/element/matrix has the benefit of forced e2ee by my configuration. I don't know of any other matrix federated servers, so i haven't tried that yet, but an associate says it works on my configuration - which means it's not as big of a pig as i thought it was based on the outlandishly, comically large config file - where whitespace matters!
Mine only has around 100 lines without comments.
# cat /etc/matrix-synapse/homeserver.yaml|wc -l
1611
# cat /etc/matrix-synapse/homeserver.yaml| grep -v '^\s*#\|^$' | wc -l
101
The config file is just well-commented.I have about 20 users, with 5 of us being really active (but not much federation).
The computer is an Intel Kaby Lake i7 - really nothing special. I’ve never noticed crazy CPU usage.
I have it running on 4gb 8core arm sbc nowadays and i dont dare to federate. When somebody connects to a federated room with history and many users it explodes.
It seems future will be federated but with beefy servers.
Considering Matrix supposed to be the answer to decentralization... its mostly used on one main instance or in centralised silos like companies.
Encryption UI is a mess. I have actively tried and failed to set up E2E encryption with at least one other technical user. Recommend disabling encryption unless you want non-technical users to abandon ship immediately.
I will agree that voip/video isn't there yet, tried it with some friends and none of us could get anything working. I did go out and set up a TURN server afterwards, but once a piece of tech fails as badly as element did for us the damage is done. E2EE could definitely be done better as well, but in another post on here I saw a comment detailing a bunch of clients (many of which were abandonware) that didn't support E2EE at all. That's going to kill mass adoption, since you have no idea how many people are on those zombie clients that you still need to support. I wonder if the Matrix API has a way to define versions for these purposes, to advertise the highest supported version by both the client and server?