> Synapse is the only choice that supports bridges
This is not true, at least today. Continuwuity, which is an alternative server implementation, and its predecessors support bridges very well.
Self-hosting a Matrix server for 5 years
61–70 of 159 posts
Re: Self-hosting a Matrix server for 5 years
#62Earlier quoted context omitted.
Sure. 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…
I don't know what's wrong with XMPP other than the network effect collapsed when the GMail chat thing was killed, while the mobile client options were poor for a very long time. 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…
The GDPR is being neutered anyway because the EU caved in to Trump.
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.
Re: Self-hosting a Matrix server for 5 years
#63Regarding 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.
Re: Self-hosting a Matrix server for 5 years
#64Earlier quoted context omitted.
> 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.
But normally when you join a conversation and are not allowed to see previous messages, you don't see anything about them. A matrix server does.
Re: Self-hosting a Matrix server for 5 years
#65> While technically, Synapse can work with a sqlite database (and which at first seems like an OK choice for having 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.
Re: Self-hosting a Matrix server for 5 years
#66I've mentioned this here before, but it bears repeating. A couple years ago or so, I made the catastrophic choice to use Dendrite as my homeserver software. It seemed like a safe bet: it was supposedly lighter weight than Synapse, being written in Go instead of Python and with everything reengineered from the ground up. It didn't support everything, but nothing in the disclaimers made it seem like it was about to abr…
This doesn't really excuse it, but to give you some idea of why Element haven't spent any time on dendrite right now, here's a sample of active servers on the federation as of today:
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.
Re: Self-hosting a Matrix server for 5 years
#67There's a bunch of outdated info in here, unfortunately:
> 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
Re: Self-hosting a Matrix server for 5 years
#68Re: Self-hosting a Matrix server for 5 years
#69I'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.
Re: Self-hosting a Matrix server for 5 years
#70>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-…
> 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.
> Matrix also makes the entire event history (minus message content depending on room configuration) available to servers on join
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.