Barely 1-2% CPU usage. Using synapse.
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
I don't know about other homeserver implementations but synapse kinda sucks. It used to randomly eat 100% of 1 or 2 CPU cores (including the database) until I tracked it down to 3 rooms having a messed up state which caused costly SQL queries. I removed the rooms from my server (using a third party admin panel because there's no proper admin GUI built in, the documentation just mentions curl commands to hit the admin API, with placeholders to manually replace). It has been fine since I did it, but I'm the only user on my server. And I expect other issues to come up at any time...
It also eats a lot of storage, mostly the database. It grew very large quickly, but it's more stable now
This is a fundamental issue of the Matrix protocol, yes. For regular small scale use it doesn't matter so much, and the state history gets reset every time you do a room upgrade, which is another annoying "feature" of Matrix, but it eases the fundamental problem a bit.
But IMHO the Matrix protocol is a child of the Bitcoin hype era and is built on a similar data-structure that is inherently impossible to scale and the developers of Matrix should have realized that early on. Their bosses back then actually did, but they spun it off as a separate company and got some crypto-currency investments so the can was kicked down the road and here we are...
Is there a good alternative that you would recommend?
XMPP obviously. Have a look at https://joinjabber.org/
Still staggering to me that XMPP isn't the default, since it was used in many chat apps in the late 90's.
Does it do screen sharing, group calls, etc.?
Screensharing is the only thing i dont think it does. Voice and video good. See snikket or conversations.im
Neither of those client promo pages mention group calling. le sigh
I believe group calling is only a thing certain clients (e.g. Dino, Movim) support, although there is a initiative to implement it on protocol level as far as I am aware.
So, Onomatopoeia there is wondering why xmpp isn't standard, and I'm getting the sense that it is targeted at oldskool usage.
Discord is popular because it's easy to start using, it has collaboration features like group screensharing, and it doesn't assume an ubernerd is the target audience.
Maybe we'll get a more unified, feature rich xmpp implementation, but until then, sounds like matrix/element is closer, despite its warts.
Any source for the coin stuff? Never read about it
They (Element / New Vector) got a major early investment in 2018 from Status, a cryptocurrency/web3 company, and later in 2021 an even bigger one in relation to Protocol Labs, who peddle their own cryptocurrency.
It can baloon as it scales up. Matrix.org (homeserver) has had at least one DB corruption and that's with their proprietary Rust bindings for Synapse. Small communities, especially ones that share rooms between them, should be fine on most systems. Make regular backups of the DB.
And, importantly, run the db on postgre, not sqlite, and implement the regular db maintenance steps explained in the wiki. I've been running mine like that in a small VM for about 6 months, i join large communities, run whatsapp, gmessages and discord bridges, and my DB is 400MB.
Before when I was still testing and didn't implement the regular db maintenance it balloned up to 10GB in 4 months.

It is my understanding that all of the ballooning DB is room states, something that you can't really prune. What exactly are you pruning from the DB?
There's also issues with the state disagreement / resolution algorithms across federation.
Has this been solved? Maybe it's also due to database corruption, where some state is forgotten across the federation, and thus the algorithm breaks down?