Same setup here since 2017. Since then, RAM usage decreased by 60%.
The admin panel is not something I'd need but it would be a nice-to-have.
Started with postgres as I wouldn't go for anything else if I wanna use it for decades. It has 2.5GBs for 10users and I don't mind if it takes 10 or 20, that's something I expected. Never did a cleanup of anything, I just dumped the db and moved to OVH recently onto a new VPS with NVMe SSD, it flies.
The fact that I cannot delete attachments that users delete is certainly my biggest irritation, 50GBs of stuff I am not sure if I can or cannot delete, but considering the size, I am just gonna bite the bullet, couple terabytes should not be a problem in 25 years. But this is def something I would love to see addressed sooner rather than later. It must be a pain even for the matrix.org server team.
After moving to a better server I do not have issues with slow notification unless the phone is sleeping for longer period of time which is an android optimization (I'd assume). It is more reliable than teams at this point. One of my friends had issues but removing 15 old devices fixed the issue.
As for element-x, I did call out "the another rewrite" issue especially with android and I do think it makes things worse. I still do not know how am I supposed to fix calling and video between old and new clients. For now I don't bother with new clients and everyone is using old ones, but it starts to become an issue as classic clients are in maintenance only mode
I ran my own matrix server for a number of years, then learned that any matrix homeserver would happily serve up any media from matrix without authentication. I shut it down the next day because I have no desire to operate a proxy for downloading csam.
A url like https://my.domain.com/_matrix/media/<some.other.domain>/<some-bad-media-id> would happily proxy the bad media through my server.
I think they've fixed this, but it's not worth the risk to me.
Whatever is going on in Matrix land isn't stable enough for most people to switch.
I gave up after they broke their calling system after changing something to this livekit system. It doesn't work, my existing TURN server became useless, and Matrix was left as a very slow chat application.
>this also creates a situation where anything said across federation cannot be unsaid, which is an ironic situation for a protocol/system that often comes up when talking about privacy.
How is it ironic? No protocol in the world can force anyone to delete anything from their own device. Chat apps that implement this function are either proprietary (so you cannot control what they can do) or, if OSS, do it on a pinky-promise-basis.
> No protocol in the world can force anyone to delete anything from their own device.
But they either do not sign the messages or allow repudiating the signatures. Matrix signs all events forever.
Matrix also makes the entire event history (minus message content depending on room configuration) available to servers on join, even if that server's users are not allowed to see it.
A protocol can mandate forced deletion. A particular client implementation may ignore it, or some users may circumvent it, so it would be a weaker kind of feature, but still a feature. And depending on circumstances it can be quite useful.
> How is it ironic? No protocol in the world can force anyone to delete anything from their own device.
You may have noticed the constant pushing to remove the user's access to their "own" device.
Forcing people to delete things from their own device is the whole concept of the Snapchat protocol, for example. Snapchat fortunately doesn't offer an OS and can't meaningfully be part of this push, but they make a convenient illustration.
You can check out Snapchat's bug bounty policy here: https://hackerone.com/snapchat . On the list of ineligible vulnerabilities is "screenshot detection avoidance". That's not a bug (because there's nothing they can do about it), even though it is their product's selling point.
Sometimes stronger companies want similar things, and they try to do something about it.
Right, but we did have efforts to take over hardware security enclaves to deliver user data, instead of copyrighted company data, to user devices.
Tim Berners-Lee tries to make the internet a place where you can choose, what it "forgets". At least that were the news I got from the 2010s and early 2020s. As for how: DRM-like tech in the hands of users should allow for that.
So having privacy by design would be nice, and e.g. many messengers try to do "it is inconvenient to copy a message that someone send you that is marked as view-only-once-or-up-to-a-timespan, but of course, you can use an external camera, i.e. make more low-fidelity copies or even exfiltrate data".
Even F/LOS software can use/would be forced to use these proprietary enclaves or at least non-user accessible key stores. (As far as I understand hardware level DRM.)
Yeah I thought this was a weird take too. Too often people take privacy for "I can do what I like". IMO deleting something you've sent to someone else is not a privacy concern at all.
Ran a homeserver for 5 years on a minimal VPS and it worked fine. Upsides - works everywhere, self hosted, feature complete. Client software in the ecosystem mostly felt bloated, with the exception of NeoChat. By 2022 the clients could no longer call each other. Decommissioned it this year in favor of traditional XMPP which works fine and it's nice that notifications are appropriately processed, finally.
Our team highly appreciates the work done in Matrix it's just unfortunate that the elephant in the room was never addressed at the start of the project, which is the need for a -simple- first-party administrative dashboard or tool to manage users, storage, and configuration. Without that core component, then you've got a layer of complexity between an admin and an audit which will increase likelihood of misconfiguration or resource management issues.
In terms of VoIP interop - yes, one of the worst bits of Matrix is that the legacy 1:1 VoIP calling is not interoperable with MatrixRTC-based (multiparty) VoIP calling, but we ran out of time/cash to implement interop and instead focused on making MatrixRTC work well. (Does XMPP give you E2EE multiparty calling ooi?)
Thanks for mentioning XMPP. I never ran a server, but as a user I've been enjoying it. Also has its problems - for example, I picked some server to create my first account, and the other day the server disappeared for 6 hours. What do normal users (i.e. non-newbies like me) do in practice in these situations?
That said, I would love to hear your experience running an XMPP server. Do you still run it?
As a former user I felt these pain points trying to do nothing more than have a very active one-on-one chat with a good friend. Tens of messages an hour, maybe 2 years running. Using matrix.org and the pre-X clients. It's fine for group chat (IRC style) but that's not a high bar.
(a) the encryption between using a mobile and the webapp desyncs/breaks all the time, it just sucks. I mean you'll get "cannot decrypt" a lot, have to bounce back and forth and generally try and force it to re-sync properly again. Sometimes never worked at all. Lots of issues on GH over the years.
(b) as mentioned in this article, insane delays on new message notif and sending and receiving. Just logging in on the webapp every morning took minutes of some sort of mysterious sync process, often the mobile app had the same problems. The X stuff may fix this, we were pre-X.
(c) cleanup. There's no message retention set on matrix.org, when I wanted to extract and remove our past chats the process and experience was excruciatingly bad. It took tens of hours over several weekends of the webapp (mobile completely non-op in practice for this) polling and loading old content, just so I could select 100 at a time to delete and then it took an hour. Once I started culling back over a year or so, the loading got longer and longer and longer, until eventually it 100% stopped working at all to load old messages.
Signal and DeltaChat are far, far better experiences for one-on-one chats with friends & family. The Delta client is a bit UI/UX behind but not horrible; e.g. you can't correct a typo in a sent message in Delta, unlike Signal - because each msg is a unique gpg-encrypted "email" rather than a database object that can be re-manipulated.
I'm sorry you had a crap time, and agreed that in the past things were not great. But in defence of the Matrix team, we fixed almost all known encryption in ~Sept 2024, and the new generation of clients fixes the slow sync issues.
I've been using Matrix for several years as a user. It works great. The problems decrypting messages have gone. X is becoming a good client.
I'm deleting my whatsapp and télégram accounts in a few weeks after a painful week-long backup...
Edit : I wonder how easy it is to backup a Matrix accounts's data. Conversations and files.
> I wonder how easy it is to backup a Matrix accounts's data. Conversations and files.
Not as easy as you might hope. The Element client has an export feature, but you have to manually activate it on each room/chat, and the export has a size cap so it may not work if you have lots of files you want to save. It's also pretty slow if the room has a lot of history. You could also try using something like Matrix Commander (a command-line client), but I couldn't get that to work fully either.
> The only thing that I don't really understand is the decision on data replication. If a user on server A joins a room on server B, recent room data is copied from server B to server A and then kept in sync on both servers.
The idea here is that rooms are abstracted from servers and sort-of exist ephemerally. This has the advantage/disadvantage of making it hard for the underlying infrastructure to exert control over the hosted communities, and seems to have become a distinguishing feature of federation.
My experience of Matrix as a possible replacement for Discord has led me to believe it's mostly a disadvantage since it leads to gross misalignments between the communities in top and the infrastructure providers underneath. I consider e.g. Discourse to be much healthier (although I would like to see an app for Discourse so that my Discourse communities behave more like Discord/Slack servers) and it's frustrating to me that there hasn't been a clear "Discourse for chat" emerge to replace Discord.
> it leads to gross misalignments between the communities in top and the infrastructure providers underneath
Yeah, this is a great way to put it. We see this a lot with the mod experience. So much of the mod tooling is "run this bot on your server" or "configure synapse like this". But those kinds of things are inaccessible to people who aren't able to run any server of any kind. Of course someone else can run the mod bot for them, but then you still have the same problem where it introduces a layer of friction between the person who needs to perform mod actions and the person who controls the mechanism for doing so.
Until there's a robust and full-featured mod toolkit built in at the protocol/client level, it's a dicey situation for people who want to use Matrix to host a community. The insidious part is that everything may seem fine until suddenly your room is flooded with images of gore or worse.
(By the way, we still miss you in the Python room on Matrix! :-)
You could also try Movim. You could have a decentralized XMPP server with a client that support group calls as well as having posts like a forum folks can comment on.
> The idea here is that rooms are abstracted from servers and sort-of exist ephemerally
No, that's not even remotely true. In fact the opposite is true. The domain name of the server used to create the room is perpetually and permanently embedded in the room name and can't be changed, ever.
I’ve been running a Matrix server for about two years on a Proxmox host in a colo I rent for the purpose (plus some other hobby stuff, but mainly because I just think it’s cool). This playbook is awesome and it’s pretty easy to set up and keep running:
https://github.com/spantaleev/matrix-docker-ansible-deploy
Regarding the "Requires federation" section, that is not true. I've been running a small family-only homeserver for several years now, and had federation disabled on it from the very beginning, and there have been exactly zero issues related to (lack of) federation with it.
> While technically, Synapse can work with a sqlite database (and which at first seems like an OK choice for having <10 users on the server), it WILL become corrupted.
Does anyone have any more information on this? Running Postgres is not a big deal, but I would expect SQLite to be fine given how well it works in my experience.
I've not seen many corrupted sqlite databases, but because Synapse is not currently storage-efficient you can end up with some terrifying large (100GB+) sqlite databases which might as well be corrupted.
We only ever supported sqlite for ease of tinkering; it was never intended to be used in production, and in retrospect supporting it at all was a mistake.
I use sqlite for my 2-user server and haven't had any issues in the several years I've been running it.
It's possible to corrupt a sqlite database file, but generally it shouldn't happen unless you're doing something weird with it. https://www.sqlite.org/howtocorrupt.html
I've been running unfederated Matrix instance with sqlite for 10 years for 10-20 people some very active. In WAL mode sqlite is fine i am not sure why it would get corrupted.
Few years ago we did a data/history wipe (i managed to migrate accounts) because we switched to conduit.rs with sqlite. I very much prefer conduit to synapse.
I never had issue with sqlite it was mostly Synapse. With recent changes i think they are completely dropping the ball on small instances and it feels like the ecosystem is splitting. Element X is just not very good. It seems to exist to kill classic element and since for element x you need some server features that not all alternative synapse servers support.
> While technically, Synapse can work with a sqlite database (and which at first seems like an OK choice for having <10 users on the server), it WILL become corrupted
I want to hear more about this. Is this because Synapse’s SQLite support is half-baked? What sort of corruption are we taking about?
I've tried off and on to actually use Matrix. I was a bit of a loud supporter in the early days. Unfortunately, it looks like it still hasn't grown past the fundamental issues I was having then. It might be time to try something else
When I started using Matrix, Riot.im did not get notifications in time, or was a battery hog. And Synapse took up a lot of memory, with occasional slowdowns. But then, circa 2022, Synapse improved and Element seems to have worked well and was consistent and reliable on all platforms.
As someone who has looked into forking Matrix for a new type of chat service, I'm grateful to see a more in-depth look at running it behind the scenes. Thank you.
I've been developing open source code for over 25 years. i've deployed hugely complicated systems like hadoop. I've never seen anything as hard to run as this + the bridges.
To add another data point, I've been hosting a (tiny) matrix server for a few months. I'm pretty comfortable with self-hosting using docker, so I opted not to use the ansible scripts in the hope that it'd keep my setup simpler and more maintainable. Somehow I didn't find any mentions of ESS until Synapse was already up and running, but Kubernetes would have been a dealbreaker for similar reasons.
In this short time I've run a database migration (sqlite is the default, but MAS requires postgres), tried and failed to migrate to MAS (required to use Element X) and have lost a couple of days messing around with coturn and eturnal with nothing to show for it -- my calls still don't connect when NAT is involved. I have to tell new users to ignore the recommendations to install Element X until I get MAS working.
There's a lot of room for foundational improvements here, even updating docs to point would-be server admins to the recommended setup du jour would help.
OT: I have some very big groups in Telegram (7 years or more, with a lot of pictures). Can Matrix (Rocketchat or alternatives) have similar storage features (with some migration scripts)? Thanks
TLDR Self-hosting isn’t dying because people stopped caring. It’s dying because the complexity has gotten out of hand.
This post highlights how something that used to be a fun, lightweight hobby has turned into a full-time maintenance burden. Systems like Matrix are powerful, but they’ve become so intricate that even skilled engineers struggle to run them reliably. The result is a slow drift back toward centralized platforms, not out of preference, but because convenience keeps winning over autonomy. It’s a reminder of the growing gap between the ideal of a user-owned internet and the realities of modern software.
I would say it became much easier in recent years. docker-compose became defacto server "app install", any linux supports it. That includes GUI options like Truenas/Unraid and very nice admins like Dockge exist.
The company behind matrix is aiming at huge scale servers but if you care about unfederated private instances you will find there are few much simpler "one binary" projects that can even use file based sqlite/rocksdb. Hosting those couldn't be simpler. You actually don't even need docker just systemd service and switch binary when updating.
Yeah, I think this is true and it's unfortunate. I think it's one of the areas where what seemed like the plan for Matrix hasn't totally worked out in practice. And it's even just the intricacy of managing it; some of the problems are deeper in the design. When I started using it several years ago, it seemed their vision was a lot of people running a lot of small servers. But the full-replication nature of the protocol, plus the resource demands of the server software, make that kind of impractical. Even tech-oriented people may shy away if they find out the database could grow to tens of gigabytes, and Synapse is not exactly light on RAM or CPU either.
Perhaps in the future if implementations improve some of this may get better, and it will become more feasible for small operators to run their own servers. But by that time it will be harder to build trust because too many people will have written it off as bloated or unstable. I think it would have been better to start lean and keep the system in more of a nerd niche until that process of evolution reached a later stage.
NixOS makes this rather easy too. There exist modules for synapse, livekit, etc (MAS module is still a Pull Request, though) and the setup is quite doable: https://wiki.nixos.org/wiki/Matrix
However, you still need to know what you are doing (the manual helps) and connect the pieces (in theory there could be a nixpkgs module that does this for you but apparently nobody did bother). Once its done you can lean back.
I've been running my homeserver happily for > 5 years and it was fairly straightforward.
I've installed fresh matrix about 8 times or so, got it to work 3 of those times. I started looking for how to do a fresh install earlier this year (matrix/synapse element) and I have no idea which docs to use,
It was bad enough before that I had to detour to random places to find workarounds for things like how nginx does it's thing differently than the matrix docs I was reading at the time.. but now with the newer element that makes it easy to not find a self hosting way - to main docs being listed as archived or old -
I'd enjoy installing it fresh with someone from matrix watching the process just to see what a slog it is - and then watch someone try to get some addins running like admin and moderation.
wordpress is a one click install via softalicious and similar on most cpanel 10$ and up hosts.. you can one click add a decent free chat plugin if you are on a VPS.
If matrix was that simple to setup, lots of people would be using it.
I've been running synapse on a small VPS for the past few years. I got some of the bridges working too. Def bumps along the way, but its still the daily driver for me and about five other people.
Recently I spun up the new ESS Community Edition on a new VPS. Much easier to get up and running. I was delightfully surprised. although since that one uses kubernetes and other things I'm not familiar with getting bridges and other things I've become used to is going to require more learning on my part. Since ESS is so new, not a lot of newbie friendly howtos yet out there.
[+] [-] lousken|3 months ago|reply
The fact that I cannot delete attachments that users delete is certainly my biggest irritation, 50GBs of stuff I am not sure if I can or cannot delete, but considering the size, I am just gonna bite the bullet, couple terabytes should not be a problem in 25 years. But this is def something I would love to see addressed sooner rather than later. It must be a pain even for the matrix.org server team.
After moving to a better server I do not have issues with slow notification unless the phone is sleeping for longer period of time which is an android optimization (I'd assume). It is more reliable than teams at this point. One of my friends had issues but removing 15 old devices fixed the issue.
As for element-x, I did call out "the another rewrite" issue especially with android and I do think it makes things worse. I still do not know how am I supposed to fix calling and video between old and new clients. For now I don't bother with new clients and everyone is using old ones, but it starts to become an issue as classic clients are in maintenance only mode
[+] [-] seryvtva|3 months ago|reply
A url like https://my.domain.com/_matrix/media/<some.other.domain>/<some-bad-media-id> would happily proxy the bad media through my server.
I think they've fixed this, but it's not worth the risk to me.
[+] [-] 0x1ch|3 months ago|reply
I'm over it.
[+] [-] chromatin|3 months ago|reply
[1] https://conduit.rs/ and https://gitlab.com/famedly/conduit [2] https://gitlab.com/famedly/conduit/-/blob/next/docs/configur...
[+] [-] Almondsetat|3 months ago|reply
How is it ironic? No protocol in the world can force anyone to delete anything from their own device. Chat apps that implement this function are either proprietary (so you cannot control what they can do) or, if OSS, do it on a pinky-promise-basis.
[+] [-] progval|3 months ago|reply
But they either do not sign the messages or allow repudiating the signatures. Matrix signs all events forever.
Matrix also makes the entire event history (minus message content depending on room configuration) available to servers on join, even if that server's users are not allowed to see it.
[+] [-] broken-kebab|3 months ago|reply
[+] [-] thaumasiotes|3 months ago|reply
You may have noticed the constant pushing to remove the user's access to their "own" device.
Forcing people to delete things from their own device is the whole concept of the Snapchat protocol, for example. Snapchat fortunately doesn't offer an OS and can't meaningfully be part of this push, but they make a convenient illustration.
You can check out Snapchat's bug bounty policy here: https://hackerone.com/snapchat . On the list of ineligible vulnerabilities is "screenshot detection avoidance". That's not a bug (because there's nothing they can do about it), even though it is their product's selling point.
Sometimes stronger companies want similar things, and they try to do something about it.
[+] [-] a3w|3 months ago|reply
Tim Berners-Lee tries to make the internet a place where you can choose, what it "forgets". At least that were the news I got from the 2010s and early 2020s. As for how: DRM-like tech in the hands of users should allow for that.
So having privacy by design would be nice, and e.g. many messengers try to do "it is inconvenient to copy a message that someone send you that is marked as view-only-once-or-up-to-a-timespan, but of course, you can use an external camera, i.e. make more low-fidelity copies or even exfiltrate data".
Even F/LOS software can use/would be forced to use these proprietary enclaves or at least non-user accessible key stores. (As far as I understand hardware level DRM.)
[+] [-] dust-jacket|3 months ago|reply
[+] [-] unknown|3 months ago|reply
[deleted]
[+] [-] The_President|3 months ago|reply
Our team highly appreciates the work done in Matrix it's just unfortunate that the elephant in the room was never addressed at the start of the project, which is the need for a -simple- first-party administrative dashboard or tool to manage users, storage, and configuration. Without that core component, then you've got a layer of complexity between an admin and an audit which will increase likelihood of misconfiguration or resource management issues.
[+] [-] Arathorn|3 months ago|reply
In terms of VoIP interop - yes, one of the worst bits of Matrix is that the legacy 1:1 VoIP calling is not interoperable with MatrixRTC-based (multiparty) VoIP calling, but we ran out of time/cash to implement interop and instead focused on making MatrixRTC work well. (Does XMPP give you E2EE multiparty calling ooi?)
[+] [-] ekjhgkejhgk|3 months ago|reply
That said, I would love to hear your experience running an XMPP server. Do you still run it?
[+] [-] The_President|3 months ago|reply
[+] [-] styanax|3 months ago|reply
(a) the encryption between using a mobile and the webapp desyncs/breaks all the time, it just sucks. I mean you'll get "cannot decrypt" a lot, have to bounce back and forth and generally try and force it to re-sync properly again. Sometimes never worked at all. Lots of issues on GH over the years.
(b) as mentioned in this article, insane delays on new message notif and sending and receiving. Just logging in on the webapp every morning took minutes of some sort of mysterious sync process, often the mobile app had the same problems. The X stuff may fix this, we were pre-X.
(c) cleanup. There's no message retention set on matrix.org, when I wanted to extract and remove our past chats the process and experience was excruciatingly bad. It took tens of hours over several weekends of the webapp (mobile completely non-op in practice for this) polling and loading old content, just so I could select 100 at a time to delete and then it took an hour. Once I started culling back over a year or so, the loading got longer and longer and longer, until eventually it 100% stopped working at all to load old messages.
Signal and DeltaChat are far, far better experiences for one-on-one chats with friends & family. The Delta client is a bit UI/UX behind but not horrible; e.g. you can't correct a typo in a sent message in Delta, unlike Signal - because each msg is a unique gpg-encrypted "email" rather than a database object that can be re-manipulated.
[+] [-] salzig|3 months ago|reply
[+] [-] kassner|3 months ago|reply
At least on the iOS app you can, just tested it. I run my own postfix/dovecot, so shouldn’t require any esoteric configurations.
[+] [-] tcfhgj|3 months ago|reply
b) yeah, X solves it (via sliding sync)
[+] [-] Arathorn|3 months ago|reply
In terms of message retention: https://element-hq.github.io/synapse/latest/message_retentio... is how you should have/could have cleaned up those rooms. (It's not exposed in Element's UI yet as we've been prioritising more fundamental stuff).
[+] [-] maelito|3 months ago|reply
Edit : I wonder how easy it is to backup a Matrix accounts's data. Conversations and files.
[+] [-] BrenBarn|3 months ago|reply
Not as easy as you might hope. The Element client has an export feature, but you have to manually activate it on each room/chat, and the export has a size cap so it may not work if you have lots of files you want to save. It's also pretty slow if the room has a lot of history. You could also try using something like Matrix Commander (a command-line client), but I couldn't get that to work fully either.
[+] [-] jamesbelchamber|3 months ago|reply
The idea here is that rooms are abstracted from servers and sort-of exist ephemerally. This has the advantage/disadvantage of making it hard for the underlying infrastructure to exert control over the hosted communities, and seems to have become a distinguishing feature of federation.
My experience of Matrix as a possible replacement for Discord has led me to believe it's mostly a disadvantage since it leads to gross misalignments between the communities in top and the infrastructure providers underneath. I consider e.g. Discourse to be much healthier (although I would like to see an app for Discourse so that my Discourse communities behave more like Discord/Slack servers) and it's frustrating to me that there hasn't been a clear "Discourse for chat" emerge to replace Discord.
[+] [-] BrenBarn|3 months ago|reply
Yeah, this is a great way to put it. We see this a lot with the mod experience. So much of the mod tooling is "run this bot on your server" or "configure synapse like this". But those kinds of things are inaccessible to people who aren't able to run any server of any kind. Of course someone else can run the mod bot for them, but then you still have the same problem where it introduces a layer of friction between the person who needs to perform mod actions and the person who controls the mechanism for doing so.
Until there's a robust and full-featured mod toolkit built in at the protocol/client level, it's a dicey situation for people who want to use Matrix to host a community. The insidious part is that everything may seem fine until suddenly your room is flooded with images of gore or worse.
(By the way, we still miss you in the Python room on Matrix! :-)
[+] [-] toastal|3 months ago|reply
[+] [-] octoberfranklin|3 months ago|reply
No, that's not even remotely true. In fact the opposite is true. The domain name of the server used to create the room is perpetually and permanently embedded in the room name and can't be changed, ever.
[+] [-] nehal3m|3 months ago|reply
[+] [-] pferde|3 months ago|reply
[+] [-] Aurornis|3 months ago|reply
Does anyone have any more information on this? Running Postgres is not a big deal, but I would expect SQLite to be fine given how well it works in my experience.
[+] [-] Arathorn|3 months ago|reply
We only ever supported sqlite for ease of tinkering; it was never intended to be used in production, and in retrospect supporting it at all was a mistake.
In terms of synapse storage efficiency and how to improve it, folks may be interested in https://www.youtube.com/watch?v=D5zAgVYBuGk&t=1851s
[+] [-] meatmanek|3 months ago|reply
It's possible to corrupt a sqlite database file, but generally it shouldn't happen unless you're doing something weird with it. https://www.sqlite.org/howtocorrupt.html
[+] [-] omnimus|3 months ago|reply
Few years ago we did a data/history wipe (i managed to migrate accounts) because we switched to conduit.rs with sqlite. I very much prefer conduit to synapse.
I never had issue with sqlite it was mostly Synapse. With recent changes i think they are completely dropping the ball on small instances and it feels like the ecosystem is splitting. Element X is just not very good. It seems to exist to kill classic element and since for element x you need some server features that not all alternative synapse servers support.
[+] [-] chrismorgan|3 months ago|reply
I want to hear more about this. Is this because Synapse’s SQLite support is half-baked? What sort of corruption are we taking about?
[+] [-] mcluck|3 months ago|reply
[+] [-] yaky|3 months ago|reply
When I started using Matrix, Riot.im did not get notifications in time, or was a battery hog. And Synapse took up a lot of memory, with occasional slowdowns. But then, circa 2022, Synapse improved and Element seems to have worked well and was consistent and reliable on all platforms.
[+] [-] jimkleiber|3 months ago|reply
[+] [-] alexnewman|3 months ago|reply
[+] [-] 24t|3 months ago|reply
In this short time I've run a database migration (sqlite is the default, but MAS requires postgres), tried and failed to migrate to MAS (required to use Element X) and have lost a couple of days messing around with coturn and eturnal with nothing to show for it -- my calls still don't connect when NAT is involved. I have to tell new users to ignore the recommendations to install Element X until I get MAS working.
There's a lot of room for foundational improvements here, even updating docs to point would-be server admins to the recommended setup du jour would help.
[+] [-] df0b9f169d54|3 months ago|reply
[+] [-] Barathkanna|3 months ago|reply
This post highlights how something that used to be a fun, lightweight hobby has turned into a full-time maintenance burden. Systems like Matrix are powerful, but they’ve become so intricate that even skilled engineers struggle to run them reliably. The result is a slow drift back toward centralized platforms, not out of preference, but because convenience keeps winning over autonomy. It’s a reminder of the growing gap between the ideal of a user-owned internet and the realities of modern software.
[+] [-] omnimus|3 months ago|reply
The company behind matrix is aiming at huge scale servers but if you care about unfederated private instances you will find there are few much simpler "one binary" projects that can even use file based sqlite/rocksdb. Hosting those couldn't be simpler. You actually don't even need docker just systemd service and switch binary when updating.
[+] [-] BrenBarn|3 months ago|reply
Perhaps in the future if implementations improve some of this may get better, and it will become more feasible for small operators to run their own servers. But by that time it will be harder to build trust because too many people will have written it off as bloated or unstable. I think it would have been better to start lean and keep the system in more of a nerd niche until that process of evolution reached a later stage.
[+] [-] catelm|3 months ago|reply
However, you still need to know what you are doing (the manual helps) and connect the pieces (in theory there could be a nixpkgs module that does this for you but apparently nobody did bother). Once its done you can lean back.
I've been running my homeserver happily for > 5 years and it was fairly straightforward.
[+] [-] stevenicr|3 months ago|reply
It was bad enough before that I had to detour to random places to find workarounds for things like how nginx does it's thing differently than the matrix docs I was reading at the time.. but now with the newer element that makes it easy to not find a self hosting way - to main docs being listed as archived or old -
I'd enjoy installing it fresh with someone from matrix watching the process just to see what a slog it is - and then watch someone try to get some addins running like admin and moderation.
wordpress is a one click install via softalicious and similar on most cpanel 10$ and up hosts.. you can one click add a decent free chat plugin if you are on a VPS.
If matrix was that simple to setup, lots of people would be using it.
[+] [-] Arathorn|3 months ago|reply
Clearly we need to do a better job of pointing folks there.
[+] [-] ekjhgkejhgk|3 months ago|reply
[+] [-] eTomte|3 months ago|reply
Recently I spun up the new ESS Community Edition on a new VPS. Much easier to get up and running. I was delightfully surprised. although since that one uses kubernetes and other things I'm not familiar with getting bridges and other things I've become used to is going to require more learning on my part. Since ESS is so new, not a lot of newbie friendly howtos yet out there.
I remain optimistic.
[+] [-] yaky|3 months ago|reply