[HN Gopher] Self-hosting a Matrix server for 5 years
___________________________________________________________________
Self-hosting a Matrix server for 5 years
Author : the-anarchist
Score : 231 points
Date : 2025-12-01 11:26 UTC (11 hours ago)
(HTM) web link (yaky.dev)
(TXT) w3m dump (yaky.dev)
| ekjhgkejhgk wrote:
| And I thought that XMPP felt broken...
| a3w wrote:
| Now you can feel twice as broken. That is what new, modern
| standards deliver. Is this part of XCD #927 or another one,
| too?
| ekjhgkejhgk wrote:
| XMPP is 26 years old, Matrix is 11 years old.
| Jnr wrote:
| XMPP felt great when compared to Matrix. Matrix was in a bad
| state some years ago when I hosted it for a while, and seems
| like it still is the same messy state. I avoid it as much as
| possible but for some reason there are communities using it.
|
| At this point it should just die so people would be motivated
| to replace it with something better.
| tcfhgj wrote:
| People are motivated to replace it with something better,
| it's called Matrix 2.0.
| Orygin wrote:
| Do they plan to fix the fundamental issues of Matrix in 2.0
| or should I wait for 3.0?
| tcfhgj wrote:
| you could be less vague
| Orygin wrote:
| I could, that's why the link has a few more words about
| the issues with matrix.
| Jnr wrote:
| I tried it a year ago when it was introduced, it did not
| work. Is it stable now?
| this_user wrote:
| Which perfectly fits the Matrix ethos of everything
| constantly being rewritten or replaced with something new
| that only implements half the features before the original
| thing is ever finished.
| jimkleiber wrote:
| 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.
| nehal3m wrote:
| 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
| pferde wrote:
| 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.
| wkat4242 wrote:
| 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.
| pferde wrote:
| 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.
| wkat4242 wrote:
| Yes but even for a web service the attack surface is pretty
| big. Lots of obscure URLs and the code isn't that clean
| either.
| styanax wrote:
| 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.
| tcfhgj wrote:
| a) is really not a big issue any more
|
| b) yeah, X solves it (via sliding sync)
| bronson wrote:
| 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.
| jedahan wrote:
| I felt bad making a long thread once I opened Element X and
| saw it didn't have support for threads.
|
| 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.
| Arathorn wrote:
| this is wrong - the threads support in labs lets you
| create threads and navigate into them as you expect.
|
| what you are describing is the old threads workaround
| which predates the proper solution in labs which should
| exit labs asap.
| kassner wrote:
| > you can't correct a typo in a sent message in Delta
|
| At least on the iOS app you can, just tested it. I run my own
| postfix/dovecot, so shouldn't require any esoteric
| configurations.
| Arathorn wrote:
| 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.
|
| 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).
| salzig wrote:
| Thanks for mentioning Delta - https://delta.chat/ and
| implicitly https://chatmail.at/
| mcluck wrote:
| 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
| jchw wrote:
| I'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 abruptly become
| defunded and essentially unmaintained. Alas, that's exactly what
| happened not too long after I made that choice. Despite showing
| no interest in maintaining it, New Vector still found it
| necessary to relicense their abandonware under the more
| restrictive AGPL license. Good priorities. Then, when a security
| patch was needed, a new release was rushed out that included not
| just a security fix, but also a bug that caused Dendrite to
| completely stop processing messages for minutes at a time
| multiple times a day. (This only got fixed _months_ later by a
| volunteer.) Joining large federated rooms on Dendrite took so
| long that I thought it was just broken; it could take hours to
| days to complete the operation! There was even a brief period
| when Element actually didn 't even support Dendrite, leaving
| everyone locked out. Dendrite has never supported Element X, and
| the old sliding sync proxy was never updated to support the new
| simplified sliding sync either, which means you're stuck with the
| old slow sync and no support for things that require it. Also,
| most appservers still don't work right on Dendrite either. I got
| Mautrix-Discord working, but only for DMs.
|
| 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.
| philipallstar wrote:
| > 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.
|
| 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.
| jchw wrote:
| In a healthier ecosystem with many stakeholders and sponsors
| this is less of a concern. However, instead of Matrix
| Foundation gaining more independence, it seems like almost
| everything moved out of the Matrix Foundation and into a for-
| profit company. Clearly, things didn't go according to plan.
|
| 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.
| Arathorn wrote:
| I get the frustration that Dendrite dev has stalled, but
| the fault here is not of an evil take-over by Element
| (given Element wrote both Dendrite and Synapse in the first
| place) but simply neither Element and Matrix Foundation
| having the $ to do be able to maintain two homeservers
| simultaneously.
|
| > 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.
| JadedBlueEyes wrote:
| 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%)
|
| To add on to that, none of their customers use it, and there's
| no real community around it, unlike the independent Conduit-
| family servers that make up that remaining 11%.
|
| 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.
| maelito wrote:
| 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 telegram 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.
| Almondsetat wrote:
| >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.
| a3w wrote:
| 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.)
| Almondsetat wrote:
| >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.
| everforward wrote:
| I think they're talking about Solid, Tim Berners-Lee's
| newer venture: https://en.wikipedia.org/wiki/Solid_(web_dec
| entralization_pr...
| dust-jacket wrote:
| 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.
| bityard wrote:
| I don't agree with it myself, but there are people who seem
| to want to frame "the right to be forgotten" as a privacy
| issue.
| Almondsetat wrote:
| Even if it were a privacy issue, it would be impossible to
| enforce it technologically via FOSS software, because, by
| definition, the user at the other end could run a forked
| version with remote deletion disabled.
| rapnie wrote:
| Just one example, but trying to get that revenge porn off
| the web, can be seen as an attempt to restore ones privacy.
| Where others should not have the right to continue to peek
| into ones private life.
| bityard wrote:
| That's not quite the kind of thing I was talking about. I
| think that is generally already covered by current laws
| in most places?
|
| The right-to-be-forgotten advocates argue that everyone
| should have the right to demand that any trace of their
| previous online existence be deleted. On social media of
| course, but also independent web forums, chat logs, git
| commits, etc.
| tenthirtyam wrote:
| 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.
|
| Can't remember what the algorithm is called.
| gabrielhidasy wrote:
| Isn't the scheme simply agreeing in a shared key and both
| using it? I'll know that the message is from you if it's
| signed with that key and is not from me and vice versa, but
| neither of us can prove who created the message.
| upofadown wrote:
| No particular name. Just deniability. I personally like to
| call this particular scheme, deniability through claimed
| forgery. Not particularly clever. You just provide your
| correspondent with what they need to forge your messages
| after the end of the session.
|
| I don't know if it actually could work in practice:
|
| https://articles.59.ca/doku.php?id=pgpfan:repudiability
| XorNot wrote:
| Off The Record chat did this.
|
| https://en.wikipedia.org/wiki/Off-the-record_messaging
| progval wrote:
| > 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.
| wahern wrote:
| 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.
| progval wrote:
| 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.
| Arathorn wrote:
| > 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.
| broken-kebab wrote:
| 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.
| Almondsetat wrote:
| 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.
| broken-kebab wrote:
| I don't know such definition frankly. And to the best of my
| knowledge there are plenty of things which people call
| "protocols" strongly prescribing actions non-verifiable in
| the very sense you used. That said I'm not here for a
| terminological discussion. We may call it green cheese, but
| it's still a useful feature.
| Almondsetat wrote:
| Nobody claimed it isn't a useful feature. The only claim
| I made is that it cannot be mandated with an open
| protocol, so if you expect 100% adherence in the name of
| privacy, you're setting yourself up for disappointment.
| broken-kebab wrote:
| Good, nobody claimed any expectation of 100% adherence as
| well!
| nicoco wrote:
| 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 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.
| AJ007 wrote:
| 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 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?)
| wkat4242 wrote:
| 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.
| nicoco wrote:
| 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.
| broken-kebab wrote:
| >pinky promise security
|
| 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.
| davorak wrote:
| It's hard to explain to a non technical user. Something
| like "We tried to delete the message, but some of the
| people who received your message might still have a
| copy." Does not sound great and is going to be hard for a
| non technical user to understand and hard to implement in
| a way that a non technical user will find satisfying.
|
| 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.
| wkat4242 wrote:
| That is exactly what happens in WhatsApp though. Maybe
| the message isn't there anymore but it used to say pretty
| much exactly that.
| zenmac wrote:
| 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?
| XorNot wrote:
| There's a difference between "I have an active adversarial
| actor" as a security model and "sometimes I send something
| I don't want to and want to delete it, the people watching
| are friends and acquaintances and are not deliberately
| preprepared to collect kompromat".
|
| When I delete a message off Signal chat, the expectation is
| that the chat members are agreeing by social contract to
| abide by that.
| miloignis wrote:
| True, and Matrix has the weaker version of the feature:
| https://spec.matrix.org/v1.16/client-server-api/#redactions
| It should absolutely work in normal situations across all
| servers and most all clients.
| thaumasiotes wrote:
| > 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.
| 24t wrote:
| 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.
| chrismorgan wrote:
| > _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?
| udev4096 wrote:
| I use sqlite for synapse (since ~2 years) and I haven't noticed
| any corruption at all. I am in lot of rooms (20-30) with 1k-2k
| users in a lot of them and the db size is 8.8G currently
| lousken wrote:
| 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
| 0x1ch wrote:
| 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'm over it.
| lousken wrote:
| 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.
| 0x1ch wrote:
| None of my friends ever migrated from Discord to my server
| for over a year, so not much is lost. I'll join more
| actively maintained instances to stick around the
| communities and chats I found for myself.
| AAAAaccountAAAA wrote:
| https://m.youtube.com/watch?v=z0ULOptq2vk&pp=0gcJCR4Bo7VqN5
| t...
|
| They seem to plan to rewrite the desktop client next.
| Teever wrote:
| 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?
|
| What does running a matrix server get me in 2025?
| seryvtva wrote:
| 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.
| polski-g wrote:
| Yes they fixed that about a year ago. It was a breaking
| change and required everyone to update their server software
| config.
| chromatin wrote:
| Conduit [1] has retention policies [2] for media and
| attachments!
|
| [1] https://conduit.rs/ and https://gitlab.com/famedly/conduit
| [2]
| https://gitlab.com/famedly/conduit/-/blob/next/docs/configur...
| nonamesleft wrote:
| Ran synapse for a few months, figured out all the tui clients are
| either abandonware or broken (originally thought i could use
| bitlbee, and did the install before realizing it was unusable).
|
| 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.
| Arathorn wrote:
| iamb is pretty good and not abandonware, fwiw:
| https://github.com/ulyssa/iamb
| df0b9f169d54 wrote:
| 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
| udev4096 wrote:
| I have been hosting synapse for 2 years now and it's been a
| smooth sail. I don't recall having any major breaking changes,
| most updates are smooth. Element client itself is definitely PITA
| but it's getting better
| Barathkanna wrote:
| 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.
| omnimus wrote:
| 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.
| Arathorn wrote:
| If you want a simple docker-compose for Matrix, you can
| always use https://github.com/element-hq/element-docker-demo.
|
| The reason Element ships ESS Community as kubernetes helm
| charts is simply so that the officially supported distro is
| as close as possible to the thing we have to support for the
| big govtech customers, where docker compose simply isn't
| going to cut it. Perversely, that means that ESS Community is
| pretty bulletproof (even if the scaling stuff is missing),
| but comes at the expense of having to run k8s.
| The_President wrote:
| 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.
| Arathorn wrote:
| We did address the elephant eventually with
| https://github.com/element-hq/element-admin a few months ago.
|
| 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?)
| The_President wrote:
| 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.
| The_President wrote:
| 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.
| The_President wrote:
| I want to give credit, and that is the early rust iOS version
| of Element X I tried was very slick and quick, but I didn't try
| it for long.
| ekjhgkejhgk wrote:
| 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?
| jamesbelchamber wrote:
| > 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.
| toastal wrote:
| 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.
| jamesbelchamber wrote:
| 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.
| JadedBlueEyes wrote:
| > 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.
| Youden wrote:
| I set up Whatsapp and Telegram bridges with Tuwunel today. The
| config file for mautrix-whatsapp indicates Dendrite should work
| as well so it seems just about every server implementation
| supports bridges?
| Aurornis wrote:
| > 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.
| Arathorn wrote:
| 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.
|
| 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 wrote:
| 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
| omnimus wrote:
| 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.
| Arathorn wrote:
| There'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
| lousken wrote:
| > The admin panel is at https://github.com/element-hq/element-
| admin
|
| 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.
| bronson wrote:
| You claim:
|
| > 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.
| 3np wrote:
| > > Onboarding is bad
|
| > 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.
| alexnewman wrote:
| 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.
| pelzatessa wrote:
| Been selfhosting synapse for about 1.5 years in a docker compose
| setup using bunkerweb (formerly "bunkerized nginx", which better
| explains it premise) reverse proxy, eturnal for TURN and
| postgres, also recently added livekit and MAS for element call
| and element X compatibility. All that runs on a small 2vcore/4gb
| VPS, and it runs pretty good, I experience a server crash every
| half a month, but that may be caused by the fact that bunkerweb
| isn't the most lightweight solution (they actually require 8GB
| RAM minimum, so I'm already beneath the limit), and also because
| I run some other software (mailserver, ebook server, plex,
| etc..).
|
| 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
| chickensong wrote:
| > it runs pretty good, I experience a server crash every half a
| month
|
| I don't... what? How can you... arrrgh!
| CyberDildonics wrote:
| Wouldn't this just be called hosting?
___________________________________________________________________
(page generated 2025-12-01 23:00 UTC)