And what if you let a human expert fact-check the output of an LLM? Provided you're transparent about the output (and its preceding prompt(s)) ?
Because I'd much rather ask an LLM about a topic I don't know much about and let a human expert verify its contents than waste the time of a human expert in explaining the concept to me.
Once it's verified, I add it to my own documentation library so that I can refer to it later on.
> 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.
Not entirely though: if you are attacking coworkers just for being wrong that is asshole. If you are holding the top of the pyramid accountable for their illegal immoral wrong "ideas" then that is a level of correct that the world needs way more of
