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.
I don't plan to give up just yet. Switching is way too difficult and I don't see many platforms having both solid desktop and mobile versions with e2ee.
But if they dare rewriting anything again from scratch I am leaving. They MUST stick with what they have and make it good at this point.
I gave up after I upgraded my server from a SQLite backend to a PostgreSQL one with their conversion script which introduced errors into my DB.
Maybe one day I'll dig into it and see if I can fix the DB by extracting whatever data in it that's causing the errors, but like, is it really worth it at this point?
Honestly this doesn't fit my usecase. If I understand it correctly, it is just like any other retention policy meaning it is not related to the fact that the attachment was deleted by user, but it just deletes everything after a certain point.
I don't mind storing things that people can access for many years - if I wanna see that funny picture from 10 years ago, I should be able to find it (even though GUI in Element sucks for that now). But what I do care about are things they uploaded accidentally or that they wanted to delete for whatever reason and it stayed on my server.
>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.
These are distinctions without a difference. Events replicated across several independent Matrix servers are not meaningfully different than events broadcast across independent clients in terms of observability or repudiation.
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.
An open protocol can mandate indeed, but that is still in the realm of pinky promise security. A better design for a privacy-friendly chat protocol is to not write a lot of stuff on a lot of different remote servers when that's not necessary IMHO. One of matrix's selling points is to be censorship-proof though; in that case copying stuff as much as possible makes a lot more sense.
A protocol can only support, never mandate. If I send you "DELETE MSG #4829" and you do nothing and reply with "200 OK; DELETE MSG #4829", nobody observing the protocol's messages will ever know what happened. Sure, an omniscent being could say "but he internally broke protocol, he didn't delete the message!", but by definition if something cannot be verified inside the protocol, it is outside of protocol.
People should related to anything federated like email. If you send something it is in someone else's computer now. With matrix or any e2ee protocols it is depending on pinky promise of the client to modify it. I thought the whole Snapchat fiasco already taught us that. Did we forget?
> 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.)
>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.
Tim Berners-Lee created the web, not the internet, which is what chat apps use. Also, unless you can provide some direct quotes about it being designed for "forgetting" stuff, I have no idea where these "news" you got came from.
>As for how: DRM-like tech in the hands of users should allow for that.
If it's in the hands of the users, i.e. open source, it can be disabled at any moment, which is exactly what my reply already addressed.
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.
IIRC it is possible to have some clever encryption so that the person you sent your message to can prove to their own satisfaction that it came from you, but they cannot prove to anyone else that it came from you. Which gives you plausible deniability; you can always claim that your contact forged the message.
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?)
Thank you Aaron for the direct response. Glad to see the central interface for administrative use. Haven't had the need to use the calling feature in a while. One of the hurdles with the Rust client on Fdroid was it was too new for the OS on the device it needed to be used on, but on iOS it was a performance improvement.
One of the genius ideas behind Element was the ecosystem of clients services that attach to rooms, and in some cases XMPP does not reach those expectations. I do plan on a redeployment soon after creating a new technical scope for its use.
I like what I can observe of the new admin interface. I hope it can come to include security and configuration check guidances to provide tools for admins of all skillsets to properly configure their servers, and related TURN-or-not and storage.
Matrix is bigtime like XMPP - I don't think it's going anywhere anytime soon. Thankful for all that it has provided to our organizations.
Another cashflow idea, as if you don't think of many yourself: A white-label version of Element (called something else) that can be deployed as scoped to an organization and based on an LTS release schedule. We'd gladly pay for this.
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?
Trusting your chat activity and availability to any XMPP server on the internet that allows free public registration is not ideal. If you want reliability then pay for it or use what you perceive as a highly credible free server. I do not run any public facing XMPP services so I do not have any input on that and as with Matrix I wouldn't roll your own unless you know exactly what you're doing due to inherit risks associated with these platforms in certain states of configuration or exposure.
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.
a) As of when? I had a "cannot decrypt" room failure on matrix.org a year ago.
b) Unfortunately, X breaks other important things, like audio/video calls. It currently feels like an alpha-quality release: buggy and lots of missing features. Not ready for widespread use.
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.
Hi Arathorn, I recognize your name as the core developer lead. :) Alas, when I was trying to cull my old messages I tried that (and a lot of other API type hacks I found floating around) and none of them, at that time, worked.
In short: the complete lack of user-facing easy to use controls for data retention and culling in the Matrix (Element) clients is a deal killer for me. That painful experience taught me a lesson - now when I test something new, one of the first things I look for is "how do I extract from this thing?". I never want to go through my Matrix extraction pain again, so a personal life lesson was learned.
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.
There are a bunch of options out there (though I've never seen Movim - thanks, I'll check it out) but most communities seem either to be on Discord or Matrix (with a few still hanging on to IRC and a few others on Slack) - Discord being by far the best UX of the lot.
> 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.
Same here, though you do still have to expose it to the internet unless you use a VPN. I'd prefer something with less of an attack service especially because bridges don't currently encrypt, but I host behind vpn now.
That's not a fair criticism. Of course you need to expose the server to the network clients are going to be connecting from. Whether that is Internet or just a LAN, that's orthogonal to the protocol.
I've also had an intra-company Matrix server running completely on a company internal LAN, with no Internet access, so there is no inherent need for it to be on The Internet.
Readit News
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
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.
I'm over it.
But if they dare rewriting anything again from scratch I am leaving. They MUST stick with what they have and make it good at this point.
Maybe one day I'll dig into it and see if I can fix the DB by extracting whatever data in it that's causing the errors, but like, is it really worth it at this point?
What does running a matrix server get me in 2025?
[1] https://conduit.rs/ and https://gitlab.com/famedly/conduit [2] https://gitlab.com/famedly/conduit/-/blob/next/docs/configur...
I don't mind storing things that people can access for many years - if I wanna see that funny picture from 10 years ago, I should be able to find it (even though GUI in Element sucks for that now). But what I do care about are things they uploaded accidentally or that they wanted to delete for whatever reason and it stayed on my server.
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.
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.
The important bit is the bit in brackets: as you say, historical message content is not shared if the room's is configured not to share history.
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.
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.)
Tim Berners-Lee created the web, not the internet, which is what chat apps use. Also, unless you can provide some direct quotes about it being designed for "forgetting" stuff, I have no idea where these "news" you got came from.
>As for how: DRM-like tech in the hands of users should allow for that.
If it's in the hands of the users, i.e. open source, it can be disabled at any moment, which is exactly what my reply already addressed.
Can't remember what the algorithm is called.
Deleted Comment
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?)
One of the genius ideas behind Element was the ecosystem of clients services that attach to rooms, and in some cases XMPP does not reach those expectations. I do plan on a redeployment soon after creating a new technical scope for its use.
I like what I can observe of the new admin interface. I hope it can come to include security and configuration check guidances to provide tools for admins of all skillsets to properly configure their servers, and related TURN-or-not and storage.
Matrix is bigtime like XMPP - I don't think it's going anywhere anytime soon. Thankful for all that it has provided to our organizations.
That said, I would love to hear your experience running an XMPP server. Do you still run it?
(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.
At least on the iOS app you can, just tested it. I run my own postfix/dovecot, so shouldn’t require any esoteric configurations.
b) yeah, X solves it (via sliding sync)
b) Unfortunately, X breaks other important things, like audio/video calls. It currently feels like an alpha-quality release: buggy and lots of missing features. Not ready for widespread use.
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).
In short: the complete lack of user-facing easy to use controls for data retention and culling in the Matrix (Element) clients is a deal killer for me. That painful experience taught me a lesson - now when I test something new, one of the first things I look for is "how do I extract from this thing?". I never want to go through my Matrix extraction pain again, so a personal life lesson was learned.
Edit : 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 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.
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! :-)
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 also had an intra-company Matrix server running completely on a company internal LAN, with no Internet access, so there is no inherent need for it to be on The Internet.