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?
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
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?
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.
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.
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.
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.
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).
> 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.
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.
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.
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).
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.
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
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.
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.
> 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.
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.
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.
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.
> 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.
> 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.
> 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.
> 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.
- 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.
> - 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.
> 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.
> 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?
- 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.
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.
- 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.
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.
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.
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...
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)
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.
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.
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.
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.
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.
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.
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 ;-)
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.
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?
> 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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
- 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.
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?
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.
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.
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.
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.
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.
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.
> 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.
* 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"
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.
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.
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.
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.
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 5€/month. I’ve been doing this for multiple organizations and many years.
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.
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.
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.
> 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? :)
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.
> 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...)
> 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.
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?
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.
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.
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?
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.
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.
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).
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?
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
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?
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.
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.
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.
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.
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.
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).
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 ?
> 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.
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.
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.
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).
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.
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.
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.
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.
> 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.
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.
People wants simple communication app. Telegram is exceptional with that. Matrix may be encrypted, but everything else is just bad.
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.
> 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.
> 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.
> 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.
> 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.
> 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.
- 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.
> - 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.
> 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.
> 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?
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.
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.
> “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.
The relevant xkcd is Chat Systems https://xkcd.com/1810/
What about maintaining encryption for an entire room of clients? I heard it's very difficult and prone to errors. Do you enforce it?
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.
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.
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...
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)
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.
thanks. we are doing our best, despite various a few misadventures along the way :)
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.
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.
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.
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.
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.
It’s open source right? You know what to do ;)
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 ;-)
This is the fastest way to get people to say "I hate proprietary solutions but at least they work"
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.
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/
> 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.
OK great. I guess you answered why Matrix is not more popular.
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.
Get into an online argument with the developers about what is the right approach and which dependency is to blame?
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.
You need to learn how to read sarcasm.
You need to learn https://en.wikipedia.org/wiki/Poe%27s_law
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.
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.
Teams has not been free with O365 for years now.
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.
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.
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.
Fluffychat does and I would argue is one of the big ones. Its however quite mobile optimized (basically more like WhatsApp, less like slack).
Element X finally has this on Android (in Labs) now. Web & iOS will follow.
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).
I enjoy self hosting stuff with Docker. Matrix/synapse is one of the more difficult / PitA projects I’ve ever gotten up and running.
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.
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.
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.
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.
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.
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.
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.
> 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...
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?
Consensus. People like to follow what the majority does even if it's suboptimal.
not just like to follow, but are forced to follow.
I don't remember why but I had to download a separate notification app that pushed notis
Bloated server implementation with lack of alternatives and a complicated protocol.
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.
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.
The UIs are terrible. I've tried it a few different times with friends and we gave up each time.
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.
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.
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.
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.
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.
> 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.
Thank you, I was about to post a response similar to yours sans the "trying to buy licenses" part.
Yeah they told me to fuck off when I wanted to purchase Element One for server-side administration.
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.
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.
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.
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.
"load" is the correct term. What would you call it?
You just don't say the sentence at all and instead choose a technology from one of the big tech companies.
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.
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 5€/month. I’ve been doing this for multiple organizations and many years.
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.
> 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.
mostly the federate aproach. Most people dont want to think about anything network related.
Element is ok as an app imho
The UK is the number one enemy of security and encryption. Did you read and compile all of the libraries and clients yourself?
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.
> 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? :)
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.
> 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...)
> 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.
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?
> - Federation makes it challenging to be GDPR compliant
Can you elaborate? AFAIK when everything is encrypted, GDPR compliance is trivial.
Thanks for the info, what do you think about Delta chat?
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...
Which tool did you guys end up using?
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.
Why not Signal? I think that Matrix and Discord are for your circles of "friends" you don't actually know.
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?
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.
Never heard of Matrix before (as a protocol) what's it's advantage over XMPP?
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.
It's heavier and leaks metadata.
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).
https://xkcd.com/927/
Related, 3 days ago:
European Commission Trials Matrix to Replace Teams
https://news.ycombinator.com/item?id=46901452
I prefer tox
Why govt needs e2ee? Transparency is all we need.