There’s a surprising amount of negativity in here. Matrix is great for me. I’m happy to see the improvements. I’m also happy to hear the team is approaching sustainability. Matrix isn’t perfect but it has only improved in the 5 years I’ve been using it. I’m looking forward to what they can do in another 5 years.
I think HN just tends to be negative, though it seems to be getting more negative. I think a lot of people don't understand that finding problems is easy. Fixing them is hard. Which yes, you need to identify first but criticize, don't complain.
But it's funny because anytime someone talks about Signal lots of people point to Matrix as "better". I'm not going to do the reverse because they solve different problems, which is okay. Besides, we should have a diversity of platforms, competition is good and there's no one size fits all. Biggest problem is people thinking there should be one superapp.
I'm pretty confident people are mostly forming opinions to justify their decisions rather than speaking from informed points of view. My evidence is that these platforms solve different problems. Personally, I don't use matrix other than occasionally playing around. But I'm glad it exists and want it to keep existing
> Matrix isn’t perfect but it has only improved in the 5 years I’ve been using it.
I'd very much like to disagree.
From the top of my head, in the past few years of using Element Web:
- Notification center is now gone.
- Room search is now only limited to official Matrix rooms.
- At peak it consumes ~2.2 GB of RAM.
- UI feels more sluggish by the day.
- Loading it now takes ~10 minutes.
- Using it as an IRC bouncer (to Libera) is now gone, which was what initially attracted me in the first place.
And I don't even use the voice / call functionality of Element Web.
I somewhat understand the reasoning behind the decisions, but I feel like they should have improved the UX first before working on the protocol itself.
It's still there; it just got moved into Labs given it never worked in encrypted rooms, and having a flakey feature for new users was (correctly) considered worse than not having a feature at all. Go look for "Enable the notifications panel in the room header (Unreliable in encrypted rooms)" in Labs on develop.element.io or Element Nightly.
> - Room search is now only limited to official Matrix rooms.
This isn't accurate. On one server (matrix.org) the room directory is currently locked down to stop it filling up with spam, however this should be opened up again to be a curated room list in the near future.
> - At peak it consumes ~2.2 GB of RAM.
> - UI feels more sluggish by the day.
> - Loading it now takes ~10 minutes.
So agreed that Element Web performance is very painful for power-users. This is because we've been putting all of our effort into fixing perf in the protocol itself (via sliding sync etc) using matrix-rust-sdk on mobile in Element X to prove it all out. We've also spent huge amounts of time on encryption reliability.
However, good news is that we've finally moved to Element X Web (codenamed as Aurora: https://github.com/element-hq/aurora), which runs matrix-rust-sdk in browser but with MVVM React components from Element Web for the UI. You can play with an alpha at https://dangerousdemos.net (non-permenant-URL) right now. In contrast:
- At peak it consumes 80MB of heap.
- UI feels instant and is O(1) regardless of account size
- Loading takes ~2 seconds (although that's about 20x slower than it should be given Aurora doesn't currently persist any local state, so it's loading everything from scratch on launch).
> - Using it as an IRC bouncer (to Libera) is now gone, which was what initially attracted me in the first place.
Agreed that this sucks. We did everything we could to stop Libera removing the bridge, but failed due to lack of $ meaning we didn't have enough dedicated manpower to meet Libera's demands.
> And I don't even use the voice / call functionality of Element Web.
Element Call's actually rather good, in terms of providing end-to-end encrypted group calling. If you used it you'd probably complain that we broke backwards compatibility with the legacy 1:1 Matrix voip calling though, which would be true; again, due to lack of dedicated manpower.
> I somewhat understand the reasoning behind the decisions, but I feel like they should have improved the UX first before working on the protocol itself.
To improve the UX with clients, we had to improve the protocol, and Element X shows how good that UX improvement is. We're now catching up on Web.
Really appreciate your work and am thankful for matrix and element.
As a user of Element call via the desktop app, I found myself sometimes confused whether I was actually using the new implementation or the legacy version.
Has the move to encrypted calls happened on the non-element-x platforms? Is there a difference between group and one-on-one calls on those platforms?
> a flakey feature for new users was (correctly) considered worse than not having a feature at all.
Would you say that implementing a flakey feature in the first place was a bad idea? I'd think that once users get dependant on a certain feature (no matter how lacking in its usefulness), it's going to be tougher for them taking it away than not shipping it in the first place.
> On one server (matrix.org) the room directory is currently locked down to stop it filling up with spam
Yes, that's what I was initially talking about since I'm (mostly) on the matrix.org homeserver. I'm glad this is a temporary situation.
Oh I wasn't aware of this. This is excellent news!
I hope it gets lots of attention in the (near) future. I'm guessing that the enshittification of Discord is about 2 to 3 years away at this point, so I believe having a proper alternative would do wonders for the open ecosystem.
> To improve the UX with clients, we had to improve the protocol.
While I believe this to be the best way forward, was it also the fastest way to acquire a userbase? If we look at Bluesky for instance, they pretty much did the reverse of what Matrix.org did, and (I think) thus was in a position to garner hefty growth as a result.
> Would you say that implementing a flakey feature in the first place was a bad idea? I'd think that once users get dependant on a certain feature (no matter how lacking in its usefulness), it's going to be tougher for them taking it away than not shipping it in the first place.
I actually wrote the notification panel in the first place: https://github.com/element-hq/element-web/pull/2113 and when we shipped it, it worked fine. However, this was 2016, before Matrix had E2EE (which eventually got turned on by default in 2020), and E2EE complicates notifications enormously, given the server can't read the messages in order to figure out whether they're a notification or not. So, instead, the client has to calculate notifications instead, which (worst case) means it has to spider every message in every E2EE room to figure out whether to notify based on keywords, mentions, event type, etc.
So, rather than hooking up all that logic in Element Web, we left NotifPanel as is, working fine for unencrypted rooms (and working best-effort for encrypted ones, iirc), instead focusing on fixing Matrix's famous decentralised E2EE stability (Unable To Decrypt errors), which literally took years. Then, rather than implementing proper notification logic in duplicate across both js-sdk (Element Web) and rust-sdk (Element X), we focused on nailing it in rust-sdk - and meanwhile hid the feature on Element Web until we can swing Element Web over to use rust-sdk (Aurora).
So to answer your question: we didn't ship a flakey feature in the first place. But hiding it once it got flakey rather than even further slowing down our progress on stabilising E2EE (given we don't have manpower to adequately to maintain two stacks) definitely feels defensible.
A more interesting question is whether we've done the right thing by rewriting all the platforms to use a shared Rust core. However, we're not alone in doing that sort of transition: https://github.com/signalapp/libsignal etc.
> > To improve the UX with clients, we had to improve the protocol.
>
> While I believe this to be the best way forward, was it also the fastest way to acquire a userbase? If we look at Bluesky for instance, they pretty much did the reverse of what Matrix.org did, and (I think) thus was in a position to garner hefty growth as a result.
We know the Bluesky team quite well, and I strongly suspect they learnt from Matrix's misadventures (just as we in turn learnt from XMPP's). My FOSDEM talk this year was literally about this: https://youtu.be/lkCKhP1jxdk?t=490. Empirically Matrix is good at ecosystem uptake (better than Bluesky) but worse at mainstream. It's never too late to change though.
I can't tell if this comment was written in jest or not.
It's always protocol improvements and 'it's coming in the next version's or 'msc #xxxx just got approved' with Matrix.
It's always someone saying 'oh this next version fixed all that' and then someone says 'well what about mobile' or 'what about desktop's and then someone says 'actually it doesn't fix it there.'
I'd love matrix to be the solution to my communication problems but it just isn't.
While that would perhaps be the best solution in the long run, wouldn't you agree that gains in userbase necessary for growth (or at least sustainability) are predicated upon how good the UX is _currently_ ?
My minimum requirements for personal online communication outside of public web-accessible forums like this one, are open protocol, open source implementations, optional E2EE, independent hosting, client choice, and access to channels on other independently hosted servers. These are non negotiable for building my social graph of communication with family, friends, colleagues, etc.
Communication is a sacred part of the human experience and I will not allow centralized entities to control my primary means of connection to my friends and family.
My options for digital comms are then are limited to email, IRC, XMPP, or Matrix.
Matrix has leaps and bounds the best UX and functionality by this criteria and is what I use for the overwhelming majority of my communications.
Anyone that is exclusively willing to communicate over corpotech disrespects my values for freedom and privacy, and is by extension opting out of being friends with me unless we see each other in person regularly.
9/10 times the people that respect me and want to be friends with me also respect my ethical conviction and create matrix accounts to talk to me if they do not already have one.
Taking back control of the internet will require conviction and I try to lead by example in my social circles. I personally could not give less of a shit if Matrix has feature parity with xyz corpotech as they are not solving the same problem. I also use IRC heavily to talk to many of the best engineers in the world and that is a low UX bar to beat.
That said, as corpotech walled gardens keep screwing their users, more and more hold-outs will come over and new features and improvements will reduce that friction over time.
For now though very few individuals understand the vital importance of digital sovereignty for a citizen controlled society, but governments absolutely get it and do not want people like Zuck controlling their comms, so it is not surprising governments are first in line willing to pay for help switching to Matrix. The people will follow in time.
If you give up on E2EE (which isn't useful on smartphones anyway since the users have so little control over the OS and app distribution) email works, nearly everyone has that. If you use eg jmp.chat you can use email, other people can talk to you over SMS, and you can just pretend all this retarded crap doesn't exist.
In the decade prior to me abandoning cell phones entirely I used E2EE email frequently on Android via OpenKeychain and K-9Mail with a Yubikey.
I did not want to be locked into Google or Apple ecosystems and the ship on a truly FOSS Android device has long sailed, so I ported my number to a VoIP provider and only use PCs now.
To your point -any- E2EE on proprietary platforms like iOS or Android cannot be trusted for high risk comms, so at my infosec job we exclusively use Matrix from QubesOS workstations.
But yes email is normally the go-to fallback except with Gen Z who almost universally refuse to use it having grown up exclusively using corpotech.
Probably because it's hyperbole. I've been using element web for a long time and have not seen those kinds of issues. Not to say that it is perfect, there are definitely bugs.
I don't think that is normal, at least I've never had any client take that long to load, and nobody I communicate with on matrix has ever mentioned that as being an issue either.
it may have to do with many of us on HN not getting the target audience for Matrix. It works great for a ton of people. Their usage stats speaks for itself.
But there are reasons it isn't competing with discord, slack or teams. I would like to say a lot of that has to do with matrix.org not having a serious/good commercial play, but I think it's a lot more nuanced than that.
Matrix is sort of like Mastodon and Lemmy in its target audience and usage, and there is nothing wrong with that. But I think a lot of us wanted something like Bluesky but for chat apps.
Marketing and UI are very important. something like Signal can get away with being terrible at it because they were able to get publicity and marketing from snowden, politicians,etc... I even think Matrix is a better OMEMO/E2EE communication client than Signal. But having a good product isn't enough, the user experience needs to be competitive for the general public to join and things like branding and publicity are especially important for Matrix because a good product other people aren't using isn't usable for communication purposes.
Don't get me wrong, I know the matrix team is well aware of this and they try their best, but it seems for now at least they know their target audience and that audience is happy enough with it. I suspect in Europe at least they're going to do really well. Whatsapp and Viber are very popular east of the Atlantic. Matrix should focus on disrupting those. Having something like whatsapp numbers instead of full on user id's (or translating them) for example would help compete there.
Matrix is carving out a nice but they're developing it like it should be competing with the bigger/dominant players. I interact with very technical people that are into opensource, development, security, etc... and every single time, I am the first person they hear about Matrix from.
If you're doing consumer chat with friends and family, I'd recommend Signal over Matrix or Zulip.
For a community: A lot of communities want anyone in the public to be able to join their spaces and read their channels. For that use case, E2EE makes the chat system slower and less usable, with limited security benefits over using web standard encryption.
What E2EE may protect you from is a malicious server operator reading the organization's messages. If the server operator is a leader in the organization already, that person may already be directly a recipient of all the interesting messages anyway. The practical benefit I see for E2EE in Zulip is mainly for Zulip Cloud or other settings where a third party is hosting the Zulip server for you.
As for decentralization, a self-hosted Zulip server only talks to external infrastructure for sending notifications (Emails, mobile push) and to implement user-controlled features (E.g., outgoing webhooks). The Zulip API is fully documented, easy to understand and implement, and has community-developed clients.
Maybe you're thinking of federation? Matrix has fancier mirroring functionality, which can be important if your use case requires sharing dozens of channels with dozens of other servers. But Zulip is supported by Matterbridge and has various nicer mirroring integrations for sharing a channel with another server on various protocols.
But I don't know of many use cases where the usability of the core chat system isn't far more important than the usability of federation features.
Signal is a non starter. Never had an account and barring major architecture changes, I never will. Weakly secured centralized control of metadata with no option to self host your way out of it, and a requirement of a phone number which makes it a non starter for friends in countries that have good reason to be anonymous.
Zulip is at least self hostable but all private conversations in plain text on the server and lock-in to only being able to access chats on the one server are also both non starters. It is not a matter of trusting the admin, it is trusting that the Linux server was deployed with no exploitable flaws, and the admin never gets a court order. Too much trust for me.
Zulip is maybe a nicer UX alternative to IRC, but it is not comparable to Matrix.
Every new release or "This week in Matrix" post I check to see if Discord style detailed permissions and voice channels get added and every time I get disappointed. I fear it'll never be added at this point due to the funding issues. I hyped it up to all of my friends who stick to Discord that "One day" it'll compete with Discord and we, and millions of others can all finally be happy. I hope that day will come, but my hope is fading.
What would you say the delta is between Element's current video-rooms and Discord-style voice-rooms (if you go and mute video for everyone), ooi? The only reason Element hasn't implemented precisely the same UI as Discord is because it's not (currently) trying to be a Discord competitor, but more a "run your own encrypted Teams alternative", given that's what Element customers are asking for right now, and we're having to follow the money to try to get sustainable. However, what we're trying to do is to ensure that Discordish features still work, despite having to focus more on Teamsish features.
In terms of permissions: I'm a bit surprised that folks feel limited by Matrix's freeform hierarchy of permissions. Every user can have a 'power level' from 0 to 100, and you can then customise the threshold required for literally permission (e.g. you need power level 54 or higher to kick users, or whatever). The only difference with Discord is that Discord lets you pick entirely arbitrary combinations of permissions (e.g. have one user able to kick but not ban, but another user able to ban but not kick, or whatever). How useful really is this in real life usage though?
I'm trying to work out whether the problem is if Element's UI for configuring permissions is too basic, or whether folks really do need a full RBAC permission matrix, and if so, for what use case?
The power level model of permissions feels to me a bit overly simplified. It’s so easy to imagine scenarios where you need exceptions to the rule of permissions existing on a single axis that it seems very limiting from the outset.
The idea of ever increasing and overlapping scopes I don’t think maps well to most people’s mental model of who should be allowed to do what. People mostly want to define an arbitrary role; admin, user, team leader, whatever, and just pick what that role is allowed to do in isolation. It’s marginally more work to setup initially picking all of the permissions again, but it removes all of the overhead of having to monitor what permissions are being adopted from lower scopes on the power level axis.
I also think the power level system makes it much harder to “refactor” permissions for specific roles without affecting permissions for everyone “above and below”
In my experience with running Discord servers you setup a couple of hierarchical roles (admin, moderator, user etc) when you first setup the server and never again.
However I'm constantly adding new roles which are really just groups of users. I would say 90% of all the Discord roles I've ever created have no permissions associated with them at all and just exist to ping a group of users (or act as a tag for bots).
Maybe that's served by a different feature in Matrix for user groups. If so, that's still not quite as useful, because sometimes later on you decide the group needs a permission (e.g. a casual gaming group has grown enough to justify having it's own channel).
Right - this matches my hunch; that folks want to define groups of users (which you can already in Matrix in 'spaces', but the UX in most clients is awful) - and what they really want is group-based permissions (which isn't part of the protocol, and instead gets layered on at the application layer today.
So the problem here isn't that folks want contradictory access levels (e.g. Admins can kick people but can't set topic, but Mods can kick people but can't set topic) but the ability to set them via group?
the discord style permissions are simply easier to understand. it's classic role based. you define the roles, and assign the roles to users. matrix permissions forces a hierarchy that is awkward and more difficult to apply because i have to force permissions into a hierarchy. on discord i don't have to think about the hierarchy.
I know of nobody who even knows of Matrix, if I haven't told them beforehand. Discord is so much better than all alternatives, that I just don't see why anyone would leave it.
Not really, because the security of letters is guaranteed by the state. The security of Discord is guaranteed by some private citizens based in the US. At least on paper the state exists for the benefit of the people. Discord exists for the benefit of investors who primarily seem to operate out of China and the US - foreign countries to me.
There's cinny, which is a pretty polished Matrix client that is very, uh, inspired by Discord in its look, that might soon add voice rooms: https://github.com/cinnyapp/cinny/pull/2335
I played around with this implementation and it's looking pretty good. Not there yet, obviously, but we're in the ballpark I'd say.
Obviously, there's lots more to Discord than just voice rooms and a similar-enough UI. But we're slowly getting there.
It baffles me that when you install the Element App (which uses matrix.org by default), you can not easily find any of your friends, because you cant “connect” your phone number…
This makes the App a no-go for everyone and their grandmother. The registration and setup process was so cumbersome, even people with some tech knowledge in my friend circle had trouble getting it to work.
Anyway, it seems so user hostile, why not just make connecting a phone number optional? That would attract many more people?
You can add your phone number.. But I don't know if it can actually be used to find you, even though it's the stated purpose :). You can find it from Settings/Security and Privacy.
Most probably don't add it anyway because it's far from mandatory (I haven't created an account for some time, but I assume it's not part of the flow), so it probably wouldn't work out great in practice.
We disabled it on matrix.org because it was being used for 2FA SMS fraud, costing us $$$K, and we didn't want to burn time building an anti-fraud system. Getting access to everyone's phonebooks is also a privacy risk (even if you do fancy stuff with SGX like Signal does).
Meanwhile, government deployments typically have LDAP or similar to discover users - and so it hasn't come up as a big requirement for the folks generating $. It's on the radar though as one of the main blockers for mainstream uptake... but right now we're trying to keep the lights on first before focusing on accelerating mainstream uptake.
That makes sense, hopefully it’s something that can be resolved sometime soon. Would be great if mainstream people have another, privacy conscious, alternative to big tech…
The part you apparently don’t understand, is that this is (unfortunately) currently the reality: it’s what most people use now.
We can’t expect everyone and their grandmother to switch to a perfect e2e alternative overnight.
Meanwhile, i need a way to communicate with everyone, preferably as secure as possible.
I like the idea of matrix and element, but the execution is just so lackluster. Even Signal added a lot of quality of life improvements, and WhatsApp is consistently getting better. I don't like the idea of using a messenger owned by Meta, but honestly, messengers absolutely need an excellent UX and UI, QOL features, etc. and Element is just far behind in this regard.
The official client is clunky and being electron on the desktop doesn't make it better. Messengers live and die on UX. Since it's an open protocol alternative clients exist of course, but are often not feature complete. Things are often slow, especially with large group channels with lots of messages.
If you host a server yourself - it's great that you can! - you'll try the official implementation, synapse — ...and discover that it's a resource hog. Things got a bit better with some streaming sync protocol or something like that, but last time I looked it up that was still experimental and the server is still a chonker. Again, alternative servers exist, again the problem with feature parity.
I feel like the protocol is bloated as well, but I didn't dive into it too much to have a good opinion on that.
When choosing a messenger, I go to Signal for security, to IRC for simplicity and to Telegram for UX. I never thought "Oh let's use Matrix"...
Alternative clients feel like a broken promise to me, since features seem to be optional or implemented differently. You're basically stuck with Element if you want to be reasonably sure you're seeing what other people are.
Even the official clients are a little weird. Element X, their next gen super fast client released in 2023, still won't allow me to create a thread on iOS. It will let me put a caption on a photo though, but Element won't.
From time to time, I go and check if there's a stable non-Electron Matrix client available - Qt would be nice. Thus, I'm still on IRC. I've tried participating in some bridged Matrix channels, but the IRC bridges I've encountered were super annoying. All messages come from one user, the bridge. Very often, the same message gets repeated twice or more, for some reason. I guess Matrix has no limit on usernames, so some users have names that are more than a line long. It's all very tedious.
The QT client for Matrix is called Nheko: https://nheko-reborn.github.io/
There's a client in just about every toolkit. Just takes a cursory internet search...
Unfortunately, they still use libolm[1] for e2ee which is deprecated[2] and has known security issues[3]. The maintainers appear to not be interested in switching to the newer Rust-based library. Matrix argue that the timing channel attacks are not possible over a network, but the history of timing channel attacks argues that this very few protocols are this fortunate (most people thought timing attacks against TLS were impossible too, until someone bothered to attack them).
Yeah, although Matrix is theoretically about being an open protocol supporting a range of clients and servers, in practice it winds up being heavily skewed to just Element/synapse. I think this is partly because there is still too much churn in the protocol. A decent amount of that churn is improving things, but it still makes it too hard for average-joe devs to keep up with what's hip. I don't think there's much chance of a real menu of feature-rich clients until the protocol becomes stable. Unfortunately, I don't foresee that happening soon.
AFAIK none of that churn is around functionality that actually matters that much to end users, however. Certainly nothing as important as “working clients”.
There's also a really great Gtk client called Fractal from GNOME; it uses the same matrix-rust-sdk as Element X: https://gitlab.gnome.org/World/fractal.
Meanwhile the plan for Aurora (Element X Web) is to run it in Tauri or similar to placate all the Electron-haters: https://github.com/element-hq/aurora
There is also Neochat from KDE, not fully featured like Element and E2E Encryption still experimental the last time I checked, but it is a nice alternative if you want a non-Electron client.
> synapse — ...and discover that it's a resource hog.
I thought that, too, but at the very least it probably grows with usage. On my single-user-server, synapse currently needs ~100MB of RAM and does not consume CPU at all. It's not "slim" but I wouldn't call it a resource hog either.
One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X: https://element.io/blog/we-have-lift-off-element-x-call-and-... etc. Element X kicks ass, in my (very biased) opinion: it's a super-speedy Rust core with fancy SwiftUI and Compose native UI layered on top. It radically outperforms any other encrypted messenger i've used in terms of UI perf and usability.
However, because it's a rewrite, it doesn't quite have feature parity with the old apps, which are now over 10 years old: Threads is in beta; Spaces haven't landed yet, and Widgets aren't implemented yet. Therefore, we have to keep the old app around for users/customers who depend on those.
As a result, >80% of the people who say "Matrix sucks" are actually talking about bad experiences on the old Element mobile apps - rather than better client Element X or indeed Matrix clients from other folks.
There's also a large set of people who got bitten by encryption problems, almost all of which were fixed by Sept 2024.
Finally, there's folks who got bitten by the sad history of bridging in Matrix: IRC bridging used to be relatively okay; the team then got very stretched due to lack of funding; we tried to land a major PR to improve its architecture; the PR introduced bugs; Libera got very upset; we tried to fix things but failed to do fast enough. As a result, bridging to Libera in particular is awful these days, using adhoc bridges which funnel all traffic through a single user, with no ability to join arbitrary IRC channels on demand or use Matrix as a bouncer.
These days, the priority at Element is providing a self-hosted, decentralised WhatsApp and Teams replacement for governments... and once we get sustainable doing that, we'll be able to spend time building community features once again.
Okay, but they do that because they used those apps, and they did that because you released those apps and said the same thing you're saying now ("use our app, it's really cool"). Surely you can understand why someone who dealt with that is going to be suspicious of "this time for sure".
> However, because it's a rewrite, it doesn't quite have feature parity with the old apps, which are now over 10 years old
So people can either judge based on "legacy" apps that do more, or the shiny new app that does less. Again, surely you can understand why people might be disappointed with both of those.
There isn't any way to avoid being judged on your whole history.
I recently tried Element X. I will say the onboarding was better, although that comes with the caveat that I'm not sure how that would go if I didn't have another device at hand to verify with. And UTD errors have definitely decreased (across all clients). Apart from that, the UX is okay, but I don't see it as radically better than the old Element.
There has been a good deal of improvement in Matrix, which I appreciate and kudos are due to you and the team for that. But I think it's a bit of a stretch to make claims like Element X being "radically better" than any competitor. And, importantly, making grandiose promises like that increases the risk of losing trust if people's experience isn't absolutely stellar.
I think this is a pretty fair summary. I've been using matrix since before the patreon was started and it's gotten a whole lot better for sure, but there is still no single client that does everything. Element X is right out since it doesn't support spaces yet. SchildiChat next comes close for me, but it can't edit room topics, pinned messages can get a bit weird once you start editing them, and I have a few invites to some pretty nasty looking spam dms that I can't delete, so there are still some rough edges.
On the desktop side, if there were a client as good as SchildiChat maybe that would work, but last time I tried one of the Element desktop clients I wasn't even able to log in (it either crashed or hung, can't remember), and most of the time I'm fine with Fractal anyway. Fractal is actually a very nice client for what it does, it just has a limited feature set: missing spaces, copy/paste doesn't quite work like you'd expect, no search (I'm not sure there are any clients with fully functioning search for encrypted rooms), and my memory is that heic image previews weren't supported. I can fall back to nheko for some of the other things when needed.
As far as I know, there aren't any clients that support the new element call unless you enable the labs feature in element x.
All that said, I can't overstate how much I appreciate all the work the matrix devs do, and it is still fine for my daily use. Even if I sometimes disagree with Arathorn's conclusions about how ready matrix is, I have to appreciate the optimism and I imagine it is part of why he's been able to continue through all the negativity :) and it's not entirely wrong to say that matrix beats the competition - I'd say it easily beats teams and imessage (teams does not deserve to be mentioned in the same sentence as anything else), and it is mostly comparable with messenger and whatsapp. Slack probably has it slightly beat, and discord is leagues ahead of everything else.
I think an early major mistake was that Matrix spent all this time and energy designing a general synchronization protocol, but not doing it in terms of native encryption and cryptographic identities. This was post-Snowden, and it was glaring at the time.
Bolting on encryption after the fact then sucked so much energy out of the ecosystem for clients. This one doesn't implement encryption, that one does but it has bugs/warts/etc, this other one does if you pull this year-old experimental branch and build it yourself. The web (-technologies) client became the de facto one because it "worked", despite being bloated and laggy - reliable tools don't even have the code to show these spinning delay circles that have become synonymous with the web ecosystem.
I don't want to be entirely negative because I do see it as the least-worst messaging option available. I use it for communicating with a bunch of friends and things do seem to be getting better, and I look forward to when I can actually switch to its window to type a message and not wait around for redraw / garbage collection / reloading messages from server /etc. That might be on me for not having surveyed native clients recently or tried Element X on my desktop, but that's exactly the negative momentum I'm lamenting above.
That's true, but in another sense I think it's just that trying to "do it all" encryption-wise is significantly harder than some people realize. Having encryption that's really "safe" raises barriers to casual use that most casual users aren't really willing to accept.
Like suppose I use Matrix only on my phone, so I just have the one device. Then I lose my phone and have to get a new one. How do I regain access to my account, including all of my old messages? Or suppose I (still using Matrix only on my phone) decide I need to log out because I want to let someone else (a friend, my kid) use my phone for a while and don't want them snooping in my messages. How do I retain access to all the messages I receive while logged out?
I'm not saying these are problems with Matrix; they would be problems with any service that attempts to cover the same bases (in particular, e2ee with forward secrecy and multiple independent devices). The average user's conception of a messaging service is "I can log in with my password and then have total access to all of my messages, past, present and future." There are too many ways to break that assumption if you try to have perfect forward secrecy and all these other desiderata that encryption wonks care about but normal people don't. I think this is one reason there's still a big gap between comments on HN saying "matrix still works fine for me" and the tales of "I tried to get my grandma to use this and it was a disaster". I don't think it makes sense to try to roll Matrix out for general use, or say it's "the best messaging app" until it can smoothly handle all of those use cases.
I'd say that all of those usability problems are made worse by bolting on encryption after the fact. It makes it so there are now two layers of authentication/identity, rather than a single one. Whereas with built in encryption, you can always punt on solving the problems you list and make implementations that are less secure. For example, just store the keys on the server, accessed by the password. That's obviously less secure, but not less secure than no encryption.
Yeah, I don't disagree. Just saying that even if they had put encryption in at the outset, there are still tough issues to solve in terms of integrating that with user expectations.
> One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X
Which is mobile-only. Element's UX on desktop is still a joke.
> These days, the priority at Element is providing a self-hosted, decentralised WhatsApp and Teams replacement for governments... and once we get sustainable doing that, we'll be able to spend time building community features once again.
In other words, you don't have the community's best interests in mind, but we should rest safe because you'll have their best interests in mind at some point in the future, maybe.
> In other words, you don't have the community's best interests in mind, but we should rest safe because you'll have their best interests in mind at some point in the future, maybe.
I'd argue that by having spent >10 years building out Matrix and Element as open source, we've demonstrated that we have the FOSS community very much in mind. But we'll only be able to continue doing that as our day jobs if we can pay our salaries, and the way to do that appears to be to sell enterprise Matrix distributions to Governments. Once we get financially sustainable doing that, we'll be able to focus more on the community again.
> Not very reassuring.
Au contraire, mon capitaine; I find it very reassuring that Element might finally be approaching a position to keep working on improving Matrix indefinitely :D
Well, it looks like my overly cynical response wasn't warranted. Best of luck in your future endeavours and I hope you manage to get the money you need without locking too many features behind enterprise Matrix.
EDIT: I do still find issue with the claim that Element X is the solution to every UX problem though. Sure, you've begun experimenting with a web version of it, but it's still in the very early stages - it's not exactly production-ready.
You're probably right that it's the UX of the OG Element that was the original problem people got hung up on but Element X isn't actually a relevant answer until it's usable, regardless of how much better it sounds like it will be on paper. A secondary problem people got hung up on was the endless parade of "you're just using the wrong client, try ${this}" and then finding it was missing half the things that they were told Matrix can do.
I'm still optimistic about Matrix but I am a bit worried that it has lost a lot of steam because of this UX history.
It's been years of seeing Matrix posts being made on hn here (and founder - that is you - enthusiastically replying to comments; which is actually nice that you still care) and even that is long after I finally gave up on it realising it is (and now it seems was never even planned to be) a communication tool for the "masses" or end users - you know - you, I and our friends and family... kind of.
Reason? It is still "work" to even try to start using Matrix and yes I tried the kicks-ass-new-swift-client and it seems to be just another dull almost useless iOS messaging app which was done as a proof of concept of an open source project with very high values and goals and completely missing the point of usability and what people need and where smartphone messaging is today.
Also by the way - how many has it been? Matrix -> Riot -> Element.. is it changing again now?
> 80% of the people who say "Matrix sucks" are actually talking about bad experiences on the old Element mobile apps
Maybe 100% of times you are missing the point why people think that way by just assuming this?
> self-hosted, decentralised WhatsApp and Teams replacement for governments
Well, I do hope you realise that "Govt as the entity" per se that would not use these apps - but "the people" (which actually kinda comes back to you, I, and our friends) in those governments will use those apps and services.
> I finally gave up on it realising it is (and now it seems was never even planned to be) a communication tool for the "masses" or end users - you know - you, I and our friends and family... kind of.
However, we have to fund our work on this, and the Matrix team at Element do so right now by building digitally-sovereign comms apps for governments. The reason is that generating funding out of mainstream consumer messaging apps is very hard when you are competing against 'free' (WhatsApp, iMessage, Signal) and when you aren't in the business of monetising data/metadata or selling ads or AI. Signal has problems with funding even at the scale they're operating, for instance. So, instead, the strategy has been to focus on getting $ from governments which in turn can then keep the lights on for everyone else. And I personally am continuing to jump through every hoop I can to try to get Matrix into mainstream use.
Perhaps an analogy is Linux On The Desktop. I'm sure when Linus created Linux he was hoping to create a generic kernel which could be used all over the place for everyone. As it happens, it first got traction serverside, and so lots of effort and focus went into refining that; meanwhile clientside Linux lagged a bit, especially as reconciling great UX with open source is... challenging. As a result, loads of people on /. or whatever complained bitterly about clientside Linux not being mainstream. As time went, on though, organisations subsequently focused on building great Linux-based clientside products like Android, Ubuntu, etc, and you could argue that Linux did eventually go mainstream on mobile, and may yet go mainstream on desktop. But it took ~20+ years to do so, due to the twisty path it took to get to critical mass.
> yes I tried the kicks-ass-new-swift-client and it seems to be just another dull almost useless iOS messaging app which was done as a proof of concept of an open source project with very high values and goals and completely missing the point of usability and what people need and where smartphone messaging is today.
You'll have to explain to me how EX misses "what people need and where smartphone messaging is today", as the feedback here feels a little unsubstantiated...
> Also by the way - how many has it been? Matrix -> Riot -> Element.. is it changing again now?
Matrix is still Matrix, and always has been. Riot got renamed to Element in 2020 and there are no plans whatsoever to change that. We should print t-shirts for folks who bring up the rebrand to hit us with 5 years later. Meanwhile, here's a shout out to Riot Games' lawyers for forcing us to rebrand in the first place...
> Maybe 100% of times you are missing the point why people think that way by just assuming this?
Maybe, but this is the first time i've heard someone complain about Element X (other than being impatient for threads/spaces); i have a high sample size of people confirming that it's a big improvement.
> Well, I do hope you realise that "Govt as the entity" per se that would not use these apps - but "the people" (which actually kinda comes back to you, I, and our friends) in those governments will use those apps and services.
Not entirely sure how to parse this, but if your point is that our competition for Govt end-users is Signal & WhatsApp, then totally agreed. Which is why we've focused on matching/outcompeting them with Element X.
Element One should support MAS + EX in the next 2-3 weeks.
Mozilla's EMS hosting got migrated over yesterday (at last)
60% of the rest of EMS-hosted servers are also migrated already.
Sorry it didn't happen earlier, but all our focus has been on getting on-premise deployments for people like NATO & the UN working excellently, and the SaaS deployments have been lagging.
which features are you actually missing? the only gap now is threads (in beta), spaces (in final design) and widgets (which were very very rarely used). the whole "i can't use X until it has precisely the same featureset as Y" feels a bit spurious, especially as you can run each app side by side and revert to the old one if you really need a given feature.
I think this happens a lot. At least a lot more than people think. Take Firefox vs Chrom{e,ium} (yes, that includes Brave). The differences are really minor and 99% of people wouldn't notice the difference. But boy do people have strong opinions. I'll make one argument for Firefox and I'm not sure other ones matter nearly as much: there needs to be competition in the browser space, and different colors of Chrome don't count. Having one backbone is good for no one. Yes, even Brave gives Google too much power over the entire internet. Hopefully Ladybird will become competitive, but in the mean time some of you should stop being dumb and use Firefox. Because frankly, it doesn't affect your browsing experience. You're just biased in your evaluation because things are "different".
The reason I brought that up is because there are so many parallels with what you're talking about with Matrix. Even down to the rewrite in rust and people acting like software hasn't improved in a decade. But the competition space is very important in chat platforms, just like browsers. You can support Signal and Matrix at the same time. They solve different problems. You can also use WhatsApp, Telegram, and/or iMessage or whatever. Competition is necessary in this space. We don't want monopolies. Especially if you're a firm believer in distributed systems! Distributed systems can become highly centralized. Just check your email account. I'll bet you have a Gmail account... I'll bet you also have an Outlook account. Or look at your phone!
Totally unrelated fun fact: people consider Coke and Pepsi an oligopoly, yet *combined* they only have a 70% market share. (This is definitely unrelated and definitely doesn't have any connection to our discussion...)
Because the product design people there seem to focus on an enterprise use case where the client is pushed out with a custom config to devices, instead of catering to end consumer usages.
I assume this is caused by the company that does the Matrix development getting its revenue from such customers.
I get the impression it is more designed to be a Slack replacement than a Signal or WhatsApp replacement, which is a shame.
No one is going to use Matrix that doesn't have privacy-focused contact forcing them to because the privacy benefit of the slight inconvenience is something almost nobody cares about. Things that are non-issues to someone who read the online Matrix documentation becomes a mountain to a middle aged mom who taps through errors without reading them and is used to things "just working" in the way Apple products just work, not the way Linux just works.
If you log into multiple devices, you have to go through a verification process to verify the new device. You may need to backup and restore your encryption keys manually or all your messages will be "Unable to decrypt message". Keeping multiple clients open simultaneously is supposed to have one client request the keys from the other client, but this either takes a while or doesn't always work. I have a contact with an unverified device (so all his messages show up with a warning) who refuses to fix it because all the other messengers just work by logging in. This is on top of people being upset that you're adding one more app to their menagerie of texts, Facebook, Whatsapp, Telegram, Discord, etc.
I use Matrix with my close contacts but I can't imagine anyone ever saying "Damn, I'm going to use this instead of Discord now!"
I tried it a few years ago and it was not friendly at all too. I'm sure it hasn't changed and everything felt confusing and complicated.
I don't remember the details but I have this feeling that I won't use it again. It seemed like the server could do everything (good) but they didn't found their niche (bad and impossible for such a generic framework).
Super happy to see matrix chug along. I’ve been self hosting dendrite home server for a long time but it doesn’t have sliding sync support, so can’t use the new modernized client. Anyone using conduit for self hosting and do you know if it works with the new client?
Room membership is still determined by the server rather than the client - but we now warn the user and freeze the room if devices which are not signed by their owner are present in the room.
Constraining the user membership to be controlled by the client is Hard in a fully decentralised world, but we're working on it: one option is MSC4256 (which pushes the whole problem to MLS); another option is to run Matrix's state resolution algorithm on the client (making the client implementation even more complex) to ensure that the client agrees with the server on the correct user membership.
Thanks a lot for chiming in! That's nice to hear it's better and improving.
View from 1000 feet: maybe a way to lock a room's users would be interesting? So that new users in, say, a DM room do not get decryption keys for messages from the client. Something like a weaker form of "only send messages to verified users", where you could have a DM room with (at most) 2 people.
Or, instead, maybe an option to disable forwarding session keys older than the user's room join event, to keep forward secrecy so that a new user does not get to read old messages (or does this already happen every 100 messages?).
> View from 1000 feet: maybe a way to lock a room's users would be interesting?
That's a really interesting idea - having immutable memberships could be a good band-aid. The problem is that right now the fact that room membership is typically mutable can be valuable: you add assistants into DMs (human or virtual); you can bridge the DM to other platforms; you can add (benign) audit bots for compliance purposes; you can migrate between Matrix IDs by inviting in your new ID and kicking out the old one; etc.
Of course, this same flexibility comes with a risk, and I see the point that it might be better to 'seal' membership if you know this is flexibility you don't want. We'll have a think.
> Or, instead, maybe an option to disable forwarding session keys older than the user's room join event, to keep forward secrecy so that a new user does not get to read old messages (or does this already happen every 100 messages?).
Currently we never forward session keys, so new users don't get to read old messages whatever. This obviously causes its own problems, especially for Slack/Teams style use cases where new joiners expect to be able to read conversation history. Work is ongoing right now to finally fix this (https://github.com/element-hq/element-meta/issues/39), but we are very mindful of the risk of not sharing existing history to the wrong users (or devices), which is one of the reasons it's taken so long to land.
The 100-message thing is separate: it's the maximum number of times a session-key ratchet can be advanced before it gets replaced. In other words, if you steal a session key, you can only use it to decrypt a maximum of the 100 subsequent messages sent by that device.
Thanks again for taking the time running me through these things.
> we are very mindful of the risk of not sharing existing history to the wrong users (or devices), which is one of the reasons it's taken so long to land.
It's great to hear these things are kept in mind going forward, should hopefully mean it's less hard to make protocol changes when they are needed.
I use beeper to connect with WhatsApp.
Saves me from 4 device WhatsApp web limit that is imposed.
That said, I am personally not so keen on using matrix. Remember India government banned matrix and other apps for "facilitating terrorist communications".
I'm happy Matrix exists and I've been a user in deployments at more than one university (where - fortunately - Teams, Slack and all the other externally hosted stuff isn't even an option).
https://github.com/matrix-org/matrix-spec-proposals/pull/254... is the de-facto way that custom emoji are done today, but as you can see from the labyrinthine Matrix Spec Change, it still needs some work to get stabilised and formally merged into the spec. Meanwhile, folks are always welcome to use experimental MSCs in the wild.
There’s a surprising amount of negativity in here. Matrix is great for me. I’m happy to see the improvements. I’m also happy to hear the team is approaching sustainability. Matrix isn’t perfect but it has only improved in the 5 years I’ve been using it. I’m looking forward to what they can do in another 5 years.
I think HN just tends to be negative, though it seems to be getting more negative. I think a lot of people don't understand that finding problems is easy. Fixing them is hard. Which yes, you need to identify first but criticize, don't complain.
But it's funny because anytime someone talks about Signal lots of people point to Matrix as "better". I'm not going to do the reverse because they solve different problems, which is okay. Besides, we should have a diversity of platforms, competition is good and there's no one size fits all. Biggest problem is people thinking there should be one superapp.
I'm pretty confident people are mostly forming opinions to justify their decisions rather than speaking from informed points of view. My evidence is that these platforms solve different problems. Personally, I don't use matrix other than occasionally playing around. But I'm glad it exists and want it to keep existing
> Matrix isn’t perfect but it has only improved in the 5 years I’ve been using it.
I'd very much like to disagree.
From the top of my head, in the past few years of using Element Web:
- Notification center is now gone.
- Room search is now only limited to official Matrix rooms.
- At peak it consumes ~2.2 GB of RAM.
- UI feels more sluggish by the day.
- Loading it now takes ~10 minutes.
- Using it as an IRC bouncer (to Libera) is now gone, which was what initially attracted me in the first place.
And I don't even use the voice / call functionality of Element Web.
I somewhat understand the reasoning behind the decisions, but I feel like they should have improved the UX first before working on the protocol itself.
> - Notification center is now gone.
It's still there; it just got moved into Labs given it never worked in encrypted rooms, and having a flakey feature for new users was (correctly) considered worse than not having a feature at all. Go look for "Enable the notifications panel in the room header (Unreliable in encrypted rooms)" in Labs on develop.element.io or Element Nightly.
> - Room search is now only limited to official Matrix rooms.
This isn't accurate. On one server (matrix.org) the room directory is currently locked down to stop it filling up with spam, however this should be opened up again to be a curated room list in the near future.
> - At peak it consumes ~2.2 GB of RAM.
> - UI feels more sluggish by the day.
> - Loading it now takes ~10 minutes.
So agreed that Element Web performance is very painful for power-users. This is because we've been putting all of our effort into fixing perf in the protocol itself (via sliding sync etc) using matrix-rust-sdk on mobile in Element X to prove it all out. We've also spent huge amounts of time on encryption reliability.
However, good news is that we've finally moved to Element X Web (codenamed as Aurora: https://github.com/element-hq/aurora), which runs matrix-rust-sdk in browser but with MVVM React components from Element Web for the UI. You can play with an alpha at https://dangerousdemos.net (non-permenant-URL) right now. In contrast:
- At peak it consumes 80MB of heap.
- UI feels instant and is O(1) regardless of account size
- Loading takes ~2 seconds (although that's about 20x slower than it should be given Aurora doesn't currently persist any local state, so it's loading everything from scratch on launch).
> - Using it as an IRC bouncer (to Libera) is now gone, which was what initially attracted me in the first place.
Agreed that this sucks. We did everything we could to stop Libera removing the bridge, but failed due to lack of $ meaning we didn't have enough dedicated manpower to meet Libera's demands.
> And I don't even use the voice / call functionality of Element Web.
Element Call's actually rather good, in terms of providing end-to-end encrypted group calling. If you used it you'd probably complain that we broke backwards compatibility with the legacy 1:1 Matrix voip calling though, which would be true; again, due to lack of dedicated manpower.
> I somewhat understand the reasoning behind the decisions, but I feel like they should have improved the UX first before working on the protocol itself.
To improve the UX with clients, we had to improve the protocol, and Element X shows how good that UX improvement is. We're now catching up on Web.
Really appreciate your work and am thankful for matrix and element.
As a user of Element call via the desktop app, I found myself sometimes confused whether I was actually using the new implementation or the legacy version.
Has the move to encrypted calls happened on the non-element-x platforms? Is there a difference between group and one-on-one calls on those platforms?
Is Jitsi still in use anywhere?
Thank you for your extensive reply.
> a flakey feature for new users was (correctly) considered worse than not having a feature at all.
Would you say that implementing a flakey feature in the first place was a bad idea? I'd think that once users get dependant on a certain feature (no matter how lacking in its usefulness), it's going to be tougher for them taking it away than not shipping it in the first place.
> On one server (matrix.org) the room directory is currently locked down to stop it filling up with spam
Yes, that's what I was initially talking about since I'm (mostly) on the matrix.org homeserver. I'm glad this is a temporary situation.
> However, good news is that we've finally moved to Element X Web (codenamed as Aurora: https://github.com/element-hq/aurora),
Oh I wasn't aware of this. This is excellent news! I hope it gets lots of attention in the (near) future. I'm guessing that the enshittification of Discord is about 2 to 3 years away at this point, so I believe having a proper alternative would do wonders for the open ecosystem.
> To improve the UX with clients, we had to improve the protocol.
While I believe this to be the best way forward, was it also the fastest way to acquire a userbase? If we look at Bluesky for instance, they pretty much did the reverse of what Matrix.org did, and (I think) thus was in a position to garner hefty growth as a result.
> Would you say that implementing a flakey feature in the first place was a bad idea? I'd think that once users get dependant on a certain feature (no matter how lacking in its usefulness), it's going to be tougher for them taking it away than not shipping it in the first place.
I actually wrote the notification panel in the first place: https://github.com/element-hq/element-web/pull/2113 and when we shipped it, it worked fine. However, this was 2016, before Matrix had E2EE (which eventually got turned on by default in 2020), and E2EE complicates notifications enormously, given the server can't read the messages in order to figure out whether they're a notification or not. So, instead, the client has to calculate notifications instead, which (worst case) means it has to spider every message in every E2EE room to figure out whether to notify based on keywords, mentions, event type, etc.
So, rather than hooking up all that logic in Element Web, we left NotifPanel as is, working fine for unencrypted rooms (and working best-effort for encrypted ones, iirc), instead focusing on fixing Matrix's famous decentralised E2EE stability (Unable To Decrypt errors), which literally took years. Then, rather than implementing proper notification logic in duplicate across both js-sdk (Element Web) and rust-sdk (Element X), we focused on nailing it in rust-sdk - and meanwhile hid the feature on Element Web until we can swing Element Web over to use rust-sdk (Aurora).
So to answer your question: we didn't ship a flakey feature in the first place. But hiding it once it got flakey rather than even further slowing down our progress on stabilising E2EE (given we don't have manpower to adequately to maintain two stacks) definitely feels defensible.
A more interesting question is whether we've done the right thing by rewriting all the platforms to use a shared Rust core. However, we're not alone in doing that sort of transition: https://github.com/signalapp/libsignal etc.
> > To improve the UX with clients, we had to improve the protocol. > > While I believe this to be the best way forward, was it also the fastest way to acquire a userbase? If we look at Bluesky for instance, they pretty much did the reverse of what Matrix.org did, and (I think) thus was in a position to garner hefty growth as a result.
We know the Bluesky team quite well, and I strongly suspect they learnt from Matrix's misadventures (just as we in turn learnt from XMPP's). My FOSDEM talk this year was literally about this: https://youtu.be/lkCKhP1jxdk?t=490. Empirically Matrix is good at ecosystem uptake (better than Bluesky) but worse at mainstream. It's never too late to change though.
Have you considered that multiple of your complaints could be addressed by protocol improvements?
I don't see this, since the complaint is about things that used to work and not things that are still missing.
Things working well with a few channels and a few hundred people are very different than working with thousands of channels and thousands of people.
I can't tell if this comment was written in jest or not.
It's always protocol improvements and 'it's coming in the next version's or 'msc #xxxx just got approved' with Matrix.
It's always someone saying 'oh this next version fixed all that' and then someone says 'well what about mobile' or 'what about desktop's and then someone says 'actually it doesn't fix it there.'
I'd love matrix to be the solution to my communication problems but it just isn't.
It is a solution for plenty of people and I am one of them. Your standards must simply prioritize UX over federation and E2EE.
While that would perhaps be the best solution in the long run, wouldn't you agree that gains in userbase necessary for growth (or at least sustainability) are predicated upon how good the UX is _currently_ ?
My minimum requirements for personal online communication outside of public web-accessible forums like this one, are open protocol, open source implementations, optional E2EE, independent hosting, client choice, and access to channels on other independently hosted servers. These are non negotiable for building my social graph of communication with family, friends, colleagues, etc.
Communication is a sacred part of the human experience and I will not allow centralized entities to control my primary means of connection to my friends and family.
My options for digital comms are then are limited to email, IRC, XMPP, or Matrix.
Matrix has leaps and bounds the best UX and functionality by this criteria and is what I use for the overwhelming majority of my communications.
Anyone that is exclusively willing to communicate over corpotech disrespects my values for freedom and privacy, and is by extension opting out of being friends with me unless we see each other in person regularly.
9/10 times the people that respect me and want to be friends with me also respect my ethical conviction and create matrix accounts to talk to me if they do not already have one.
Taking back control of the internet will require conviction and I try to lead by example in my social circles. I personally could not give less of a shit if Matrix has feature parity with xyz corpotech as they are not solving the same problem. I also use IRC heavily to talk to many of the best engineers in the world and that is a low UX bar to beat.
That said, as corpotech walled gardens keep screwing their users, more and more hold-outs will come over and new features and improvements will reduce that friction over time.
For now though very few individuals understand the vital importance of digital sovereignty for a citizen controlled society, but governments absolutely get it and do not want people like Zuck controlling their comms, so it is not surprising governments are first in line willing to pay for help switching to Matrix. The people will follow in time.
If you give up on E2EE (which isn't useful on smartphones anyway since the users have so little control over the OS and app distribution) email works, nearly everyone has that. If you use eg jmp.chat you can use email, other people can talk to you over SMS, and you can just pretend all this retarded crap doesn't exist.
In the decade prior to me abandoning cell phones entirely I used E2EE email frequently on Android via OpenKeychain and K-9Mail with a Yubikey.
I did not want to be locked into Google or Apple ecosystems and the ship on a truly FOSS Android device has long sailed, so I ported my number to a VoIP provider and only use PCs now.
To your point -any- E2EE on proprietary platforms like iOS or Android cannot be trusted for high risk comms, so at my infosec job we exclusively use Matrix from QubesOS workstations.
But yes email is normally the go-to fallback except with Gen Z who almost universally refuse to use it having grown up exclusively using corpotech.
Element is just one UX.
Yes, however it is also the most feature-complete UX.
> Loading it now takes ~10 minutes.
What?! How is this possible? How come users tolerate it at all?
Probably because it's hyperbole. I've been using element web for a long time and have not seen those kinds of issues. Not to say that it is perfect, there are definitely bugs.
I don't think that is normal, at least I've never had any client take that long to load, and nobody I communicate with on matrix has ever mentioned that as being an issue either.
I am a power user and have never experienced this. Their system must be disk bound or ram bound or something.
Granted I have 0 systems I use with less than 64gb of memory. Ram is cheap.
it may have to do with many of us on HN not getting the target audience for Matrix. It works great for a ton of people. Their usage stats speaks for itself.
But there are reasons it isn't competing with discord, slack or teams. I would like to say a lot of that has to do with matrix.org not having a serious/good commercial play, but I think it's a lot more nuanced than that.
Matrix is sort of like Mastodon and Lemmy in its target audience and usage, and there is nothing wrong with that. But I think a lot of us wanted something like Bluesky but for chat apps.
Marketing and UI are very important. something like Signal can get away with being terrible at it because they were able to get publicity and marketing from snowden, politicians,etc... I even think Matrix is a better OMEMO/E2EE communication client than Signal. But having a good product isn't enough, the user experience needs to be competitive for the general public to join and things like branding and publicity are especially important for Matrix because a good product other people aren't using isn't usable for communication purposes.
Don't get me wrong, I know the matrix team is well aware of this and they try their best, but it seems for now at least they know their target audience and that audience is happy enough with it. I suspect in Europe at least they're going to do really well. Whatsapp and Viber are very popular east of the Atlantic. Matrix should focus on disrupting those. Having something like whatsapp numbers instead of full on user id's (or translating them) for example would help compete there.
Matrix is carving out a nice but they're developing it like it should be competing with the bigger/dominant players. I interact with very technical people that are into opensource, development, security, etc... and every single time, I am the first person they hear about Matrix from.
[dead]
Same. Some friends and I use Matrix for keeping in touch, and I've been quite happy with it. I find that it just works and gets out of our way.
When compare to Zulip , Matrix usability is nothing close to that.
Zulip lacks end to end encryption and decentralization so they are not remotely comparable.
If you're doing consumer chat with friends and family, I'd recommend Signal over Matrix or Zulip.
For a community: A lot of communities want anyone in the public to be able to join their spaces and read their channels. For that use case, E2EE makes the chat system slower and less usable, with limited security benefits over using web standard encryption.
What E2EE may protect you from is a malicious server operator reading the organization's messages. If the server operator is a leader in the organization already, that person may already be directly a recipient of all the interesting messages anyway. The practical benefit I see for E2EE in Zulip is mainly for Zulip Cloud or other settings where a third party is hosting the Zulip server for you.
As for decentralization, a self-hosted Zulip server only talks to external infrastructure for sending notifications (Emails, mobile push) and to implement user-controlled features (E.g., outgoing webhooks). The Zulip API is fully documented, easy to understand and implement, and has community-developed clients.
Maybe you're thinking of federation? Matrix has fancier mirroring functionality, which can be important if your use case requires sharing dozens of channels with dozens of other servers. But Zulip is supported by Matterbridge and has various nicer mirroring integrations for sharing a channel with another server on various protocols.
But I don't know of many use cases where the usability of the core chat system isn't far more important than the usability of federation features.
Signal is a non starter. Never had an account and barring major architecture changes, I never will. Weakly secured centralized control of metadata with no option to self host your way out of it, and a requirement of a phone number which makes it a non starter for friends in countries that have good reason to be anonymous.
Zulip is at least self hostable but all private conversations in plain text on the server and lock-in to only being able to access chats on the one server are also both non starters. It is not a matter of trusting the admin, it is trusting that the Linux server was deployed with no exploitable flaws, and the admin never gets a court order. Too much trust for me.
Zulip is maybe a nicer UX alternative to IRC, but it is not comparable to Matrix.
Every new release or "This week in Matrix" post I check to see if Discord style detailed permissions and voice channels get added and every time I get disappointed. I fear it'll never be added at this point due to the funding issues. I hyped it up to all of my friends who stick to Discord that "One day" it'll compete with Discord and we, and millions of others can all finally be happy. I hope that day will come, but my hope is fading.
What would you say the delta is between Element's current video-rooms and Discord-style voice-rooms (if you go and mute video for everyone), ooi? The only reason Element hasn't implemented precisely the same UI as Discord is because it's not (currently) trying to be a Discord competitor, but more a "run your own encrypted Teams alternative", given that's what Element customers are asking for right now, and we're having to follow the money to try to get sustainable. However, what we're trying to do is to ensure that Discordish features still work, despite having to focus more on Teamsish features.
In terms of permissions: I'm a bit surprised that folks feel limited by Matrix's freeform hierarchy of permissions. Every user can have a 'power level' from 0 to 100, and you can then customise the threshold required for literally permission (e.g. you need power level 54 or higher to kick users, or whatever). The only difference with Discord is that Discord lets you pick entirely arbitrary combinations of permissions (e.g. have one user able to kick but not ban, but another user able to ban but not kick, or whatever). How useful really is this in real life usage though?
I'm trying to work out whether the problem is if Element's UI for configuring permissions is too basic, or whether folks really do need a full RBAC permission matrix, and if so, for what use case?
The power level model of permissions feels to me a bit overly simplified. It’s so easy to imagine scenarios where you need exceptions to the rule of permissions existing on a single axis that it seems very limiting from the outset.
The idea of ever increasing and overlapping scopes I don’t think maps well to most people’s mental model of who should be allowed to do what. People mostly want to define an arbitrary role; admin, user, team leader, whatever, and just pick what that role is allowed to do in isolation. It’s marginally more work to setup initially picking all of the permissions again, but it removes all of the overhead of having to monitor what permissions are being adopted from lower scopes on the power level axis.
I also think the power level system makes it much harder to “refactor” permissions for specific roles without affecting permissions for everyone “above and below”
In my experience with running Discord servers you setup a couple of hierarchical roles (admin, moderator, user etc) when you first setup the server and never again.
However I'm constantly adding new roles which are really just groups of users. I would say 90% of all the Discord roles I've ever created have no permissions associated with them at all and just exist to ping a group of users (or act as a tag for bots).
Maybe that's served by a different feature in Matrix for user groups. If so, that's still not quite as useful, because sometimes later on you decide the group needs a permission (e.g. a casual gaming group has grown enough to justify having it's own channel).
Right - this matches my hunch; that folks want to define groups of users (which you can already in Matrix in 'spaces', but the UX in most clients is awful) - and what they really want is group-based permissions (which isn't part of the protocol, and instead gets layered on at the application layer today.
So the problem here isn't that folks want contradictory access levels (e.g. Admins can kick people but can't set topic, but Mods can kick people but can't set topic) but the ability to set them via group?
the discord style permissions are simply easier to understand. it's classic role based. you define the roles, and assign the roles to users. matrix permissions forces a hierarchy that is awkward and more difficult to apply because i have to force permissions into a hierarchy. on discord i don't have to think about the hierarchy.
this comment was proofread by the department of redundancy department.
Real life usage is messy.
Idc about permissions, but the usability difference is astronomical.
I'm running matrix with jitsi for voice. No one is gonna leave discord for it though....not yet in my circles at least.
I know of nobody who even knows of Matrix, if I haven't told them beforehand. Discord is so much better than all alternatives, that I just don't see why anyone would leave it.
if people actually cared about freedom/privacy, Discord wouldn't be a thing, right?
and even harder to leave Discord now when a lot of users invested in Nitro fancy emoticons and profile enchantments
Even without that, its just a much slicker and more useable system.
I really want to love matrix but at least last time I tried it, the app was very noticeably more clunky and featureless.
I care for privacy. But there has to be a compromise between privacy and socializing otherwise we would all use letters with encrypted text, no?
Not really, because the security of letters is guaranteed by the state. The security of Discord is guaranteed by some private citizens based in the US. At least on paper the state exists for the benefit of the people. Discord exists for the benefit of investors who primarily seem to operate out of China and the US - foreign countries to me.
> At least on paper
But how is this relevant to a discussion of reality?
There's cinny, which is a pretty polished Matrix client that is very, uh, inspired by Discord in its look, that might soon add voice rooms: https://github.com/cinnyapp/cinny/pull/2335
I played around with this implementation and it's looking pretty good. Not there yet, obviously, but we're in the ballpark I'd say. Obviously, there's lots more to Discord than just voice rooms and a similar-enough UI. But we're slowly getting there.
Smells like baby duck syndrome. You're used to what you're used to, and you'll never get used to anything else if you don't switch.
I do see what people are talking about in reference to the voice channels though, even though I can't stand them.
Why don't we all speak Esperanto? Inertia.
I think hierarchical permission systems are awkward. Role based is easy to understand and setup, even if more complex technically.
We don't speak Esperanto because constructed languages work against human nature.
Why don't we all speak Esperanto? Inertia.
Well, also because Ido is the superior language. But also inertia, yes.
It baffles me that when you install the Element App (which uses matrix.org by default), you can not easily find any of your friends, because you cant “connect” your phone number…
This makes the App a no-go for everyone and their grandmother. The registration and setup process was so cumbersome, even people with some tech knowledge in my friend circle had trouble getting it to work.
Anyway, it seems so user hostile, why not just make connecting a phone number optional? That would attract many more people?
You can add your phone number.. But I don't know if it can actually be used to find you, even though it's the stated purpose :). You can find it from Settings/Security and Privacy.
Most probably don't add it anyway because it's far from mandatory (I haven't created an account for some time, but I assume it's not part of the flow), so it probably wouldn't work out great in practice.
I don't use that functionality, but I'm pretty sure it exists:
https://spec.matrix.org/latest/identity-service-api/
https://github.com/matrix-org/sydent
Yea that's correct, it seems to exist; However apparently the default server, matrix.org , does not support it...
(which everyone uses who follows the default App setup flow.)
We disabled it on matrix.org because it was being used for 2FA SMS fraud, costing us $$$K, and we didn't want to burn time building an anti-fraud system. Getting access to everyone's phonebooks is also a privacy risk (even if you do fancy stuff with SGX like Signal does).
Meanwhile, government deployments typically have LDAP or similar to discover users - and so it hasn't come up as a big requirement for the folks generating $. It's on the radar though as one of the main blockers for mainstream uptake... but right now we're trying to keep the lights on first before focusing on accelerating mainstream uptake.
Good to hear the insight, thank you.
That makes sense, hopefully it’s something that can be resolved sometime soon. Would be great if mainstream people have another, privacy conscious, alternative to big tech…
I genuinely can not understand if this is satire or not. Attaching everything to a phone number is the worst thing that happened to messaging.
The part you apparently don’t understand, is that this is (unfortunately) currently the reality: it’s what most people use now. We can’t expect everyone and their grandmother to switch to a perfect e2e alternative overnight.
Meanwhile, i need a way to communicate with everyone, preferably as secure as possible.
But you're not attaching everything to a phone number here, only ease of discovery
> It baffles me
It baffles me that people use corporate surveillance software, and balk at the tiniest of privacy hurdles.
Can't wait until MAS is just part of synapse/dendrite, will be a lot easier to install and maintain than the extra moving parts.
I kinda like the extra moving parts, it makes it easier to scale away from the slow Python parts.
I like the idea of matrix and element, but the execution is just so lackluster. Even Signal added a lot of quality of life improvements, and WhatsApp is consistently getting better. I don't like the idea of using a messenger owned by Meta, but honestly, messengers absolutely need an excellent UX and UI, QOL features, etc. and Element is just far behind in this regard.
$50 says that this is yet another instance of the failure-mode explained in https://news.ycombinator.com/item?id=44392479.
ElemntX does not support all features that Element does, so if I'm using a space to group rooms, then I can't use it.
None of these things are why I and everyone I know doesn’t use Matrix.
Why exactly don't people use matrix that much? It strikes me as a reasonably good open, secure comms protocol.
The official client is clunky and being electron on the desktop doesn't make it better. Messengers live and die on UX. Since it's an open protocol alternative clients exist of course, but are often not feature complete. Things are often slow, especially with large group channels with lots of messages.
If you host a server yourself - it's great that you can! - you'll try the official implementation, synapse — ...and discover that it's a resource hog. Things got a bit better with some streaming sync protocol or something like that, but last time I looked it up that was still experimental and the server is still a chonker. Again, alternative servers exist, again the problem with feature parity.
I feel like the protocol is bloated as well, but I didn't dive into it too much to have a good opinion on that.
When choosing a messenger, I go to Signal for security, to IRC for simplicity and to Telegram for UX. I never thought "Oh let's use Matrix"...
Alternative clients feel like a broken promise to me, since features seem to be optional or implemented differently. You're basically stuck with Element if you want to be reasonably sure you're seeing what other people are.
Even the official clients are a little weird. Element X, their next gen super fast client released in 2023, still won't allow me to create a thread on iOS. It will let me put a caption on a photo though, but Element won't.
"Messengers live and die on UX" - THIS
From time to time, I go and check if there's a stable non-Electron Matrix client available - Qt would be nice. Thus, I'm still on IRC. I've tried participating in some bridged Matrix channels, but the IRC bridges I've encountered were super annoying. All messages come from one user, the bridge. Very often, the same message gets repeated twice or more, for some reason. I guess Matrix has no limit on usernames, so some users have names that are more than a line long. It's all very tedious.
The QT client for Matrix is called Nheko: https://nheko-reborn.github.io/ There's a client in just about every toolkit. Just takes a cursory internet search...
Unfortunately, they still use libolm[1] for e2ee which is deprecated[2] and has known security issues[3]. The maintainers appear to not be interested in switching to the newer Rust-based library. Matrix argue that the timing channel attacks are not possible over a network, but the history of timing channel attacks argues that this very few protocols are this fortunate (most people thought timing attacks against TLS were impossible too, until someone bothered to attack them).
[1]: https://github.com/Nheko-Reborn/nheko/issues/1786 [2]: https://matrix.org/blog/2024/08/libolm-deprecation/ [3]: https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
Yeah, although Matrix is theoretically about being an open protocol supporting a range of clients and servers, in practice it winds up being heavily skewed to just Element/synapse. I think this is partly because there is still too much churn in the protocol. A decent amount of that churn is improving things, but it still makes it too hard for average-joe devs to keep up with what's hip. I don't think there's much chance of a real menu of feature-rich clients until the protocol becomes stable. Unfortunately, I don't foresee that happening soon.
AFAIK none of that churn is around functionality that actually matters that much to end users, however. Certainly nothing as important as “working clients”.
There's also a really great Gtk client called Fractal from GNOME; it uses the same matrix-rust-sdk as Element X: https://gitlab.gnome.org/World/fractal.
Meanwhile the plan for Aurora (Element X Web) is to run it in Tauri or similar to placate all the Electron-haters: https://github.com/element-hq/aurora
There is also Neochat from KDE, not fully featured like Element and E2E Encryption still experimental the last time I checked, but it is a nice alternative if you want a non-Electron client.
> synapse — ...and discover that it's a resource hog.
I thought that, too, but at the very least it probably grows with usage. On my single-user-server, synapse currently needs ~100MB of RAM and does not consume CPU at all. It's not "slim" but I wouldn't call it a resource hog either.
One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X: https://element.io/blog/we-have-lift-off-element-x-call-and-... etc. Element X kicks ass, in my (very biased) opinion: it's a super-speedy Rust core with fancy SwiftUI and Compose native UI layered on top. It radically outperforms any other encrypted messenger i've used in terms of UI perf and usability.
However, because it's a rewrite, it doesn't quite have feature parity with the old apps, which are now over 10 years old: Threads is in beta; Spaces haven't landed yet, and Widgets aren't implemented yet. Therefore, we have to keep the old app around for users/customers who depend on those.
As a result, >80% of the people who say "Matrix sucks" are actually talking about bad experiences on the old Element mobile apps - rather than better client Element X or indeed Matrix clients from other folks.
There's also a large set of people who got bitten by encryption problems, almost all of which were fixed by Sept 2024.
Finally, there's folks who got bitten by the sad history of bridging in Matrix: IRC bridging used to be relatively okay; the team then got very stretched due to lack of funding; we tried to land a major PR to improve its architecture; the PR introduced bugs; Libera got very upset; we tried to fix things but failed to do fast enough. As a result, bridging to Libera in particular is awful these days, using adhoc bridges which funnel all traffic through a single user, with no ability to join arbitrary IRC channels on demand or use Matrix as a bouncer.
These days, the priority at Element is providing a self-hosted, decentralised WhatsApp and Teams replacement for governments... and once we get sustainable doing that, we'll be able to spend time building community features once again.
> One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X: https://element.io/blog/we-have-lift-off-element-x-call-and-... etc.
Okay, but they do that because they used those apps, and they did that because you released those apps and said the same thing you're saying now ("use our app, it's really cool"). Surely you can understand why someone who dealt with that is going to be suspicious of "this time for sure".
> However, because it's a rewrite, it doesn't quite have feature parity with the old apps, which are now over 10 years old
So people can either judge based on "legacy" apps that do more, or the shiny new app that does less. Again, surely you can understand why people might be disappointed with both of those.
There isn't any way to avoid being judged on your whole history.
I recently tried Element X. I will say the onboarding was better, although that comes with the caveat that I'm not sure how that would go if I didn't have another device at hand to verify with. And UTD errors have definitely decreased (across all clients). Apart from that, the UX is okay, but I don't see it as radically better than the old Element.
There has been a good deal of improvement in Matrix, which I appreciate and kudos are due to you and the team for that. But I think it's a bit of a stretch to make claims like Element X being "radically better" than any competitor. And, importantly, making grandiose promises like that increases the risk of losing trust if people's experience isn't absolutely stellar.
I think this is a pretty fair summary. I've been using matrix since before the patreon was started and it's gotten a whole lot better for sure, but there is still no single client that does everything. Element X is right out since it doesn't support spaces yet. SchildiChat next comes close for me, but it can't edit room topics, pinned messages can get a bit weird once you start editing them, and I have a few invites to some pretty nasty looking spam dms that I can't delete, so there are still some rough edges.
On the desktop side, if there were a client as good as SchildiChat maybe that would work, but last time I tried one of the Element desktop clients I wasn't even able to log in (it either crashed or hung, can't remember), and most of the time I'm fine with Fractal anyway. Fractal is actually a very nice client for what it does, it just has a limited feature set: missing spaces, copy/paste doesn't quite work like you'd expect, no search (I'm not sure there are any clients with fully functioning search for encrypted rooms), and my memory is that heic image previews weren't supported. I can fall back to nheko for some of the other things when needed.
As far as I know, there aren't any clients that support the new element call unless you enable the labs feature in element x.
All that said, I can't overstate how much I appreciate all the work the matrix devs do, and it is still fine for my daily use. Even if I sometimes disagree with Arathorn's conclusions about how ready matrix is, I have to appreciate the optimism and I imagine it is part of why he's been able to continue through all the negativity :) and it's not entirely wrong to say that matrix beats the competition - I'd say it easily beats teams and imessage (teams does not deserve to be mentioned in the same sentence as anything else), and it is mostly comparable with messenger and whatsapp. Slack probably has it slightly beat, and discord is leagues ahead of everything else.
I think an early major mistake was that Matrix spent all this time and energy designing a general synchronization protocol, but not doing it in terms of native encryption and cryptographic identities. This was post-Snowden, and it was glaring at the time.
Bolting on encryption after the fact then sucked so much energy out of the ecosystem for clients. This one doesn't implement encryption, that one does but it has bugs/warts/etc, this other one does if you pull this year-old experimental branch and build it yourself. The web (-technologies) client became the de facto one because it "worked", despite being bloated and laggy - reliable tools don't even have the code to show these spinning delay circles that have become synonymous with the web ecosystem.
I don't want to be entirely negative because I do see it as the least-worst messaging option available. I use it for communicating with a bunch of friends and things do seem to be getting better, and I look forward to when I can actually switch to its window to type a message and not wait around for redraw / garbage collection / reloading messages from server /etc. That might be on me for not having surveyed native clients recently or tried Element X on my desktop, but that's exactly the negative momentum I'm lamenting above.
That's true, but in another sense I think it's just that trying to "do it all" encryption-wise is significantly harder than some people realize. Having encryption that's really "safe" raises barriers to casual use that most casual users aren't really willing to accept.
Like suppose I use Matrix only on my phone, so I just have the one device. Then I lose my phone and have to get a new one. How do I regain access to my account, including all of my old messages? Or suppose I (still using Matrix only on my phone) decide I need to log out because I want to let someone else (a friend, my kid) use my phone for a while and don't want them snooping in my messages. How do I retain access to all the messages I receive while logged out?
I'm not saying these are problems with Matrix; they would be problems with any service that attempts to cover the same bases (in particular, e2ee with forward secrecy and multiple independent devices). The average user's conception of a messaging service is "I can log in with my password and then have total access to all of my messages, past, present and future." There are too many ways to break that assumption if you try to have perfect forward secrecy and all these other desiderata that encryption wonks care about but normal people don't. I think this is one reason there's still a big gap between comments on HN saying "matrix still works fine for me" and the tales of "I tried to get my grandma to use this and it was a disaster". I don't think it makes sense to try to roll Matrix out for general use, or say it's "the best messaging app" until it can smoothly handle all of those use cases.
I'd say that all of those usability problems are made worse by bolting on encryption after the fact. It makes it so there are now two layers of authentication/identity, rather than a single one. Whereas with built in encryption, you can always punt on solving the problems you list and make implementations that are less secure. For example, just store the keys on the server, accessed by the password. That's obviously less secure, but not less secure than no encryption.
Yeah, I don't disagree. Just saying that even if they had put encryption in at the outset, there are still tough issues to solve in terms of integrating that with user expectations.
> One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X
Which is mobile-only. Element's UX on desktop is still a joke.
> These days, the priority at Element is providing a self-hosted, decentralised WhatsApp and Teams replacement for governments... and once we get sustainable doing that, we'll be able to spend time building community features once again.
In other words, you don't have the community's best interests in mind, but we should rest safe because you'll have their best interests in mind at some point in the future, maybe.
Not very reassuring.
> Which is mobile-only. Element's UX on desktop is still a joke.
Actually, we span up Element X on web a few weeks ago and are currently figuring out how to transplant EW's view layer (which is fine) onto matrix-rust-sdk (which is more than fine): https://matrix.org/blog/2025/06/05/this-week-in-matrix-2025-... etc.
> In other words, you don't have the community's best interests in mind, but we should rest safe because you'll have their best interests in mind at some point in the future, maybe.
I'd argue that by having spent >10 years building out Matrix and Element as open source, we've demonstrated that we have the FOSS community very much in mind. But we'll only be able to continue doing that as our day jobs if we can pay our salaries, and the way to do that appears to be to sell enterprise Matrix distributions to Governments. Once we get financially sustainable doing that, we'll be able to focus more on the community again.
> Not very reassuring.
Au contraire, mon capitaine; I find it very reassuring that Element might finally be approaching a position to keep working on improving Matrix indefinitely :D
Well, it looks like my overly cynical response wasn't warranted. Best of luck in your future endeavours and I hope you manage to get the money you need without locking too many features behind enterprise Matrix.
EDIT: I do still find issue with the claim that Element X is the solution to every UX problem though. Sure, you've begun experimenting with a web version of it, but it's still in the very early stages - it's not exactly production-ready.
You're probably right that it's the UX of the OG Element that was the original problem people got hung up on but Element X isn't actually a relevant answer until it's usable, regardless of how much better it sounds like it will be on paper. A secondary problem people got hung up on was the endless parade of "you're just using the wrong client, try ${this}" and then finding it was missing half the things that they were told Matrix can do.
I'm still optimistic about Matrix but I am a bit worried that it has lost a lot of steam because of this UX history.
It's been years of seeing Matrix posts being made on hn here (and founder - that is you - enthusiastically replying to comments; which is actually nice that you still care) and even that is long after I finally gave up on it realising it is (and now it seems was never even planned to be) a communication tool for the "masses" or end users - you know - you, I and our friends and family... kind of.
Reason? It is still "work" to even try to start using Matrix and yes I tried the kicks-ass-new-swift-client and it seems to be just another dull almost useless iOS messaging app which was done as a proof of concept of an open source project with very high values and goals and completely missing the point of usability and what people need and where smartphone messaging is today.
Also by the way - how many has it been? Matrix -> Riot -> Element.. is it changing again now?
> 80% of the people who say "Matrix sucks" are actually talking about bad experiences on the old Element mobile apps
Maybe 100% of times you are missing the point why people think that way by just assuming this?
> self-hosted, decentralised WhatsApp and Teams replacement for governments
Well, I do hope you realise that "Govt as the entity" per se that would not use these apps - but "the people" (which actually kinda comes back to you, I, and our friends) in those governments will use those apps and services.
Anyway, good luck.
> Maybe 100% of times you are missing the point why people think that way by just assuming this?
"Am I so out of touch? No, it's the users who are wrong"
> I finally gave up on it realising it is (and now it seems was never even planned to be) a communication tool for the "masses" or end users - you know - you, I and our friends and family... kind of.
Matrix has always intended to provide communication for the masses. You can see this from day 1 here: https://matrix.org/blog/2014/09/03/hello-world. You can see it in the Matrix Foundation's manifesto & mission here: https://matrix.org/foundation/about. You can see this in my "Road to mainstream Matrix" FOSDEM mainstage talk this year: https://fosdem.org/2025/schedule/event/fosdem-2025-6274-the-....
However, we have to fund our work on this, and the Matrix team at Element do so right now by building digitally-sovereign comms apps for governments. The reason is that generating funding out of mainstream consumer messaging apps is very hard when you are competing against 'free' (WhatsApp, iMessage, Signal) and when you aren't in the business of monetising data/metadata or selling ads or AI. Signal has problems with funding even at the scale they're operating, for instance. So, instead, the strategy has been to focus on getting $ from governments which in turn can then keep the lights on for everyone else. And I personally am continuing to jump through every hoop I can to try to get Matrix into mainstream use.
Perhaps an analogy is Linux On The Desktop. I'm sure when Linus created Linux he was hoping to create a generic kernel which could be used all over the place for everyone. As it happens, it first got traction serverside, and so lots of effort and focus went into refining that; meanwhile clientside Linux lagged a bit, especially as reconciling great UX with open source is... challenging. As a result, loads of people on /. or whatever complained bitterly about clientside Linux not being mainstream. As time went, on though, organisations subsequently focused on building great Linux-based clientside products like Android, Ubuntu, etc, and you could argue that Linux did eventually go mainstream on mobile, and may yet go mainstream on desktop. But it took ~20+ years to do so, due to the twisty path it took to get to critical mass.
> yes I tried the kicks-ass-new-swift-client and it seems to be just another dull almost useless iOS messaging app which was done as a proof of concept of an open source project with very high values and goals and completely missing the point of usability and what people need and where smartphone messaging is today.
You'll have to explain to me how EX misses "what people need and where smartphone messaging is today", as the feedback here feels a little unsubstantiated...
> Also by the way - how many has it been? Matrix -> Riot -> Element.. is it changing again now?
Matrix is still Matrix, and always has been. Riot got renamed to Element in 2020 and there are no plans whatsoever to change that. We should print t-shirts for folks who bring up the rebrand to hit us with 5 years later. Meanwhile, here's a shout out to Riot Games' lawyers for forcing us to rebrand in the first place...
> Maybe 100% of times you are missing the point why people think that way by just assuming this?
Maybe, but this is the first time i've heard someone complain about Element X (other than being impatient for threads/spaces); i have a high sample size of people confirming that it's a big improvement.
> Well, I do hope you realise that "Govt as the entity" per se that would not use these apps - but "the people" (which actually kinda comes back to you, I, and our friends) in those governments will use those apps and services.
Not entirely sure how to parse this, but if your point is that our competition for Govt end-users is Signal & WhatsApp, then totally agreed. Which is why we've focused on matching/outcompeting them with Element X.
> Anyway, good luck.
thanks! :D
It's a little frustrating that Element X is constantly pitched as the answer when it isn't yet supported by Element's own EMS One hosted service.
Element One should support MAS + EX in the next 2-3 weeks.
Mozilla's EMS hosting got migrated over yesterday (at last)
60% of the rest of EMS-hosted servers are also migrated already.
Sorry it didn't happen earlier, but all our focus has been on getting on-premise deployments for people like NATO & the UN working excellently, and the SaaS deployments have been lagging.
Appreciate the response, that's great to hear.
> One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X
Yeah, wake me up when X supports all the features the original app has. Until it's usable, there is no point.
which features are you actually missing? the only gap now is threads (in beta), spaces (in final design) and widgets (which were very very rarely used). the whole "i can't use X until it has precisely the same featureset as Y" feels a bit spurious, especially as you can run each app side by side and revert to the old one if you really need a given feature.
Spaces.
I think this happens a lot. At least a lot more than people think. Take Firefox vs Chrom{e,ium} (yes, that includes Brave). The differences are really minor and 99% of people wouldn't notice the difference. But boy do people have strong opinions. I'll make one argument for Firefox and I'm not sure other ones matter nearly as much: there needs to be competition in the browser space, and different colors of Chrome don't count. Having one backbone is good for no one. Yes, even Brave gives Google too much power over the entire internet. Hopefully Ladybird will become competitive, but in the mean time some of you should stop being dumb and use Firefox. Because frankly, it doesn't affect your browsing experience. You're just biased in your evaluation because things are "different".
The reason I brought that up is because there are so many parallels with what you're talking about with Matrix. Even down to the rewrite in rust and people acting like software hasn't improved in a decade. But the competition space is very important in chat platforms, just like browsers. You can support Signal and Matrix at the same time. They solve different problems. You can also use WhatsApp, Telegram, and/or iMessage or whatever. Competition is necessary in this space. We don't want monopolies. Especially if you're a firm believer in distributed systems! Distributed systems can become highly centralized. Just check your email account. I'll bet you have a Gmail account... I'll bet you also have an Outlook account. Or look at your phone!
Totally unrelated fun fact: people consider Coke and Pepsi an oligopoly, yet *combined* they only have a 70% market share. (This is definitely unrelated and definitely doesn't have any connection to our discussion...)
[dead]
Because the product design people there seem to focus on an enterprise use case where the client is pushed out with a custom config to devices, instead of catering to end consumer usages.
I assume this is caused by the company that does the Matrix development getting its revenue from such customers.
I get the impression it is more designed to be a Slack replacement than a Signal or WhatsApp replacement, which is a shame.
No one is going to use Matrix that doesn't have privacy-focused contact forcing them to because the privacy benefit of the slight inconvenience is something almost nobody cares about. Things that are non-issues to someone who read the online Matrix documentation becomes a mountain to a middle aged mom who taps through errors without reading them and is used to things "just working" in the way Apple products just work, not the way Linux just works.
If you log into multiple devices, you have to go through a verification process to verify the new device. You may need to backup and restore your encryption keys manually or all your messages will be "Unable to decrypt message". Keeping multiple clients open simultaneously is supposed to have one client request the keys from the other client, but this either takes a while or doesn't always work. I have a contact with an unverified device (so all his messages show up with a warning) who refuses to fix it because all the other messengers just work by logging in. This is on top of people being upset that you're adding one more app to their menagerie of texts, Facebook, Whatsapp, Telegram, Discord, etc.
I use Matrix with my close contacts but I can't imagine anyone ever saying "Damn, I'm going to use this instead of Discord now!"
Because it entails getting people away from WhatsApp/Telegram/etc. - I speak from experience.
That's why bridges exist.
It doesn't look consumer friendly at all to set up
I tried it a few years ago and it was not friendly at all too. I'm sure it hasn't changed and everything felt confusing and complicated.
I don't remember the details but I have this feeling that I won't use it again. It seemed like the server could do everything (good) but they didn't found their niche (bad and impossible for such a generic framework).
Super happy to see matrix chug along. I’ve been self hosting dendrite home server for a long time but it doesn’t have sliding sync support, so can’t use the new modernized client. Anyone using conduit for self hosting and do you know if it works with the new client?
Maybe I'm confusing something, but I thought dendrite development had stopped due to budget concerns.
I see now that there were actually recent releases on github.
Does anyone know if homeservers still control room membership + user key lists or if it's somehow properly signed now?
I couldn't find anything on https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en...
Room membership is still determined by the server rather than the client - but we now warn the user and freeze the room if devices which are not signed by their owner are present in the room.
Constraining the user membership to be controlled by the client is Hard in a fully decentralised world, but we're working on it: one option is MSC4256 (which pushes the whole problem to MLS); another option is to run Matrix's state resolution algorithm on the client (making the client implementation even more complex) to ensure that the client agrees with the server on the correct user membership.
Thanks a lot for chiming in! That's nice to hear it's better and improving.
View from 1000 feet: maybe a way to lock a room's users would be interesting? So that new users in, say, a DM room do not get decryption keys for messages from the client. Something like a weaker form of "only send messages to verified users", where you could have a DM room with (at most) 2 people.
Or, instead, maybe an option to disable forwarding session keys older than the user's room join event, to keep forward secrecy so that a new user does not get to read old messages (or does this already happen every 100 messages?).
> View from 1000 feet: maybe a way to lock a room's users would be interesting?
That's a really interesting idea - having immutable memberships could be a good band-aid. The problem is that right now the fact that room membership is typically mutable can be valuable: you add assistants into DMs (human or virtual); you can bridge the DM to other platforms; you can add (benign) audit bots for compliance purposes; you can migrate between Matrix IDs by inviting in your new ID and kicking out the old one; etc.
Of course, this same flexibility comes with a risk, and I see the point that it might be better to 'seal' membership if you know this is flexibility you don't want. We'll have a think.
> Or, instead, maybe an option to disable forwarding session keys older than the user's room join event, to keep forward secrecy so that a new user does not get to read old messages (or does this already happen every 100 messages?).
Currently we never forward session keys, so new users don't get to read old messages whatever. This obviously causes its own problems, especially for Slack/Teams style use cases where new joiners expect to be able to read conversation history. Work is ongoing right now to finally fix this (https://github.com/element-hq/element-meta/issues/39), but we are very mindful of the risk of not sharing existing history to the wrong users (or devices), which is one of the reasons it's taken so long to land.
The 100-message thing is separate: it's the maximum number of times a session-key ratchet can be advanced before it gets replaced. In other words, if you steal a session key, you can only use it to decrypt a maximum of the 100 subsequent messages sent by that device.
Thanks again for taking the time running me through these things.
> we are very mindful of the risk of not sharing existing history to the wrong users (or devices), which is one of the reasons it's taken so long to land.
It's great to hear these things are kept in mind going forward, should hopefully mean it's less hard to make protocol changes when they are needed.
I use beeper to connect with WhatsApp. Saves me from 4 device WhatsApp web limit that is imposed.
That said, I am personally not so keen on using matrix. Remember India government banned matrix and other apps for "facilitating terrorist communications".
Ah... the joys of democracy.
[dead]
I'm happy Matrix exists and I've been a user in deployments at more than one university (where - fortunately - Teams, Slack and all the other externally hosted stuff isn't even an option).
custom emojis still didn't make the cut?
The protocol must support it somehow already, as some bridges can send custom emojis from other platforms
https://github.com/matrix-org/matrix-spec-proposals/pull/254... is the de-facto way that custom emoji are done today, but as you can see from the labyrinthine Matrix Spec Change, it still needs some work to get stabilised and formally merged into the spec. Meanwhile, folks are always welcome to use experimental MSCs in the wild.
I used it for a month. It's full of cartoon kiddie porn and porn in general.
Find better friends?
[dead]