[Arathorn]

> - 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.

[nadir_ishiguro]

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?

[justaj]

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.

[Arathorn]

> 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.