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.
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 are right, though I still prefer "weak feature" as a term :) There's enough value in such things. Cryptography crowd is concentrated on omnipotent Eve breaking ciphers, and that wrench from xkcd, but I dare to claim that majority of both commercial and private leaks happen just because well-intentioned users don't have enough capacity to keep track of all the things, and proverbially think twice. Features like "unsend", or timed deletion are indeed laughable on their purely technical merits, but do wonders saving users from grave mistakes anyway.
So if I was a dev on matrix/element and this feature came across my plate I would have to weigh it against features that I know can be implemented in a way which make technical and non technical people feel satisfied and better about the application.
In practice, in federated networks bad actors end up being blacklisted. It does not provide any "formal" guarantee, but… it tends to work fine enough. For this specific "deletion request" feature, of course it should always be seen as a convenience thing, and absolutely not about security.
As with many engineering things, it's tradeoffs all the way down. For instant messaging, a federated approach, using open protocols, offers what I value most: decentralisation, hackability, autonomy, open source. My options in this space are Matrix or XMPP. I have not attempted to self-host a matrix server, but have been very happy with my [prosody](https://prosody.im/) instance for almost a decade now.
Matrix has the appearance of being a drop in replacement for Slack or Discord, but the design decisions seem so compromised that the only explanation is they did manage to establish a (somewhat weak) network effect? It certainly is not a good look for an open source project to be running on Slack or Discord (free/cheap plans rugpulled or to be soon.) Then that leaves IRC, which has a network effect collapsing at a much slower pace.
I never got far enough to try hosting a matrix server, but reading the linked post -- Matrix definitely is not GDPR compliant. The combination of whatever end form of ChatControl the EU gets along with possibly hundreds of other laws across the world and individual US states makes me think the days of a public facing non-profit or small startup running a project like this are over. (Or maybe the future of open source is funding lawyers while the development is all done for pennies by AI?)
Not being chatcontrol compliant? That's a feature not a bug. Nobody wants that anyway. Just another stupid US lobby (Thorn).
A big organisation won't be able to run matrix for everyone no but that's the cool thing about it. People can run their own for smaller groups of people.
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.
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.
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.
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.
(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.
Someone let me know later that threads are hidden behind a Labs setting, but it only allows the client to reply to threads, but still exposes the entire thread inline for the channel which sucks up all the air in the chat.
what you are describing is the old threads workaround which predates the proper solution in labs which should exit labs asap.
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).
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.
Edit : I wonder how easy it is to backup a Matrix accounts's data. Conversations and files.
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.
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
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
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?
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.
At this point it should just die so people would be motivated to replace it with something better.
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.
This is not true, at least today. Continuwuity, which is an alternative server implementation, and its predecessors support bridges very well.
My experience as a administrator has been pretty good, perhaps it's because from the beginning I was optimistic, it suited my needs as I wanted a selfhosted, modern and fairly convenient communication platform. From what I recall, most problems during configuration were caused mostly by bunkerweb (or rather my inability to correctly set it up to proxy requests correctly and not hijack the 4xx and 5xx HTTP codes). Synapse itself has been a pleasure to maintain, but also bear in mind that I did not tinker with with it, I basically set it up and let it run for about a year and then added MAS and livekit.
Yeah, disk usage sucks, for about 5-10 active users and 1.5 year usage my postgres "schemas" folder clocks at 10Gibs. It doesn't include the media_store catalog where synapse keeps media (images, videos). The homeserver is federated and I joined a couple of big rooms in the past. Mechanics mentioned in the links below do help though:
https://matrix-org.github.io/synapse/v1.40/admin_api/purge_h...
https://github.com/matrix-org/rust-synapse-compress-state
Clientwise also sucks, but I think enough has already been said on this matter. But it's good enough to keep my nontechnical friends using it. They do hate it, but not enough to kick me in the arse. Would love to say that this proves that element clientside is usable, but I also have to admit that my friends are just hella good guys who would even write pigeon mail to me if I stopped using anything else for communication :) for me as a techie, element is obviously alright. Clunky, but works. I think clients simply need more time.
What irritates me is the Matrix authentication service (MAS), it's kind of a separate service for matrix homeservers that handles logins specifficaly. You can't use element X without it. However when it's enabled, you cannot log in from your client, instead a web browser opens and shows the login panel where you have to authorize, and then it should return to the client. Except in my case it simply doesn't :( I observed that for some reason chromium based browsers won't redirect back to the element app, and it doesn't know that the authorization has been granted. I managed to bypass it by copying the URL and opening it on firefox, but in one instance even that didn't work.
But other than that MAS problems everything has been fine from administration standpoint. I think it simply needs more time, as it already has traction, I see that a lot of new projects seem to include a matrix room in their social/communication channels, frequently it's the only option besides the bugtracker. And I'm willing to wait patiently :)
edit: added links for people who also struggle with disk space usage
Looked at current tui offerings now some years later, situation seems to be unchanged, the only client that ran back then was gomuks, and that has received a rewrite that hasn't reached feature parity yet.
I am probably the type of person referred to in the last part of xkcd 1782.
I legitimately could go on and I'm sure I've forgotten things. It's amazing how quickly my experience with Dendrite went from pretty good to nightmare.
I realized that nobody in charge at the Matrix Foundation or New Vector really cared enough about leaving people stranded on a completely broken server to actually do anything about it (and trust me, I'm not alone. In every single federated room I've ever been in, I've always seen hostnames with dendrite subdomains. I could see them pass by in the logs while joining servers was taking hours.) I honestly considered just leaving the Matrix ecosystem, but I wasn't alone on my home server, so I decided to do my best to fix the problem. I wrote a tool that attempts to migrate the data from Dendrite to Synapse. This is a complicated operation that really took a huge amount of effort to get working, but after a couple of months of failed attempts, I had a test where I was able to seamlessly perform the migration and have clients continue to work and stay in federated rooms. So after getting it "close enough", I went ahead and gave the migration a shot in production and of course, it didn't work very well. All of the user accounts were intact, but a lot of stuff was broken. People indeed stayed in federated rooms, but my room state migration was definitely not 100% correct. Despite this, though, after manually cleaning up the database a bit more, hackishly while live, it was mostly a success. I believe I am probably the first person to directly move from Dendrite to Synapse.
So now that I am on Synapse, have my thoughts on Matrix changed? Yes. It's significantly better using Synapse, without question. The ecosystem is still a mess, but everything about Synapse is less broken than Dendrite. There are so many features Dendrite just doesn't do, like URL previews.
Why not contribute to Dendrite? Honestly, I don't want to. Their CLA sucks and they're not going to change it for me, and I don't think they're really going to spend time reviewing PRs given the circumstances. If I'm going to contribute to a project without retaining my rights I'd prefer to be on payroll. That's not something you should get from a community member. Either change the CLA to guarantee the project must stay open, or don't expect any free contributions.
Why not post my migration tool? Well honestly, for starters, it's not a very high quality tool. I could probably do some good for the Matrix ecosystem if I could get this tool in much better shape and have it migrating complex room states correctly, but I don't even know if I want to help anyways. This should've never been my problem. I will fully admit that it was my bad choice that got me here, but I really think it can be forgiven: nothing I saw suggested to me that Dendrite was on the way out. On the contrary, everything suggested it was the future, and just simply not ready for large scale usage yet. I'm bitter. I spent a lot of hours on this problem and I feel like hours spent on the Matrix ecosystem won't be repaid.
I hate to be this cynical, but it's just how it is. It's a mess. I didn't bother going into the other messes that still exist when using Synapse, like the seemingly many different ways that VoIP can work in Element and Element X, and the fact that Element X seems to only support a newer VoIP protocol that Element on desktop does not. (Surprise! There is no Element X on desktop...)
Matrix has some other downsides, that I think are tolerable but definitely make me a bit bummed. It leaks quite a lot of metadata to the homeservers, which is kind of alright, but I do think it's a bit sad; even room names are not encrypted, clearly it would be possible to do better. The ecosystem of clients is sad; Element is the only one that is feature complete and while I think it has improved quite a lot I still would prefer a native application over a web view. (You kind of need a webview if you want feature parity though, since group A/V in Element desktop seems to just use a Jitsi iframe...)
The upside is that it is federated and at least messages and files are E2EE in DMs and optionally for groups. I do like that.
Personally though the federation thing feels a bit off to me. I know it's a pipe dream, but it just feels like 1-on-1 and small group DMs should be roughly peer-to-peer. Servers should be for chatrooms and relays. The problems I see are mobile notifications, offline messaging, and discovery. I have wondered if a model like AT proto could get you there for DMs. I would like to try to prototype something some day, but I know that at this point the XKCD 927 count for IM software is pretty insane, so if I'm going to throw my hat into the ring it better be worth it.
Maybe some day I will be less bitter. I mean, Matrix is free, how much can I really be angry if it didn't work how I wanted it to. But, it's hard. I tried to buy in hard, and wound up making a lot of trouble for me and a small group of people that I inadvertently looped into my own mess. I trusted Matrix because it seemed to be the leading option, but definitely I will now be much, much more careful before adopting an ecosystem into my life and the life of people around me. For example, I still have no ActivityPub server... Maybe it's better if I just wait and see what happens there before jumping in, if I'm going to.
2025-12-01
synapse : 10068 (85.8%)
conduit : 476 (4.1%)
dendrite : 369 (3.1%)
continuwuity : 303 (2.6%)
Dendrite was a bet for two things: Could they make synapse faster? Yes. Synapse is faster now, and Synapse Pro is apparently even faster. And, can we make Matrix peer to peer? They ran out of money, and didn't have any customers who would fund it themselves. They're left with this project that is idling without a community, a customer, or a reason to exist.
Apparently, they have some funding to do work on the foundational parts of p2p now, but that will take a long time, and Dendrite is unlikely to be a part of that for a while, possibly at all (the Rust ecosystem seems to be where Element invested their time on the client, while Beeper invested in Go).
In the end, a lot of Element's pain is because of ambitious technical decisions made without a way to back them up practically or business wise. Things would be amazing if everyone working on Matrix had infinite time and money. Unfortunately, they don't, and Element is eating the consequences for acting like they did for a while. They seem to be better now, though.
Sorry this is your experience - my only small comment on this last part is here: if there's no financial incentive to keep things running then it is very possible that they won't. Money isn't some evil thing we should alternatives to. It's how we value relatively our time and effort vs other people's time and effort.
Most of us just running homeservers are just random people who have no power over this situation and not enough money to make a dent in their budget needs. For us, Matrix was sold as an open E2EE chat system, and we bought in. Does us buying in do anything for Matrix Foundation/Element? I dunno. Maybe it helps sell Matrix to get broader adoption. Either way, we took a gamble on it, potentially instead of other solutions.
Now the free and open source Matrix homeserver has to compete with a closed source commercial one. I sort of hope there's a happy ending on this one, but it sure looks dicey to me right now.
> Now the free and open source Matrix homeserver has to compete with a closed source commercial one
This isn't really the case - normal open source Synapse is the core focus for Element, and the vast majority of work is going into that, including performance work. Synapse Pro is "just" for scalability and HA for big government-scale deployments - https://element.io/blog/scaling-to-millions-of-users-require... etc. But all the schema work etc which supports that goes into FOSS Synapse.
> Does not have an admin panel
The admin panel is at https://github.com/element-hq/element-admin (but it's relatively new, so many folks haven't noticed it exists)
> No image captions > > This is silly, but while (official?) bridges support image captions, official Element app does not.
Element Web & X support captions. (Element Web doesn't currently support authoring them, but can display them - obviuosly this is on the todo list though).
Element Classic has basically not been touched in 2.5 years, unfortunately, and so yes - doesn't support them. But at this point the old app is just not being developed; we don't have bandwidth to do both.
> Slow notifications
This sounds like it might be overloaded server problems ftr.
> Element X is Slower > Somehow, it is slower. Clicking on a conversation takes 0.5-1.0 seconds to load it, compared to almost instant load on Classic.
This was an Android specific bug which was fixed a few weeks ago; EXA should now be instant as it should be, at least on nightlies: it was stuff surrounding https://github.com/matrix-org/matrix-rust-sdk/pull/5841 and https://github.com/matrix-org/matrix-rust-sdk/pull/5854. Unsure if the fix has made it into a build yet.
EDIT: the fix shipped in stable Element X Android a few weeks ago.
> Conversations are sorted by... who knows. It is not recent nor alphabetical.
It should be by recency.
> Onboarding is bad
Sorry, but you have to run an auth server (matrix-authentication-service) if you want Element X to work.
EDIT: if i've got any of the above wrong please just say, rather than downvote :D
I think author uses regular synapse install and there is no apt package for element-admin, manual build would be required with no update process.
> Element Web & X support captions - i think this is honestly the worst of both worlds
if app_old has features A,B,C,D and app_new has A,C,D,E it frustrates both groups of users. Which app are you actually supposed to use? Having feature parity with the old app is essential before moving on with newer features. And I am still waiting for that to tell people to switch.
> There's a bunch of outdated info in here
Then link to a 3 week old issue and a repo that didn't meaningfully exist until two months ago? Wow.
If you consider that to be outdated, then that reinforces the OP's point about Matrix being difficult to host.
> at this point the old app is just not being developed; we don't have bandwidth to do both.
You're wording that as if it's a good excuse for providing a poor user experience. It's not.
> Sorry, but you have to run an auth server (matrix-authentication-service) if you want Element X to work.
This is a bit outrageous IMO. Actually breaking and deprecating the classic auth and requiring a new server component to keep the only actively supported client (which still can't properly manage keys or sessions on its own, like classic Element can, even as non-verified sessions are being disabled) is a bit rich.