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
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.
We certainly didn't have decentralized rooms before
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.
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.
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.
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.
What?! How is this possible? How come users tolerate it at all?
Granted I have 0 systems I use with less than 64gb of memory. Ram is cheap.
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.
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?
> 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.
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.
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.
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.
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.
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.