[HN Gopher] Matrix messaging gaining ground in government IT
___________________________________________________________________
Matrix messaging gaining ground in government IT
Author : rbanffy
Score : 207 points
Date : 2026-02-09 11:53 UTC (11 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| bsaul wrote:
| I wonder why matrix isn't more widerspread at this point. It's
| open, it's e2ee, it works, it has client lib for integration with
| any tool..
|
| What makes it not more popular ? Is it the federated approach ?
| The client applications that don't look really fancy ?
| bratwurst3000 wrote:
| mostly the federate aproach. Most people dont want to think
| about anything network related.
|
| Element is ok as an app imho
| coolius wrote:
| For me the issue that prevented me from really using matrix is
| that none of the big clients support multiple servers. As a non
| enterprise user, this has prevented me from seriously adopting
| it several times.
| Arathorn wrote:
| Element X _finally_ has this on Android (in Labs) now. Web &
| iOS will follow.
| tionis wrote:
| Fluffychat does and I would argue is one of the big ones. Its
| however quite mobile optimized (basically more like WhatsApp,
| less like slack).
| nkmnz wrote:
| Search is essentially broken and completely useless. If I'm
| mistaken, maybe someone might chime in and explain how I can
| make it work. But right now, the only way to search for
| messages is to export them and search in the text file.
| j1elo wrote:
| If that's true, it sounds terrible, and a reason enough to
| not consider it at all. So much of the work in bug
| organizations is about just searching for past conversations
| when a similar issue had been discussed... Search must be
| flawless.
| olafmol wrote:
| It's open source right? You know what to do ;)
| rolymath wrote:
| This is the fastest way to get people to say "I hate
| proprietary solutions but at least they work"
| throwaway150 wrote:
| Then you should use proprietary solutions. Open source
| solutions are written by developers for themselves. They
| are not writing it for you. They have no reason to write
| them for you. You are not paying them. It is a labor of
| love they are doing for themselves.
|
| Yet as a bonus they are offering it to you for free as a
| gift with the hope that if it doesn't work for you, you
| can improve it or hire someone you can.
|
| If you only care about consuming open source but not
| contributing, by all means you should buy proprietary
| solutions.
| jodrellblank wrote:
| This is a subthread of "I wonder why matrix isn't more
| widespread at this point". When people reply why it
| doesn't work for them, that's not time for "you didn't
| say thank you".
|
| > " _They are not writing it for you._ "
|
| From matrix.org[1]: 'The values we follow are:
| Accessibility rather than elitism. Empathy rather than
| contrariness.' ... 'act as a neutral custodian for Matrix
| ... for the greater benefit of the whole ecosystem, not
| benefiting or privileging any single player or subset of
| players. For clarity: the Matrix ecosystem is defined as
| anyone who uses the Matrix protocol. This includes (non-
| exhaustively): End-users of Matrix clients. Anyone using
| Matrix for data communications'
|
| > " _They have no reason to write them for you._ "
|
| How are Matrix/Element going to get anywhere with their
| mission to replace proprietary chat networks if they
| don't write their new one for millions of ordinary people
| to be willing to use?
|
| [1] https://matrix.org/foundation/about/
| throwaway150 wrote:
| > This is a subthread of "I wonder why matrix isn't more
| widespread at this point".
|
| Exactly. My point is that the question itself is
| misplaced. It reflects a consumer mindset, which makes
| sense when you are paying for a product, but feels out of
| place with open source projects built largely through
| voluntary effort.
|
| However noble the foundation's mission sounds, the
| reality is that Matrix is a complex protocol sustained by
| people investing their time and energy because they care
| about it.
|
| It will not magically solve every user problem. If
| something does not work for you, the constructive path is
| to help fix it or at least propose concrete improvements.
| Otherwise, choosing a proprietary solution is perfectly
| reasonable but expecting open source projects to behave
| like consumer products is out of place.
| rolymath wrote:
| OK great. I guess you answered why Matrix is not more
| popular.
| throwaway150 wrote:
| Yes, it is not popular, for the reasons I already
| mentioned.
|
| What puzzles me is why so many HN comments, including
| yours, frame this purely in consumer terms: "If this open
| source tool doesn't meet my needs, I'll switch to a
| proprietary one."
|
| And that is perfectly fine. Use whatever works for you.
| No issue there.
|
| What seems misplaced is the expectation that Matrix must
| be popular. Why should it be? It is not your project, and
| you are not contributing to it. Where does this
| expectation of its popularity come from?
|
| Matrix already serves its developers and contributors. If
| it does not serve you, you can either help improve it or
| choose a proprietary alternative. Both are reasonable
| paths.
|
| What feels off is the dismissive tone suggesting that if
| Matrix is not widely adopted, something must be wrong and
| proprietary options are therefore superior. In reality,
| this is just how open source works: projects exist to
| serve those who build and support them, not necessarily
| the mass market.
|
| There is nothing wrong with an open source project not
| meeting everyone's needs, leading some people to choose
| proprietary alternatives. Remarks like "This is the
| fastest way to get people to say: I hate proprietary
| solutions but at least they work" or "OK great. I guess
| you answered why Matrix is not more popular" are not
| really the decisive critique you think they are.
|
| Open source and proprietary software each have legitimate
| roles. For some use cases and users, open source tools
| are a better fit. For others, proprietary solutions make
| more sense. Popularity alone is not a meaningful measure
| of value and choosing what works best for you is entirely
| reasonable either way.
| ilvez wrote:
| > What seems misplaced is the expectation that Matrix
| must be popular. Why should it be? It is not your
| project, and you are not contributing to it. Where does
| this expectation of its popularity come from?
|
| Partly it's the wish and need for particular project to
| succeed. They use/like it and want their friends to do
| so, but then getting brought down by the reality. And
| communication software is all about critical mass..
|
| Also the promises given and then seeing them not
| delivered. Everyone can't be builders..
|
| Just to be clear, have been using Matrix from around 2015
| with friends and family. Keeper of souls..
| karel-3d wrote:
| Get into an online argument with the developers about
| what is the right approach and which dependency is to
| blame?
| throwaway150 wrote:
| There is no need to get into an online argument with the
| developers. The open source software is still offered to
| you as a gift. You can modify it however you need and
| keep it for yourself.
|
| The developers developed the open source software for
| themselves. Doesn't work for you? Too bad. But they are
| not going to develop it for _you_. Definitely not, when
| you are not paying them.
|
| If it doesn't work for you, you shouldn't think, "Oh, I
| need to get into an online argument with the developers."
| Here's what you do.
|
| 1. Develop the fix/feature you need for yourself. If you
| cannot do it yourself, hire someone who can.
|
| 2. Send a pull request to the developers. But don't
| expect them to merge it. Remember they developed their
| stuff for themselves. You developed your stuff for
| yourself. If they merge, great. If they don't merge,
| you've still got your stuff for yourself.
|
| 3. If they don't merge your stuff, you could maintain a
| fork. Yes, it's a pain to keep your fork updated but you
| need to do your own work. Nobody else will do your work
| for you.
|
| If all this is too difficult for you, why even consider
| open source? Just use proprietary software.
|
| I truly don't understand the self-entitled HN comments
| that think for some strange reason that someone else
| should give you a software for free and then do all the
| work for you.
| Klonoar wrote:
| You need to learn how to read sarcasm.
| throwaway150 wrote:
| You need to learn
| https://en.wikipedia.org/wiki/Poe%27s_law
| Klonoar wrote:
| No, I don't. It doesn't apply here because the comment
| you responded to is written in such a sarcastic manner
| that you have to be willfully obtuse to miss it.
| throwaway150 wrote:
| Did you even read the link I gave you? It already
| addresses exactly the scenario you mention. That no
| matter how obviously sarcastic the comment is, it can
| still be seen as a sincere comment. Please re-read it.
|
| But TBH in this case I couldn't tell whether the parent
| comment was sincere or sarcastic. But that's not the
| point. Poe's law applies even when the comment is
| obviously sarcastic.
| j1elo wrote:
| Meh, already got enough in my plate. That "do it yourself
| if you need it" is technically correct for FOSS, but only
| when people _need_ it, not the case here until it gets so
| popular that the whole organization decides to use it ;-)
| Arathorn wrote:
| Unencrypted room search should Just Work for unencrypted
| rooms (it uses postgres FTS under the hood).
|
| Encrypted room search should also Just Work... but only on
| Element Desktop (which uses tantivy to do clientside search).
| We are in the process of porting this to Element X (and
| Element Web), but after an initial spike over the summer
| we're waiting for either funding or manpower to finish it.
| pkulak wrote:
| I just added search. ;)
|
| https://github.com/pkulak/matui/releases/tag/v0.6.0
|
| For encrypted rooms it just starts pulling messages down
| and looking for substrings... but it's actually works
| pretty well if you don't want to search back to the
| beginning of time.
| Arathorn wrote:
| cool! would be even cooler to hook it up to
| https://github.com/matrix-org/matrix-rust-sdk/issues/5350
| when it should then just work?
|
| matui looks super fun - you should come tell
| https://matrix.to/#/#twim:matrix.org about it :)
| nh2 wrote:
| What about 1:1 chat?
|
| I'm using Element X and there seems to be no search button
| for messages at all.
|
| So I cannot even search for "shopping" to find the shopping
| list, or "address" to find the address a friend sent me
| some days ago.
|
| It is simple to see why the normal user will have a bad
| everyday experience.
|
| The app uses 160 MB user data on my phone which fits a lot
| of text, why cannot I just search it?
| andylynch wrote:
| I think it's a few things
|
| - lots of places kind of Teams by default - or Slack or discord
| m, even WhatsApp - or in intensive cases, things like
| Refinitiv, Bloomberg, and, Symphony , which is kind of
| federated, but adds all the automation and also governance
| stuff needed for 100MM trades via IM and the like.
| blitzar wrote:
| > governance stuff needed for 100MM trades via IM
|
| We have come a long way from Yahoo messenger days.
|
| https://www.reuters.com/article/technology/oil-traders-
| prepa...
| tapoxi wrote:
| Enterprises get Teams for free with O365, or use Slack if they
| really care about the experience.
|
| Most individuals don't care and use iMessage/WhatsApp. Those
| that do use Signal since it's dramatically easier.
| rolymath wrote:
| Teams has not been free with O365 for years now.
| Quarrel wrote:
| I use Teams all the time (although not because it is what
| I'd choose..).
|
| Mostly just completely free tier, although I do have O365.
|
| On the free tier I think the main restriction is the 60
| minute limit on groups > 2?
|
| Don't get me wrong, MS are almost as bad as Google in
| segregating their chat/video call/conferencing offerings,
| and even if you did know the names last week, they've
| probably changed them this week.
| rolymath wrote:
| No I mean they were recently forced to unbundle by the EU
| or face monopoly claims. I guess they saw people paid
| anyway and unbundled everywhere else.
| galbar wrote:
| I am a daily user, family and friends chatting on Matrix.
|
| My take is that there are two layers of friction:
|
| a) people that care about chat encryption and would be willing
| to change, already did, to Telegram and/or Signal. "I'm not
| going to install yet another chat app" is a real answer by a
| friend of mine
|
| b) no one wants to either host their own server, nor pay
| someone to host it for them. If it wasn't for me and a one of
| my friends, none of the people I chat with daily would be on
| Matrix.
|
| And yes, there is the matrix.org server. Out of the ~13 people
| I chat frequently with, 1 is on matrix.org. "What's the point
| of changing apps if I'm still going to be using the centralized
| server" is another answer I've gotten.
|
| I don't know what the solution to this dynamic is other than
| us, the power users, setting it up and paying for the group of
| people around us.
| INTPenis wrote:
| What about maintaining encryption for an entire room of
| clients? I heard it's very difficult and prone to errors. Do
| you enforce it?
| Arnt wrote:
| I use matrix. Every chat room I use is unencrypted and all
| have at least one matrix.org user. I assume it can be
| encrypted but the usability is such that in practice it's
| cleartext.
| cge wrote:
| As a counterexample: I use Matrix along with ~30-50
| people, on a federated server, and every room is
| encrypted. After sufficiently stressing to people that
| they need to save their secure backup key, we've had few
| problems with encryption usability.
| Valodim wrote:
| > a) people that care about chat encryption and would be
| willing to change, already did, to Telegram and/or Signal.
|
| It continues to baffle me that the "telegram is encrypted"
| spin is still widely believed, even on a forum like this.
| Telegram is for 99.9% of intents and purposes not encrypted.
| Anonyneko wrote:
| And even when you do enable encryption of the chat
| contents, the unencrypted metadata is often enough for
| security services to make a suspect out of you. Granted,
| this is mostly a concern for Russian and Belarusian users.
| dizhn wrote:
| What is encrypted and how is public information. If it
| doesn't fit your use case don't use it. There is no "spin".
|
| People were spreading this kind of FUD until last week when
| all of a sudden people started claiming it was self evident
| that "of course Meta can read your WhatsApp messages". I
| don't get this kind of weird fixation with a product. I
| suspect it's two things. Perceived Russian origin and that
| one guy dared write a crypto library rather than using
| their own. I agree with the latter. The prior is not even
| true the way people understand it to be. I for one like the
| stickers. Shoot me :)
|
| We even give companies like Google which we know for a fact
| is looking at all of our data a free pass with the super
| western "privacy policy" cop out while judging other tools
| with a different set of rules.
|
| Another darling is Signal who refused to stop collecting
| phone numbers until recently even though they never needed
| it, does not allow open source or other clients to use
| their servers (and won't release the actual server code)
| and frankly does not work half as well as Telegram in terms
| of UX.
|
| All of this is really confusing for me.
| palata wrote:
| > All of this is really confusing for me.
|
| Yep, I can see that.
|
| The problem with Telegram is that it is not an E2EE
| messaging platform, period. It is a non-E2EE platform
| that has an option to encrypt 1:1 messages with a
| criticised algorithm. Whoever uses Telegram does it _for
| all the nice features that are not E2EE_.
|
| > all of a sudden people started claiming it was self
| evident that "of course Meta can read your WhatsApp
| messages".
|
| Because some people say stuff like this doesn't make it
| right. WhatsApp messages are E2EE encrypted, unlike
| Telegram. There are other things to criticise with
| WhatsApp, but not that.
|
| > Signal who refused to stop collecting phone numbers
| until recently even though they never needed it
|
| As you said, you're confused. Signal needed the phone
| numbers for convenience, so that you could reach your
| friends. Exactly the same reason as WhatsApp. Could they
| have done without it? Yes, but maybe Signal would not be
| as popular. That's a valid tradeoff, and Signal never
| lied about it. Also having to share your phone number
| with Signal is still better than any of the other popular
| platforms. Anything that is "more private" than Signal
| hasn't managed to get on the map.
| dizhn wrote:
| > Because some people say stuff like this doesn't make it
| right. WhatsApp messages are E2EE encrypted, unlike
| Telegram. There are other things to criticise with
| WhatsApp, but not that.
|
| Is this verifiable fact or Meta's claim? As far as I know
| neither the server nor the client are open source.
| palata wrote:
| > As far as I know neither the server nor the client are
| open source.
|
| That is correct. I have a few things to add:
|
| - Meta employees (and there are many of them) have access
| to the sources. So if Meta was downright lying about it,
| chances are that _someone_ would leak it.
|
| - Thanks to the Digital Markets Act, we see that the
| encryption protocol _exposed_ by Meta for
| interoperability is based on Signal. If Meta wanted to
| lie, they would have to either use a different protocol
| internally (but again, we know that the Signal authors
| contributed to integrate the Signal protocol in 2016, and
| a Meta employee could relatively easily see if WhatsApp
| had removed Signal and re-added it just for interop
| recently) or use the Signal protocol but have the app
| send the content of the messages to the Meta servers
| after decryption (which would be fairly easy to see by a
| Meta employee).
|
| - People who don't want to trust WhatsApp should use
| Signal. Moving to Telegram because of a lack of trust
| would be weird, as Telegram is _most definitely not E2E
| encrypted_.
|
| In other words, the WhatsApp situation is not perfect,
| but telling people to move to Telegram because "it's
| safer" is actually dangerous. Telegram is strictly less
| private, period. Signal is strictly more private.
|
| I am not saying people shouldn't use Telegram. As far as
| I'm concerned, people can do whatever they want (and I
| hear that the Telegram UX superior). What I do not
| tolerate is wrong statements about the privacy situation.
| Telegram is strictly less private, Signal is strictly
| more private.
| wizzwizz4 wrote:
| > _There are other things to criticise with WhatsApp, but
| not that._
|
| Nitpick: Facebook can obviously grant themselves the
| ability to read your WhatsApp messages, by pushing out a
| new client. What they can't do is _covertly_ read your
| WhatsApp messages: WhatsApp is well-studied enough that
| people would notice the malicious client update within a
| year.
|
| Google or Apple can also grant themselves the ability to
| read your WhatsApp messages. Someone grabbing your phone
| while it's unlocked has the same ability.
| palata wrote:
| Nitpick indeed, but correct :-)
| drnick1 wrote:
| Absolutely, and this is why one of the only viable
| options for truly private communication is Signal on a
| degoogled ROM like Graphene. Matrix also works, but you
| need your server.
| exo762 wrote:
| > What is encrypted and how is public information. If it
| doesn't fit your use case don't use it. There is no
| "spin".
|
| Correct way of speaking about Telegram is - nothing* is
| encrypted. (encrypted chats are not more than 0.5% of all
| chats). That would be a "no spin" take.
|
| > one guy dared write a crypto library rather than using
| their own
|
| Red herring. This library is NOT used for more than
| 99.95% of chats on Telegram. It is applied only to
| "secret chat", which is a torture device with horrible
| UX. I guess that horrible UX is the result of choice of
| using custom crypto library instead of going with
| something capable of working when addressee is not
| online.
|
| > Another darling is Signal who refused to stop
| collecting phone numbers until recently even though they
| never needed it, does not allow open source or other
| clients to use their servers (and won't release the
| actual server code) and frankly does not work half as
| well as Telegram in terms of UX.
|
| Phone numbers are still used as anti-spam measure. You
| are free to get a burner, register an account and throw
| away the SIM card.
|
| > does not allow open source
|
| Signal client is open source.
|
| > frankly does not work half as well as Telegram in terms
| of UX.
|
| It works well where it does matter. Vide Telegram's
| "secret chats".
|
| > All of this is really confusing for me.
|
| You are clearly misinformed. That explains the confusion.
| dizhn wrote:
| - Messages by default are encrypted in transit. Client to
| server. Yes Telegram does have access to those messages.
| (I don't believe we had any e2e encrypted chat service
| before the likes of signal, matrix etc. Whatsapp added it
| after Telegram too if my memory is right.)
|
| - The library IS used for all encryption including the
| above client to server encryption. As far as I can tell
| from casual use the other end does not need to be online
| for secret chats per se. There's a key exchange with
| picture verification that requires the party on the other
| end to accept the chat request.
|
| - The phone bits in your and the other commenters
| response sound a little bit handwavy to me.
|
| - Telegram client(s) are also open source. The comment
| was about the server and interoperability with other
| clients.
|
| After all it doesn't seem to me that I am more
| misinformed than yourself.
| exo762 wrote:
| > Messages by default are encrypted in transit. Client to
| server.
|
| By this metric Facebook and Google are encrypted, because
| TLS. Sorry, Telegram's messaging is an attempt to mislead
| users, plain and simple.
|
| > The library IS used for all encryption.
|
| They could chose to use TLS for for almost all chats, and
| instead they've "invented" MTProto. Why go with MTProto?
|
| > As far as I can tell from casual use the other end does
| not need to be online per se.
|
| You are wrong. Phone on other side has to accept "secret
| chat request" (no user interaction is needed). Until its
| accepted, initiator's app interface is blocked with a
| spinning circle. And to add insult to injury, one can't
| initiate secret chat from desktop client.
|
| > Telegram client(s) are also open source.
|
| Yes, it is very refreshing to be able to verify that they
| can read all of my messages. /s
|
| > The comment was about the server and interoperability
| with other clients.
|
| Signal leadership explicitly stated that they care about
| secure comms and don't care about ecosystem around the
| chat. You can create your own client, you can't market it
| as Signal because that might "endanger lives".
|
| > - The phone bits in your and the other commenters
| response sound a little bit handwavy to me.
|
| I issue you a formal apology on behalf of HN hive mind.
| /s
|
| On serious note - palata's point is right, but a bit
| outdated. Functionality is still there, but it became
| opt-in. New users have phone number automatically hidden
| and phone number is collected only as an anti-spam
| feature.
|
| I'll repeat my point again. Telegram is a honey pot of
| messengers and nobody should use it.
| Valodim wrote:
| > - Messages by default are encrypted in transit. Client
| to server. Yes Telegram does have access to those
| messages.
|
| No connection over the internet is not transport
| encrypted these days, but that is not what this
| conversation is about. It's about whether messages are
| encrypted so the server cannot read them. And Telegram is
| commonly mistaken to have this property, including OP I
| was responding to.
|
| If you go around telling people that telegram is
| "encrypted", please stop. You are spreading
| disinformation.
| general1465 wrote:
| People wants simple communication app. Telegram is
| exceptional with that. Matrix may be encrypted, but
| everything else is just bad.
| bdunks wrote:
| > "I'm not going to install yet another chat app"
|
| This is legitimate.
|
| I have to use:
|
| - iMessage & SMS for most US based family, casual friends and
| co workers. - WhatsApp for European Family - Signal for one
| group of friends - Telegram for another group of friends
|
| Every time I message someone I have to remember what app to
| use. It's annoying. This in addition to random threads that
| pick up with the same people on instagram, discord, etc.,
| which I try to redirect to our "standard" channel as
| aggressively as I can.
| shagie wrote:
| The relevant xkcd is Chat Systems https://xkcd.com/1810/
| thesuitonym wrote:
| > no one wants to either host their own server, nor pay
| someone to host it for them.
|
| I hear this every time anyone brings up a federated
| chat/social media/anything service, and I just don't get it.
| If you don't want to host it, don't. There are plenty of
| servers out there, and a lot of them are free. Yeah, you have
| to trust the person hosting it, but why is that only a
| problem for federated services?
| psychoslave wrote:
| My wild guess is that "big corp"
|
| - are willing mostly to harvest data at scale, mostly for
| ad target or whatever political agenda owner that can pay
| bills
|
| - will make big breaking changes only if more money is
| expected in a some quarters
|
| The local/small benevolent geeks:
|
| - aren't entangled into micro-management policies and might
| just be logging everything to target individual as seen
| relevant by someone that could be whatever evil profile one
| can think of
|
| - are possibly going to do their best for free, but could
| well end the experiment tomorrow without prior warning as
| they burn out into a growing discontent user base despite
| best efforts (and few to no recognition for that), or
| simply because they found a new hobby to spend attention to
|
| And of course hosting all at home is taking the burden on
| one self. For people in IT, that might be something
| affordable, but otherwise this is like baking your own
| bread, sewing your own garment, producing and storing your
| own electricity, cultivate your own garden. Yes all of them
| are doable by an individual, especially those already
| proficient in the field. But obviously, this is not going
| to scale easily, and it's not the general tendency of most
| contemporary societies. Doing otherwise would require
| humankind to make a giant leap in civilization tendencies.
| wolvoleo wrote:
| No but hosting a small server is much more manageable
| financially than hosting the whole world. One geek can
| host hundreds of people for pocket change.
| lukeschlather wrote:
| There are two things: trusting the person's intentions and
| trusting the person's competence. Federation makes both
| problems worse, because you need to trust an unbounded
| number of organizations rather than a single organization.
| Even if you take it for granted that I trust all of those
| orgs intentions, there's no way they are as competent as
| the multimillion and multibillion dollar organizations
| running the big names.
| BLKNSLVR wrote:
| I ran a server for a while a couple (maybe a couple of couples)
| of years ago, and client devices periodically disconnected and
| had to be re-setup / re-authenticated from scratch, losing the
| chat history and being a general hassle. It happened often
| enough that I got jack of it.
|
| I like the idea, a lot, but the implementation at the time
| annoyed me away from it. I just don't have time / motivation at
| the moment to have another go. We ended up on Discord for
| family communication and it works well. I know Discord is on
| the lower end of 'one of the bad guys', but for the same reason
| I don't re-setup Matrix I don't move off Discord. At least it's
| not WhatsApp...
|
| I did try to get them onto Signal, but I don't think Signal did
| group chat back then - which means it must have been before
| 2020.
| megous wrote:
| Bloated server implementation with lack of alternatives and a
| complicated protocol.
| jasonfrost wrote:
| I don't remember why but I had to download a separate
| notification app that pushed notis
| munin wrote:
| Matrix is an unserious project and the client ecosystem is a
| train wreck. The server ecosystem is not much better. The
| Element people, who are kind of the default Matrix people
| because as far as I can tell are the only people getting paid,
| will tell you that this is because a bunch of IT integrator
| companies unjustly profit off of the open source work by
| selling services to European companies but contributing none
| back to either Element or other open source Matrix projects.
|
| The first issue I'd like to address is that one: as a small
| business, I tried to purchase software from Element and was
| told that I was not large enough to justify their time. Fair
| enough, I only wanted a 200 seat license and I was willing to
| pay per seat, but I guess they really want the high value
| contracts if they have a limited sales team. However, it is a
| bit much to go from that experience to their justification
| about the structure of their project. Maybe they should think
| about taking some sales opportunities that present themselves?
|
| Then there are branding and release decisions around the
| clients that Element makes. There are two projects in the
| client space from Element: a client called Element, and a
| client called Element X. Element X is the newer one. Element
| (do you see how this is getting confusing yet) is
| simultaneously at different times an Electron desktop app, a
| mobile app, and a web app. Element X is becoming all of those
| things but the feature parity is not even between them. Element
| supports "legacy" Jitsi for voice and video calling while
| Element X supports newer Element call - which is different from
| legacy Element, Element call is a webRTC implementation native
| to the Matrix ecosystem while the "legacy" Jitsi is a way to
| send clients a URL for Jitsi calls and have them shell out to
| another app to actually implement the call. Fair enough.
| However, the desktop Element X client does not yet support new
| Element call but the "old" Element client does support both
| "legacy" Jitsi and new Element call. And the Element X mobile
| app cannot call the old Element mobile app - but I think the
| other way around can. Even getting your head around this as an
| IT person is confusing.
|
| To add insult to injury the new Element X app on mobile is in
| some ways a downgrade because they integrated the cloud vendor
| push notification services into the app, so even though you
| have "sovereign" and "self-hosted" infrastructure you're still,
| on a good day, leaking meta-data about your chats back through
| to the people you were trying to decouple yourself from anyway.
| You can run your own push notification services for this mostly
| if you want and all your mobile clients are Android but like,
| why.
|
| Then, there's desktop client usability. During account setup,
| Element/Matrix makes a big ceremony out of establishing your
| cryptographic identity. Perfect. And as part of that you write
| down a 10-ish something word passphrase that is a recovery
| sequence for said identity. Perfect. Then some network hiccup
| happens that disturbs the Element client like some kind of prey
| animal and it spontaneously logs you out. You log back in, but
| there are no fields or options visible to use that recovery
| passphrase to restore your cryptographic identity. Your only
| option is to reset your identity, which makes all prior chats
| you have had unreadable. That part at least makes sense but why
| have this recovery story if it is not tested or usable in the
| app? This is probably an Element thing but in my research I
| have not found a client that people say is more robust, though
| at this point I'm open to trying.
|
| It's also possible that the way most people use this is as a
| web app, which is to be fair more robust. It does seem worse
| from a security point of view to have one central web server
| dealing in most of your users plain text, though. At that
| point, why not use Mattermost? I guess they're even more
| hostile to their users/customers, for some reason.
|
| Finally, there's the server ecosystem. The thing that is
| frustrating to me here is the interplay between Synapse, Matrix
| Authentication Service (MAS), and OIDC. This, as far as I can
| tell, is all intentionally hostile to drive you into Element's
| commercial product offering. Which I find especially galling
| because they won't sell your their commercial offering anyway,
| so you're going to have to figure it out for yourself. Synapse
| has some legacy support for OIDC which you are going to need to
| enable for backwards compatibility. However, for forwards
| compatibility with Element X, you are going to need MAS.
| Synapse is a large, mature Python project. MAS is a single Rust
| binary which is simultaneously a server and CLI to do user
| management. You'll need both configured against your OIDC
| provider. Why didn't the new OIDC features just get integrated
| into Synapse?
|
| I think that a lot of this is an outcome of the fact that
| Element is very literally in a "the old world is dying and the
| new world struggles to be born" situation at this time. I do
| have a lot of sympathy for being in the position of having huge
| companies - especially companies as annoying as IT outsourcing
| and integration - make a line of business out of configuring
| and installing your open source software. However, I have to
| say, having spent some of my professional life now also
| configuring and installing this open source software, I
| understand why those IT outsourcing companies have a moat. If
| the open source software was easier to install and use, perhaps
| those companies would have less of a moat. It seems to me that
| at least some of the story from Element is that if they make
| the ecosystem harder to use and understand, then people will
| take their money and the business will survive. However, in my
| experience, they won't take your money anyway.
| TavsiE9s wrote:
| Thank you, I was about to post a response similar to yours
| sans the "trying to buy licenses" part.
| secretballot wrote:
| The thing about hosting was the same conclusion I drew when I
| looked into this. I've stood up a lot of daemons in my time,
| and Matrix's difficulty level is so far outside the norm
| that... it's got to be on purpose, right? If it's not on
| purpose, man, that's also worrisome.
| this_user wrote:
| I think their main issue is that they seem to have no one who
| is seriously looking at the Matrix ecosystem from a product
| perspective. You have all of these pieces of technology in
| various states of maturity that more or less fit together if
| you know what you are doing. But there is also a lot of
| friction and a lot of things breaking on a regular basis etc.
|
| What the project needs is someone who looks at it from a
| customer perspective and who can direct resources to make
| sure the entire thing is packaged as one consistent thing
| that does what the customer needs.
|
| If you install WA or Signal, or if you sign up to Slack, you
| don't have to wonder which home server you should install and
| which of a dozen or so available clients you should use and
| what features are not yet production ready. Instead, it just
| works.
| noirscape wrote:
| I think a product focus does exist: Element seems to be a
| genuine attempt to fully assemble Matrix as one full
| project. The problem is that it feels like the Element devs
| are stuck wanting to have their cake and eat it too.
|
| There's some design choices in Matrix that don't really
| "fit" with what modern messaging infrastructure looks like.
| (Which to summarize it pretty quickly is a Slack/Discord-
| esque model, where non-sysadmin users get to fully
| administer their own spaces, with an expectation for
| multiple different channels, control over user permissions
| and user access and so on and so forth.)
|
| Some of these come from the fact that Matrix is pretty
| blatantly just designed as "what if IRC, but slightly more
| modern". It's main unit for non-sysadmin moderation is a
| single channel, with the expectation that one _instance_ of
| Matrix will never have two channels named #general (as an
| example). Similarly, it 's entirely possible to kick users
| from a channel... but then have that exact same channel
| continue independently on a different instance, but under a
| different label. This makes sense if you look at it as
| "supercharged IRC", but becomes a complete and utter mess
| when you factor in things like the encryption between two
| servers suddenly disagreeing with each other (leading to a
| bunch of old messages becoming unreadable), content
| moderation (barely an issue on IRC because message
| retention is expected to be almost entirely clientside) and
| so on and so forth.
|
| Element/synapse's people do _try_ to provide for these
| cases, but you 're effectively stuck trying to prod at
| admin API endpoints, bots to synchronize moderation
| decisions and they have like 3 different "channel grouping"
| that's supposed to be their version of the Slack
| workspace/Discord guild model.
|
| Honestly though, I'm pretty sure that once XMPP gets a
| proper multi-user multi-channel XEP going (there's one in
| draft right now which specifically tries to provide
| workspace-esque support; it's possible to do this already
| but it's a sysadmin XEP, the proposal aims to give this
| capability to regular users), it'll just end up blowing
| Matrix out of the water entirely for most usecases. Unlike
| Matrix, it's a far more mature protocol that's a lot easier
| to work with and actually has many different
| implementations that you can choose from.
| Teever wrote:
| The lack of attention that you identify is a real issue
| with the project but the root issue is ultimately a lack of
| sufficient funding that would enable all these parts to
| receive the attention that they require.
|
| Funding fixes all these problems and it has to come from
| big governmental and institutional players in Europe who
| are motivated by ending their reliance on American
| companies like Microsoft.
| polski-g wrote:
| Yeah they told me to fuck off when I wanted to purchase
| Element One for server-side administration.
| veeti wrote:
| > To add insult to injury the new Element X app on mobile is
| in some ways a downgrade because they integrated the cloud
| vendor push notification services into the app, so even
| though you have "sovereign" and "self-hosted" infrastructure
| you're still, on a good day, leaking meta-data about your
| chats back through to the people you were trying to decouple
| yourself from anyway. You can run your own push notification
| services for this mostly if you want and all your mobile
| clients are Android but like, why.
|
| Probably because this is literally the only way to make
| notifications work reliably on mass market Android and iOS
| devices? It is no different from Signal or any other secure
| messenger on the market. Decoupling from these platforms is a
| story for another day.
| nickslaughter02 wrote:
| The UK is the number one enemy of security and encryption. Did
| you read and compile all of the libraries and clients yourself?
| LeelaAI wrote:
| I enjoy self hosting stuff with Docker. Matrix/synapse is one
| of the more difficult / PitA projects I've ever gotten up and
| running.
| snorremd wrote:
| When me and a bunch of friends and acquaintances switched away
| from Slack a little under a year ago (I think) we looked into
| Matrix. One of the primary requirements was that even our non-
| technical friends should be able to use it.
|
| At the time Matrix/Element had recently launched their Matrix
| 2.0 efforts and I tried setting up the whole stack without
| resorting to their all in one shell-script meant for non-
| production use. I did not mind hosting four different servers
| (Synapse, Matrix Auth Service (MAS), Call, etc), but did find
| the integration and config job a bit tedious. The main blocker
| though was the lack of an invite-system in the new Matrix Auth
| Server. Also the fact that the Element X app uses a new Livekit
| based call server while other clients/apps use a different
| approach is also something not great.
|
| We ended up going for Mattermost. One service easily hosted
| with Docker. One app, and easy invites. While I think
| federation would be cool, right now Mattermost was a bit
| simpler to get up and running.
|
| Element seems more focused on enterprise and government
| contracts than self-hosters. I think this is fine, they need to
| pay their bills. But Matrix 2.0 for self-hosters might need a
| better story right now.
| Arathorn wrote:
| When we first announced Matrix 2.0 implementations in Sept
| 2024 we made a major error by not providing an easy distro,
| so I feel your pain.
|
| We fast-followed with https://github.com/element-hq/ess-helm
| as a really easy distribution (albeit using helm charts)
| based on the paid offering we provide for folks for NATO and
| the UN and folks. It really is trivial to install now - e.g.
| here's a live-install from FOSDEM last weekend:
| https://youtu.be/EngsGD30Ow0?t=929
|
| Meanwhile if you're allergic to k8s I went and published a
| trivial docker-compose at https://github.com/element-
| hq/element-docker-demo/ too.
| horsawlarway wrote:
| While I definitely appreciate that this exists now (as
| another person who considered matrix and ended up passing
| due to deployment complexity) this is not what I think most
| folks would reasonably call a "trivial" docker compose
| setup.
|
| It's a 16 service compose setup, complete with init hacks,
| inline docker-file builds to use those init hacks, a
| _whole_ bunch of required config templates, some services
| that aren 't clear if they're examples or requirements (ex
| - why is mailhog in there? just give me the SMTP env vars),
| and just a lot of general complexity still.
|
| This feels like several discrete services that don't play
| nicely, herded together like cats. It doesn't feel like a
| solid and planned set of tools.
|
| ---
|
| From my end - it's not enough to just stand it up. If this
| is my primary messaging tool and I'm hosting it, I need to
| have a feel for how it might break, and how I can fix it
| when it does.
|
| Hell, I'm not even allergic to k8s (I host dozens of
| services on a baremetal cluster), but I am allergic to helm
| for very similar concerns: Complexity at the self-hosting
| scale (individual to small business) is rarely worth the
| additional overhead, and helm rapidly makes what should be
| simple yaml file deployments a complex, abstracted process.
| Your docker compose has a similar feel.
|
| My first rule of thumb is "How long will it take me to
| manually read and understand a compose file while
| converting it to a k8s deployment?" This one looks onerous,
| not trivial.
| netdevphoenix wrote:
| Consensus. People like to follow what the majority does even if
| it's suboptimal.
| em-bee wrote:
| not just like to follow, but are forced to follow.
| Anonyneko wrote:
| Compared to Telegram, it feels like using a laggy MSN
| Messenger. The experience, both client and server-wise, just
| feels very unpolished. It's no single big thing, it's more like
| death by a thousand cuts.
|
| I was bullish on Matrix because it's so extensible, but in the
| end I realized that only the default client experience matters
| as that's the one everyone will be using. And it just isn't
| there yet. In the end, all the group chats I was in migrated to
| Discord or Telegram, so I had no more reason to use it...
| Arathorn wrote:
| We explicitly built Element X to be competitive with
| Telegram's UX - I'm guessing that the feedback here is on the
| crusty old Element Classic app, which hasn't been touched for
| 3 years now, and definitely did feel like a laggy MSN by
| comparison.
|
| Meanwhile Element X feels _really really good_ - especially
| on iOS, but also Android has improved loads in the last few
| months (after tweaking the rustc ARM compilation flags
| properly, doh)
| bluebarbet wrote:
| Thank you for your work. For my money there is literally
| nothing that free computing needs more right now than a
| consumer-ready open standard for encrypted IM. Matrix has
| been the obvious candidate for a decade. Let's get there.
| Arathorn wrote:
| thanks. we are doing our best, despite various a few
| misadventures along the way :)
| guerrilla wrote:
| The UIs are terrible. I've tried it a few different times with
| friends and we gave up each time.
| mightyham wrote:
| I publish a Firefox plugin and needed help a few years ago. Not
| to get too far down that rabbit hole, but they suddenly blocked
| my plugin because they couldn't build my source code, even
| though the issue with their build environment was pretty
| obvious. Anyways, I had to use their Matrix support channel and
| they recommended Element. I was immensely frustrated with how
| buggy the experience was, and it turned me off from ever trying
| it again.
| trvz wrote:
| You're not alone, their iOS apps have 3.4 and 3.6 star
| ratings. Anything below 4.0 isn't good.
|
| I've downloaded them, and neither has proper dark mode icons.
| Instant fail.
| polski-g wrote:
| Imagine your parents:
|
| * need to use size 18 font on their phone
|
| * refer to the phone as "that fancy music player"
|
| * calls you when their favorite blog doesn't "load"
|
| * every password they've ever had is "password1"
|
| Now you want to tell them to "download this new app, generate a
| private key, store it as a backup somewhere. When you get a new
| phone, you need to re-import it"
|
| Good luck with that.
| Bender wrote:
| I assume the government installations are integrating it with
| LDAP/AD or at least they should. This assumes both chat and
| LDAP/AD are logging to a SIEM for the auditors.
| onraglanroad wrote:
| "load" is the correct term. What would you call it?
| tormeh wrote:
| You just don't say the sentence at all and instead choose a
| technology from one of the big tech companies.
| onraglanroad wrote:
| Also, I'd encourage the use of "passphrase" rather than
| "password".
|
| No-one normal can remember tr5vgh6##t5, but something like
| "$firstpetsname notatafarm garbagecan" is secure and easily
| remembered.
| tsimionescu wrote:
| Having tried to use that, I can assure you that no one
| actually (a) remembers their passphrase, nor (b) is willing
| to type it in when it does come up. It's a fun idea, but
| it's actually much worse UX than even a secure password.
| pkulak wrote:
| Fluffy Chat is great on iOS. My mom uses it; it respects
| system fonts very nicely.
|
| I get the frustration with encryption though. I wish there
| was a way to mark a homeserver as default _NOT_ encrypted. My
| homeserver is in my closet. Given the choice, I'd rather take
| the extremely tiny opsec hit for all the simplicity and
| usability benefits of unencrypted rooms.
| broken-kebab wrote:
| Matrix is not out-of-the-box thing.
|
| For hosting it you really have to go through some trial-and-
| error before it works as you'd like, and most self-hosting
| enthusiasts have pretty short span of said enthusiasm.
|
| For users its easier, but there are some idiosyncrasies in
| terminology, and concepts.
|
| There are docs but they really would benefit from human editing
| to become fully useful.
|
| Synapse in particular has a problem of existing in two places
| on GitHub, and the one which is obsolete somehow comes first in
| searches, and appears in AI responses constantly. Which I guess
| shoots quite a lot of first tries in their steps.
| Klonoar wrote:
| Running an alternative like Conduwuit is a one step cargo
| build process. Been using it for some time now and it works
| great with Element X.
| JadedBlueEyes wrote:
| You might want to move to a maintained fork like
| https://continuwuity.org if you haven't already
| domoritz wrote:
| The UX has many rough edges especially in the default element
| apps. UX was the primary reason my university department passed
| on switching to matrix from slack so far.
| tormeh wrote:
| It's a bit shit at being WhatsApp. Slow, buggy, and feature-
| poor. The unique selling points are very compelling, but only
| for a small niche. Fortunately for Matrix, that niche includes
| a lot of places with big budgets, but it does not include
| consumers.
| superkuh wrote:
| Matrix is controlled by a single company Riot.im/Element.io who
| decides what the protocol is now. Element.io's income stream is
| hosting these extremely fat synapse servers for government. It
| doesn't really care about anything else. The Matrix Foundation
| has abdicated from it's role as of a couple years back (ref:
| https://element.io/blog/element-to-adopt-agplv3/
| https://matrix.org/blog/2023/11/06/future-of-synapse-dendrit...
| https://blakes.dev/posts/2023-11-06-element-closing-matrix/).
| And generally synapse servers RAM and storage requirements grow
| and grow and grow, with no effective mechanism to trim the DB,
| until it requires hundreds of GB of ram just to idle and it
| starts becoming very expensive and infeasible for non-
| government/corporate pocket books to pay for. Even with just a
| few users the min ram suggested is 8GB at the very start.
|
| For human people, for small social groups, Matrix in the form
| of the controlling Synapse server is infeasible over any period
| longer than a few years. See:
| https://news.ycombinator.com/item?id=46376201 /
| https://news.ycombinator.com/item?id=44617309 and the reports
| there or just ask around. I know Afternet gave up Matrix
| because of this despite really liking the features too,
| https://afternet.org/help/matrix
|
| There are other Matrix protocol servers but none that implement
| the full protocol. Conduwuit was the most full featured but
| died, now there's https://continuwuity.org/ and a tiny bit of
| hope.
|
| tldr; the Element Synapse matrix server uses too many resources
| (and they killed dendrite). We all wanted it to succeed but it
| was co-opted. Alternatives are not in control of the protocol,
| few, and of limited lifetime so far.
|
| XMPP and IRC are the better alternatives.
| preya2k wrote:
| There's hundreds or thousands of people out there hosting
| Synapse for small groups and use cases. Ressource
| requirements for a couple of dozen or hundreds of people are
| pretty tame (mostly storage that grows fast). You can easily
| host Synapse on cheap VPS products for less than 5EUR/month.
| I've been doing this for multiple organizations and many
| years.
| panick21_ wrote:
| > It doesn't really care about anything else.
|
| That they don't care is unfair, they just do what makes them
| survive.
|
| > infeasible over any period longer than a few years.
|
| I know companies that have done so. The resources requriments
| are bit higher then some alternatives but its really not has
| crazy as you make out to be.
| amandine wrote:
| The governance of the Matrix Spec has always been open, as
| explained on the website
| (https://matrix.org/foundation/about/) and in the Matrix Spec
| Change process (https://spec.matrix.org/proposals/).
|
| Meanwhile in the last 2 years the Foundation has evolved a
| lot, in particular with the election of its Governing Board
| (https://matrix.org/foundation/governing-board/) representing
| all stakeholders of its ecosystem, and which has an advisory
| role to ensure the independence of the Foundation. The
| Governing Board has also set-up several Committees which are
| hosts to Working Groups which help run the various activities
| of the Foundation (https://matrix.org/foundation/working-
| groups/). You will note in particular the existence of the
| Governance Committee
| (https://matrix.org/foundation/governing-
| board/committees/#go...) and its corresponding Working Group
| which "exists to determine how The Matrix Foundation should
| be structured. It determines why the Foundation is structured
| the way it is, or look for alternatives when the Foundation
| has visible flaws.".
|
| In terms of the Foundation developing its own software: it
| has been a deliberate choice to not have any development
| (beyond moderation tools) within the Foundation. The reasons
| for it include the fact that the Foundation is already
| running at loss and can't afford to pay a team of developers
| big enough to develop and maintain all the bricks of a Matrix
| stack. If the Foundation decided to develop everything itself
| it would need to set up revenue lines which would probably
| compete with the various vendors in the Matrix ecosystem, so
| the Foundation would rather support an active ecosystem than
| cannibalise it. That said, it may change in the future if
| that is the best choice for the project; or a Matrix vendor
| may choose to donate the code of their stack, like Element
| was donating Synapse until freeriders destroyed its business
| and forced them to fire half their employees to stay alive.
|
| In terms of Synapse's efficiency, it has improved lately
| despite losing some of the team, and thanks to having stopped
| dispersing the resources across two server implementations in
| parallel, and focused on one. As you say Continuwuity is an
| alternative implementation to look at if you are unhappy with
| Synapse.
| Aurornis wrote:
| > What makes it not more popular ? Is it the federated approach
| ? The client applications that don't look really fancy ?
|
| It's not that the UI doesn't look fancy. The overall experience
| of using Matrix has a lot of catching up to do. Like many
| others on HN I was enthusiastic about it early on, but I've
| been so worn down by all of the little problems, random re-
| authentication issues that nobody can explain, and missing
| features that I found myself avoiding using it unless I really
| needed to talk to someone I couldn't contact any other way.
|
| You can find isolated success stories about small groups who
| successfully use it for their group chat, but at the root of
| all of those stories is always one person who takes the role of
| very dedicated IT person to keep it all running and walk others
| through steps to fix it when it breaks.
|
| They've been churning a lot on features and design, which has
| added another layer of fatigue on top of it all. It's hard to
| even discuss Matrix any more because every negative experience
| will get waved away with an explanation that it was a problem
| with an old app or version and you just need to try Element X
| and Matrix 2.0 or the newest release. However, it's felt that
| way for years. I'll revisit it again in a year but for now I've
| reached my limit for how much time I can put into trying to
| make a project work and stay working.
| bigfudge wrote:
| As someone who has dealt into this quite recently, I can
| confirm that it hasn't really changed that much. The
| documentation for integrating clients and bots is just old or
| wrong or non-existent. The complexities of getting
| authentication right and even getting messages validated
| between two human clients was really much worse than it
| should've been and it's just not in a position where normal
| people can use it just yet. That said, I'm hopeful that
| government adoption could make it right quite quickly. And
| adopting it within a managed setting would mean that the UX
| could be ironed out fairly quickly.
| etiam wrote:
| I think this is right.
|
| I just also want to toss in that (at least for Element in
| particular) the continuing lack of long-form composition or
| history navigation appears to be a liability with some
| contacts.
|
| At this point it's probably fine for chat format one-liners
| in the moment, but for the communications that have
| historically been going over e-mail as opposed to IRC it's
| something of a pain to use.
| ufmace wrote:
| The best way to understand why it isn't widespread is to spend
| 10 minutes attempting to use it to actually chat with some
| people you know. I don't know which issues you'll run into, but
| it's virtually guaranteed you'll run into a variety of
| incredibly dumb and inexplicable ones.
| palata wrote:
| I was very enthusiastic about Matrix a few years ago, but my
| experience has been relatively bad and I lost interest.
|
| Apart from the experience, I think that there is a fundamental
| issue in the way Matrix is built: the Matrix servers have
| access to _a lot_ of metadata (at least last time I checked,
| but it feels quite fundamental to the protocol).
| zeec123 wrote:
| The fact that a "contact" is just a room with me and my peer
| and renaming my contact changes the room name for both of us
| tells me the UX is an utter failure. How can this be
| acceptable?
| panick21_ wrote:
| Why would it be? Being open and e2ee is irrelevant for mpost
| people.
|
| Most private messaging is done in whatsapp and after that
| telegram. Telegram has spend more usability and less on most
| other things.
|
| Then it compete with Slack and Teams on the cooperate side,
| where it was much later and less optimized for it. Slack took
| much of that market.
|
| It did replace IRC in many places but that was only ever a
| small part of the market.
|
| Basically between Whatsapp, Teams and Slack most of the market
| is covered and nobody is really a big player.
| pocksuppet wrote:
| It doesn't work very well. To join a room by address, you type
| the address into several boxes until you find the right one. If
| you log out, all your private messages are deleted because they
| were encrypted and the key is saved nowhere.
| pkulak wrote:
| Keys are actually saved somewhere. On your homeserver, in a
| store itself encrypted by another key that only you (and your
| other clients) have.
|
| You can disregard that store and not use it at all, which I
| actually think is a totally valid use case. It turns Signal-
| style at that point.
| Fabricio20 wrote:
| Personally what drove me away was all the thousands of little
| annoying things that you just dont have to deal with on other
| apps like Telegram or Discord or Slack. The final straw for me
| was the 2nd time losing all chat history because I got logged
| out on my browser and when logging back in and providing the
| super secure authentication key and resynchronizing, messages
| older than 7 days still didn't decrypt on all chats so I just
| lost all of that. Plus Element client being mega laggy and
| stuff (though I had a smoother experience with the third party
| Cinny client).
| uoaei wrote:
| It's akin to using Plex v Jellyfin for serving media files to
| others. If they're not technically savvy they really don't want
| to have to think about networking protocols and their
| fragility... so you just deal with Plex because at least it
| turns down the volume on constant calls to your support desk /
| personal mobile phone.
| abnercoimbre wrote:
| Have you heard of Emby? It seems to be closed-source. However
| you can still run it yourself [0]. UX appears to be better
| than Jellyfin, but I haven't tried either and not sure which
| one to go for.
|
| [0] https://emby.media
| maelito wrote:
| 300 million users, not bad though.
| zaik wrote:
| Everytime I change my nickname in the XMPP room that is
| bridged to Matrix, the counter increases by one. Never used
| Matrix.
| WhyNotHugo wrote:
| Who exactly is the target audience?
|
| People who are really into e2ee and privacy use Signal.
|
| People who want open, federated networks, use XMPP.
|
| People who want something fancy with all the features, etc use
| Telegram or whatever.
|
| Matrix basically has a lot of hype and marketing around it
| (presumably due to being VC funded), but it's hard to see any
| appeal beyond that. And the protocol and spec are an absolute
| mess.
| greentea23 wrote:
| Popularity is irrelevant imo, it's a general purpose FOSS tool.
| Ignore Element and matrix.org, the open protocol is what
| matters. These features are useful even if matrix never gains
| any network effect: 1. talking among a small-ish specific group
| that needs sovereign communication, e.g. when forming a company
| or a tight knit in person friend group 2. only data limit is
| the size of my harddrive 3. bridge to every other popular
| protocol 4. personal bots and automation with no restrictions
| 5. Unlimited and customizable clients with no restrictions 6.
| Combinations of 1-5.
|
| Can't speak for non-self hosters or people who aren't serious
| about chat, but for chat enthusiasts who can setup a server
| with bridges and bots, matrix is incredibly useful.
| dotdi wrote:
| I was on a team that evaluated moving a significant portion of a
| product that should be used for government/healthcare onto
| Matrix. There were several drawbacks that made us NOT go this
| route:
|
| - Olm/Megolm does not offer forward secrecy for group messaging
|
| - Olm/Megolm does ensure end-to-end encryption for message data,
| but not for metadata.
|
| - Federation makes it challenging to be GDPR compliant
|
| - Synapse is very heavy, other implementations are less
| production ready
|
| - For better or worse, the matrix foundation is under UK
| jurisdiction.
|
| I'm sure I forget some of the nuance, but these were some of the
| major points. However, there are several government entities in
| Germany, France, Poland, etc, that can live with the limitations
| and DO self-host Matrix servers.
|
| I won't go into the pair of high-severity vulns in 2025 (and the
| somewhat difficult mitigation) because that could hit anyone.
| Buxato wrote:
| Thanks for the info, what do you think about Delta chat?
| dotdi wrote:
| The cryptography is sound, however, it's also frequently
| changing, in addition to straying from standards more or
| less. This makes it difficult to give a firm answer.
|
| This ETH (i.e. Zurich) paper[0] identified several
| exploitable vulnerabilities (bad), which were quickly
| addressed by delta chat (good).
|
| So overall, I'd see it as a good messenger, but with
| downsides.
|
| [0]:
| https://www.usenix.org/system/files/usenixsecurity24-song-
| yu...
| Buxato wrote:
| Thank you :)
| Arathorn wrote:
| > Olm/Megolm does not offer forward secrecy for group messaging
|
| Megolm does provide forward secrecy - just in blocks of
| messages. If a message key gets stolen, an attacker could
| decrypt subsequent messages from that sending device until the
| next session begins: by default this happens either after 100
| msgs have been sent, a week has elapsed, or if the room
| membership changes. Most folks consider this to be adequate
| perfect secrecy.
|
| In terms of the Matrix Fdn being incorporated in the UK... I
| guess that means one shouldn't use the Internet, given IETF is
| US incorporated? :)
| dotdi wrote:
| > In terms of the Matrix Fdn being incorporated in the UK...
| I guess that means one shouldn't use the Internet, given IETF
| is US incorporated? :)
|
| The outputs of the IETF are RFCs. The Matrix foundation does
| more directly oversee the "de-facto" Matrix, so has more
| influence, could bow to government pressure or changing laws,
| etc. etc.
| Arathorn wrote:
| Hmmm. The main difference between the Matrix Fdn publishing
| a spec (https://spec.matrix.org) made out of Matrix Spec
| Changes (https://spec.matrix.org/proposals) versus IETF
| only publishing RFCs is simply that the Matrix Fdn also
| maintains a consolidated version of the spec. I'm not sure
| that makes the protocol governance fundamentally more
| vulnerable to govt influence?
| pseudalopex wrote:
| They said they were sure they forgot some of the nuance.
| UK company Element took server development from UK
| company Matrix Foundation would have been forgettable
| nuance. Or they evaluated Matrix before possibly.
| danjones-crypto wrote:
| Re. security of old keys/sessions/messages after compromise
| of some current state (i.e. notions like forward security):
|
| Do Matrix clients still keep the oldest version of the Megolm
| ratchet they have ever received? When I last looked (around
| 2024), the libraries maintained by the Matrix.org core team
| did.
|
| This means that, while Megolm has a ratchet that can be used
| to provide forward security, no Matrix implementation that I
| am aware of does this. This seems to me to be because other
| features of the Matrix specification rely on continued access
| to these old keys (like Megolm key backups and history
| sharing).
|
| Re. security of new keys/sessions/messages after compromise
| of some current state (i.e. notions like post-compromise
| security, future secrecy):
|
| My understanding is that, while a _sender_ will rotate Megolm
| sessions every 100 or so messages, recipients tend not to:
| clients will accept ciphertexts sent from those old sessions
| for an indefinite period of time. Again, I haven't been
| following developments in the Matrix world for a little
| while, so please correct me if I'm wrong.
|
| This seems (to me) to be for similar reasons to the above:
| recipients keep around the recipient sessions so they can be
| backed up and shared with new devices (for history sharing).
| But (!) Matrix could get way better authentication guarantees
| if they just _disabled accepting messages_ from these old
| sessions at the same schedule as the sender stops using them.
|
| --
|
| These are not a unreasonable compromises (there aren't too
| many attempts to square this circle, and most that I'm aware
| of are quite academic) but it's worth making clear that just
| because Olm/Megolm/the Matrix spec have particular features,
| it doesn't mean they are used properly to give the security
| guarantees we would naively expect from their composition. At
| least, this is the case for almost all Matrix clients that
| I'm aware of.
| Arathorn wrote:
| > Do Matrix clients still keep the oldest version of the
| Megolm ratchet they have ever received? When I last looked
| (around 2024), the libraries maintained by the Matrix.org
| core team did.
|
| It entirely depends on the client. There is nothing in the
| protocol which means that clients have to store old keys,
| but many do - mainly so they have a copy that can be backed
| up on the server to support migrating between devices, and
| for history sharing, as you say. However you absolutely
| could configure a locked-down Matrix client which discards
| megolm keys after receipt.
|
| > My understanding is that, while a _sender_ will rotate
| Megolm sessions every 100 or so messages, recipients tend
| not to: clients will accept ciphertexts sent from those old
| sessions for an indefinite period of time. Again, I haven't
| been following developments in the Matrix world for a
| little while, so please correct me if I'm wrong.
|
| Yup, this is fair - and agreed that implementations could
| and should discard unexpected messages in those sessions.
| There's nothing in the protocol that stops that (but also
| it's not explicitly covered in the spec).
|
| We can fix this though; thanks for flagging it (and sorry
| if we missed it in the RHUL research...)
| user32489318 wrote:
| Which tool did you guys end up using?
| fsflover wrote:
| > - Federation makes it challenging to be GDPR compliant
|
| Can you elaborate? AFAIK when everything is encrypted, GDPR
| compliance is trivial.
| Buxato wrote:
| I deleted my matrix account after I receive some very nasty spam
| in form of Element Android notification. I think it wasn't Matrix
| direct fault, but as I used some Matrix chat groups and the list
| of member was public .. But I got really alarmed and angry when I
| receive so disgusting spam.
| ticulatedspline wrote:
| Never heard of Matrix before (as a protocol) what's it's
| advantage over XMPP?
| edhelas wrote:
| https://xkcd.com/927/
| fishgoesblub wrote:
| The only one that sprouts to mind is it is currently more
| popular and has fancier mobile clients. Besides that, it's
| slower and more resource intensive.
| panick21_ wrote:
| https://news.ycombinator.com/item?id=10040302
|
| Lots of discussion here.
|
| The conceptual the prinicple difference is that XMPP originally
| is about sending messages while Matrix conceptually is about
| 'syncing state' (like a mini-graph database).
| goodpoint wrote:
| It's heavier and leaks metadata.
| jimmydoe wrote:
| Why govt needs e2ee? Transparency is all we need.
| Western0 wrote:
| I prefer tox
| ChrisArchitect wrote:
| Related, 3 days ago:
|
| _European Commission Trials Matrix to Replace Teams_
|
| https://news.ycombinator.com/item?id=46901452
| RockstarSprain wrote:
| One thing I heard from some of my friends as a reason why they
| don't like using Matrix (via Element clients) was inability to
| use "stickers" like one can on WhatsApp, iMessage and other
| messaging apps. Apparently, this was important enough for them to
| lose interest in the platform over it.
|
| I guess the bar is pretty high for consumer messengers these
| days?
| Saris wrote:
| Yeah having a messaging app I enjoy using is important. Good UI
| and fun features make something worth using, it's why telegram
| is still my most used messenger.
| wolvoleo wrote:
| Telegram is great indeed. I'm happily paying for premium for
| two reasons: first it's not expensive at all (2EUR per month)
| and secondly it offers so many fun and useful features. I
| often buy it for friends too as a gift. They really have a
| good thing going.
|
| On most other platforms it's usually more the stick than the
| carrot (pay up or we bombard you with ads) and it's tons more
| expensive, eg Instagram alone costs 3x as much.
| Anonyneko wrote:
| This was definitely a little frustrating. Matrix protocol does
| have stickers technically, I've been following that PR since
| its inception. But when I last used it in practice, admittedly
| a few years ago, the UX was lacking. Adding and posting
| stickers was _not_ straightforward, in fact adding new stickers
| was restricted somehow. Not sure how it works now, and maybe
| that's just inevitable with a decentralized protocol.
| notpushkin wrote:
| It's not inevitable - the sticker packs (as currently
| implemented) live on your homeserver. So in a sense, it is
| decentralized already, and it's only a matter of designing
| and building an interface to manage those packs (and
| hopefully making stickers link back to the packs, for better
| discoverability).
|
| For now, you can override which server to use for the
| stickers. There's an implementation that downloads Telegram
| sticker packs (but you have to specify which packs you want
| before deploying it).
| riskable wrote:
| It also doesn't handle animated/looping gifs or webp properly.
| They don't loop.
|
| To summarize the great big problem with Matrix: It's no fun. No
| fun at all.
| u1hcw9nx wrote:
| In a an work/purposeful communication it's a great feature
| not to have fun features.
|
| People how love messaging are the bane of professional
| communication. You need to tell them to shout up, and tone
| down, but you want to do it politely. Just one person in a
| group that sends haha and gif to response to every message in
| a group is painful to deal with.
|
| Two Apps is the solution.
| u1hcw9nx wrote:
| How is that not a feature?
|
| Differently designed apps for social and professional life is a
| good idea! A streamlined app focused only on essential
| functionality is the best way to ensure meaningful
| coordination.
|
| It is mentally taxing when critical work updates are buried
| under reactions, glitter, and casual banter. Moving memes and
| family updates to a dedicated 'leisure' app allows for a high-
| signal environment.
|
| Something that gets things done, but also something where quick
| reactions are painful to do would be perfect.
| happysadpanda2 wrote:
| I don't know whether or not it is our instance at $dayjob that
| has a wonky setup, or if it is the elements client, or what
| (probably the client, as the problems all but disappear in the
| webb-ui version), but oh how many synchronization issues we are
| facing. threaded conversations not showing up, or randomly
| disappearing, clients getting stuck in message fetching loops,
| not actually fetching anything, notifications of new messages
| either not appearing, or not disappearing upon reading them,
| and ON TOP OF THAT no custom stickers/emojis/gifs...
|
| but those synchronization issues... if I want to be sure
| something reaches the rest of the team in a timely manner, I
| have reverted back to email
| Arathorn wrote:
| Matrix should categorically not have any sync issues; this is
| not normal. Something bad must be happening on the server;
| what server are you using and how are you running it?
| AyyEye wrote:
| Lol, messages showing up randomly days later is par for the
| course for our tiny group chat, most of whom are on
| matrix.org. Sometimes element won't download messages for
| some rooms (or even all rooms) for days/hours. Matrix has
| gotten far less reliable over the years (and I used to run
| a few homeservers).
| ezst wrote:
| I was like "oh common, that can't be a real comment, it's
| obvious to everyone how unstable this still is", then I saw
| that the comment was from Arathorn.
|
| You know, for half of the time you spend commenting over
| here to save face (or something), you could work with your
| users and see their firsthand experience for yourself.
| Arathorn wrote:
| this is me working with my users and trying to understand
| their firsthand experience for myself :)
| brnt wrote:
| > Matrix should categorically not have any sync issues
|
| Will you please let every single instance of any piece of
| Matrix infrastructure know? Nothing appears to be
| respecting this rule.
| notepad0x90 wrote:
| quite the opposite, Matrix clients lack their own unique
| character. they play the feature-catch-up game instead of being
| original.
| lynndotpy wrote:
| Not the primary use case for stickers, but what do you do when
| you're talking with someone for whom you're not literate in
| their language? Or someone who is not literate in any language?
|
| Stickers provide utility beyond beyond a fun way to
| communicate. Stickers, emoji reactions, voice notes, etc. are
| things we tend to see denigrated here, but are also non-
| optional features for a messaging app in the year 2016.
| timbit42 wrote:
| 2016?
| hexfish wrote:
| I wish.
| lynndotpy wrote:
| Not a typo, that's roughly my recollection for when
| stickers, reacts, and voice notes became broadly expected
| in messaging apps.
|
| I can't imagine seriously aspiring to get _everyone_ I know
| to download a messaging app in the year 2026 that doesn 't
| have these features at a minimum.
| wolvoleo wrote:
| These days messaging apps have been translation features.
| Another thing that matrix/element is missing sadly.
|
| I remember reading a feature request and it was put off
| on the reasoning of "server-based breaks our encryption
| and client-based doesn't work well enough". Makes sense
| but I don't think the latter point is still true, and
| Matrix is too focused on encryption IMO. In large open
| rooms there's no point to it because anyyone who wants to
| can join anyway.
| wolvoleo wrote:
| Stickers are easily replaced by emoji and small images. In
| fact this is how the matrix bridges do it.
| sp4cec0wb0y wrote:
| On a related note, Discord recently announced ID verification for
| users. Matrix might become a viable option for those who want to
| opt out of Discord for their "circles" of friends.
| pocksuppet wrote:
| Why not Signal? I think that Matrix and Discord are for your
| circles of "friends" you don't actually know.
| sp4cec0wb0y wrote:
| Well personally, I like to have organized chat rooms or
| "channels". Matrix is closer to a user friendly IRC client.
| Signal is great for group chats but some people are looking
| to have organized chat rooms for their friends.
|
| Someone will eventually ask "why not just use IRC?" and the
| answer is simply: Would your non-tech-inclined friends enjoy
| doing that?
| fsflover wrote:
| Because Signal has a single point of failure and actively
| fights with decentralization?
| lynndotpy wrote:
| I love Signal, but it's not "IRC-shaped" like Discord, Slack,
| Matrix, etc are. It isn't built to play the same role.
| waynesonfire wrote:
| > while Element (formerly Vector and later Riot) is the name of
| the client app. Element the company, originally called New Vector
| Ltd, was spun out of Amdocs in 2017. A for-profit business, it
| rebranded as Element in 2020. Element.io provides both client
| apps and server software that run the Matrix protocol. As well as
| free FOSS versions of both, there are also paid-for commercial
| tools: the Element Pro client and the Element Server Suite Pro.
|
| The is Matrix for you. A series of for-profit closures, merges,
| rebrands, and acquisions to increase synergy and unlock
| shareholder value. I'm staying away from this.
|
| That government IT is gaining around this service just speaks to
| the sales initative of this for-profit machine.
| notepad0x90 wrote:
| There is this phenomena where users of a product say they want
| something. But what they want is very different. People are not
| good at telling you what really matters to them. That's the main
| obstacle of Matrix's adaption I think.
|
| Matrix tries to copy-cat all these other products. But in the end
| it feels like something trying to be all sorts of things and not
| quite doing it as well as the originals in every way. Plus you
| have this "confusing" security/crypto aspect. And then you have
| the whole issue with inconsistencies between clients.
|
| You have to really commit to it, or matrix has to be the backend
| of some other more refined/specific app (like chat section on
| websites, like Disqus).
|
| In my opinion, if you want Matrix adaption, stop talking about
| Matrix adaption, that's like talking about HTTP adaption. You
| want people to use clients, talk about clients. Let's talk about
| "Element" adaption. (side-chat: Please make names more
| searchable. ok, you want to use this generic/confusing term
| "Element", can you at least make it unique by calling it "Elemnt"
| with a weird spelling so it's more searchable?)
|
| People don't like learning new and complex systems for the sake
| of it. It's a chore. I want to be able to tell people "let's use
| Element" and explain why they should use it. It would help if it
| had original features other products didn't have that it does
| really well. It's been over a year since i used Element, but I
| didn't like the UI at all, it felt like Teams but more clunky?
| perhaps the mobile app is better, I never tried it.
|
| All that said, I think it's a great system, it's perfect for
| government systems too. they're not usually concerned about
| things looking great or having cosmetic features. I would very
| much prefer to use it over Teams or Slack personally. So long as
| it handles scheduling meetings, and managing things like booking
| conference rooms just as well.
| ilovefrog wrote:
| whats wrong with IRC?
| ptman wrote:
| nothing, but people these days expect more from chat
___________________________________________________________________
(page generated 2026-02-09 23:02 UTC)