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
Competition can be good, for example, if we had new clients for existing federated IM protocols.
But Matrix brings fragmentation more than anything else: a brand new protocol that's slowly re-inventing what we already had. Matrix clients don't really compete with existing ones for open (or closed) protocols, they exist in an entirely new sphere.
I don't think this is a net positive; the general ecosystem has finite manpower, the more we fragment it, the less each protocol gets. In the end, we have a new federated IM protocol which doesn't bring many new things to the table, but we still don't have any reliably easy-to-use clients.
> 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.
Zulip's topic focus chatting get the work done and kept information organized, very easy to search and assign tasks.
That's huge upgrade over IRC since information is organized at the protocol level.
i agree matrix is desirable to replace slack only in case of where E2E is necessary.
For companies, inspection of chat logs may needed by top management in case of dramas.
