New Element Web and Desktop apps
element.io
element.io
I don't really think Element or Matrix gives a damn, either. Well, I get that there's no money to extract from the community, or at least not much, but still, all of this leaves a bad taste in my mouth, and makes me think that we all should've probably just stuck with XMPP. But then again, I never self-hosted XMPP, so maybe it is just as dreadful.
I agree that it sucks that Element doesn't have the $ to support work on both Dendrite and Synapse/Synapse Pro, and unfortunately there's not been enough community momentum on Dendrite to add features like sliding sync.
It's not a matter of "there's no money to extract from community users" - instead it's simply "until we get to breakeven, we can't afford to work on Dendrite".
While I can't promise that Element will ever return to working on Dendrite once we /do/ get to breakeven (maintaining two codebases of the same product is just self-destructive, especially now other 3rd party servers exist) - at the least we can provide migration tools. It's worth noting that right now you can't even migrate between domains from synapse to synapse though, let alone dendrite to synapse.
I'm a programmer, so one of my first instincts when I noticed Dendrite was struggling was to take a look and see if I could maybe make sense of things. But, a few things did strike me immediately:
- The Dendrite code is split across a few different projects. Nothing terribly wrong with this, and I'm sure there is plenty of good reason for it to be that way (i.e. there was clearly intent to have an agnostic Go library for writing Matrix servers) but it's definitely not great for development. I think it should just be part of a mono repo, personally.
- The Dendrite code seems like it was practically abandoned a while ago. It's not terrible or anything, but it does feel like taking Dendrite and modernizing it would be a substantial effort. This is a bit frustrating because honestly, when I first ran Dendrite, I didn't realize it was already kind of abandoned. A lot of trouble could have been saved if that were made clear earlier :\
- Even if I wanted to work on Dendrite, I'd have to sign the CLA. I'm not super keen on that. Open source licenses give me rights as a community contributor, and a CLA takes all of them away. I get that community contributions have always been and will likely always be minuscule compared to the amount put in by full-time employees, but full-time employees get a paycheck and dental, I don't, I would like to retain some of my rights. It'd be one thing if the CLA had a legally-binding guarantee that the code must stay open source, but I don't believe that it does. And while I have no problem with the AGPLv3 licensing in general, I have my suspicions about the intent behind the sudden quiet license change on Dendrite; Dendrite isn't even maintained, it feels kinda silly to do this now.
All of this together makes me, again, question if communities like the open source community should really be standardizing on Matrix. Of course, in part due to all of this mess, the open source community actually isn't necessarily standardizing on Matrix; a lot of big projects have Matrix in addition to other official discussion channels. As sad as it is, I suspect that right now the vast majority of open source community communication happens on Discord.
Don't get me wrong, Element and Matrix do a lot of interesting things, but this has been a very strange experience for me for sure. Basic text chat features have worked effortlessly and near-flawlessly for me with open source community options, like IRC servers, XMPP, etc. for a long time, but with Matrix (and particularly Dendrite) I've had so many issues with just that, even when not considering E2EE. Sometimes it definitely feels like a step backwards in some regards.
As a heavy Element user for work, I have long hated this in Element X iOS and now I have the pleasure of hating it in Element web. Everyone at my job is mad about the remove of these "duplicative" metaspaces. Here's a GitHub issue about it: https://github.com/element-hq/element-web/issues/30849
I am a UI dev and I try to give people the benefit of the doubt, but after using Element for nearly 5 years, it really does feel like the user experience only gets worse over time. It is really sort of amazing.
What do you mean by 'constantly collapses the filters'? I'm clicking the filters right now and they stick? And don't collapse? Or are you saying that they apply to a single list rather than multiple sections?
I'd love to use Element X, but Element abandoned the form of SSO my community depends on, and I don't really have an appetite to spend 12 hours of my free time standing up sliding sync, a separate auth server, migrating my users to the separate auth server, spending hours explaining to everyone that their credentials live in some other place now, and then migrating my custom server admin software to use OpenID connect. Oh well.
This has been built into synapse now for months, maybe a year. Does not require a second sliding-sync component anymore.
What about Matrix Authentication Service? That's still a separate piece of software that requires PostgreSQL (as opposed to SQLite like my Synapse instance uses) and has no clear migration path for those of us using our own SSO solution (SAML, CAS, maybe your own OIDC provider like Keycloak...), right?
I don't want to run Dex and complicate the stack further, either.
I think 12 hours to migrate is probably optimistic even with built-in sliding sync, actually...
Still its own thing which I have not deployed on my homeserver.
> as opposed to the SQLite like my Synapse instance uses
I've done this for testing but they really don't recommend it for production. It's had a history of being broken: https://github.com/element-hq/synapse/issues/18325
I wish it were easier to be a Synapse admin! It seems like all server updates are focused on scaling matrix.org and the little guys that provide network diversity are not really being considered a priority.
Meanwhile you can see me trying to improve diskspace for Synapse by ~100x here:https://www.youtube.com/watch?v=D5zAgVYBuGk&t=1851s - admittedly motivated by matrix.org, but it would improve disk storage immeasurably for everyone.
Then, https://element.io/server-suite/community is built to be a really simple FOSS distro (albeit for k8s) which provides Matrix Auth Service, Synapse, Element Web, Element Call and (in a few days) Element Admin all in one package for self-hosters.
And if you hate k8s, then there's always the trivial docker-compose thing I did for the same stack at https://github.com/element-hq/element-docker-demo.
We have very much not forgotten the self-hosters - not least because Element tries to make money by selling the enterprise distro for enterprisey self-hosters at https://element.io/server-suite/pro. The rule of thumb is that stuff which privileges the end-user goes FOSS, and the stuff which privileges the enterprise over the end-user goes Pro{prietary,fessional}.
Matrix is a product of venture capital and the growth at all cost culture, the absurd price to play (reqs to federate with the canonical matrix.org server) made it clear from the get go. If you have your users managed externally, you could probably have a shot at setting-up an XMPP server alongside Synapse, for a tenth of the hassle and resources consumption, and see for yourself if that's an acceptable plan B.
Now I still have the button to list rooms outside of any "Space" but now instead of a DM button I have "Home" which mixes both DMs and rooms outside of any "Space" so I need to click on that and then the "People" filter (which doesn't save so I can't just click it once and be done) to get rid off the rooms that I already have a dedicated button for.
You sure succeeded in removing duplication. Two buttons that did two different things caused so much duplication!
Now I will have to create a "Space" to add those "space-less" rooms so that they don't show up in Home.
Oh and on upgrade I had no button to view DMs at all as I disabled "Home" before but you didn't force re-enable it for people upgrading.
Message search on Element X Android when?
EDIT: Also the filters hide under another button when your sidebar is too small and if you expand it then it can take up even 6 lines.
EDIT: And now also noticed that favourites don't stay at the top, truly useless, thanks.
EDIT: Why is room sorting method global now… I used to have spaces with different sorting… the location of the button to change the sorting hasn't even changed so it still feels like if it was local to the space. Good UX.
EDIT: Since I ended up complaining so much, might as well say that the sidebar having the same colour as the chat panel is pretty ugly and makes the whole application blend in more when the chat should be the main focus. Also expanding the spaces is still terrible as it expands the space part of the sidebar and it is annoying to have to toggle the sidebar back, I don't want the sidebar to take 1/3 of my screen.
I didn't even know such "important" features exist, and never needed them.
> Whenever you log on from a new device, you have to cross-verify the device using either a secret key or, more comfortably, another device that has already been verified.
If you have a laptop and a smartphone, you need to verify the device once, doesn't look complicated. And most smartphones are probably backdoored anyway so you should not be using matrix there.
> Matrix was never good.
Web version of Element allows sending messages, files and calls, and they actually work. That's already better than many open-source projects including Jabber.
Although I must I admit, I see a warning that I need to "verify this session" in a web client, but no meaningful way to do it. Also web client annoys and distracts me by messages like "Chats have a new look". What's the point of showing this popup? If they have a new look, everyone will notice without any popups. Stop copying worst features of commercial software.
I'm not sure we've been quiet about it - c.f. https://element.io/blog/element-x-ignition/ :P
> it still misses crucial features like threads and spaces
fwiw, threads & spaces are in beta right now on Element X iOS and Android, aiming to launch in the coming weeks. If you are unafraid of bugs, and bearing in mind that it's very still WIP and none of the perf work has happened yet, you can enable dev mode by 7-tapping the version number in settings and enabling them on.
> Matrix was never good.
I'd be first to admit that Matrix clients like Element have had their usability challenges over the years. However, we have spent the last 2-3 years doing nothing but trying to fix this, and we believe the Element X generation finally punches its weight against the proprietary/centralised alts.
Live location share is next on the list after Thread/Spaces; "Low priority" is already an option in dev settings, and then Widgets are pretty much the last thing left.
You can see a full parity comparison between Element Classic & Element X at https://docs.google.com/spreadsheets/d/17_j_HAPZEopqDAbKKsaw... fwiw - which hopefully puts the "EX is missing crucial features" complaint more in context.
In the spreadsheet you linked I see "manually import/export E2EE keys" as missing in EX but there is way more (and IMO more significant) gaps in security-related UI than that. I believe this class of missing functionality may be a major blind spot on the EX roadmap.
"The authenticity of this message can't be guaranteed on this device"... OK, now what? In Element it's usually at least possible to understand the cause of and do something about those situations. In Element X, that notice is all you get.
Because of this it still feels like a toy beta since you basically need a second not-Element-X client running as a backup for when issues occur or you otherwise want that control or insight into your own account, sessions, and chats.
Oh, and I guess not everyone is content with Apple/Google duopoly while EX is exclusive to iOS/Android.
Hmmmmmmm. Are you running EX against an older homeserver which doesn't have matrix-authentication-service and native OIDC? On my EX on matrix.org, I have "Manage account" and "manage devices" options in Settings which takes me through to manage the current devices and sessions.
In terms of managing verification and cross-signing, the reason there's no longer explicit controls for verifying your sessions is that the model going forwards is that users must verify all their devices: in future any devices not verified by the user will be excluded from conversations. EX does this by forcing you to verify when you login (and Element Classic also does this).
In other words, the missing functionality you're talking about is deliberately removed because it was never a good idea in the first place - it was a backwards-compatibility side-effect of the way that encryption and cross-signing incrementally landed in the first place. Now, we're moving towards a model like Signal or iMessage or any other E2EE messenger where all your devices should be verified and cross-signed and trusted automatically, and so the UX reflects that.
Obviously if you have other Matrix clients or bots flying around which don't verify by default, this then becomes tricky, but it's very unclear that the right solution is to bog EX's UI down with the fragility and complexity of the old apps. If you're a poweruser who needs to juggle dangerous Matrix arcana like unverified devices, then the right solution probably is to use a poweruser app to do so. Meanwhile, we want EX's UI to be simple and just work out of the box, rather than getting tangled up with these complexities.
The problematic situations that have otherwise crept up are generally devices that all think they're independently verified but somehow get out of sync for any nuber of arcane or archaic reasons. Reset flows are another pain point.
And yeah, I think our homeserver will not adopt MAS/OIDC - requiring a separate service and client (web browser) for account managament certainly feels like a regression. I see why it makes sense for matrix.org and the customers of Element but making EX depend on MAS for full functionality was not something I expected going in.
What I'm talking about so far is basically orthogonal to user-server authn/authz flows and mechanics (the scopes of MAS and OIDC). Tightly coupling user-user authn to client-server authz doesn't seem ideal.
For authenticating your own devices in EX, you are forced to verify them at login. If you have other devices flying around that aren’t verified then you have to use a different app to unpick the mess - in a Matrix 2.0 world it should not be possible to get into that mess (even if the server DB rolls back). So it’s only if you have 1.x clients hanging around that you need this… at which point you might as well use the 1.x clients to unpick the mess if needed.
For verifying other users - EX should support that well as the classic apps ever did.
The new Element design is nice.
I have succeeded 3 times to varying degrees (never got the extra things added like better moderation or custom stickers I think it was) -
I just did a quick ddg search to see if there are current docs on doing this setup.
Last time I remember running into docs that said these are old docs being archived, but no new docs available.
I spent a number of days in the chat trying to hone in on the small errors in homeserver yaml and going back and forth trying to get nginx or caddy to do that basic things it needs to.
I'm sure there were other weird things.
My quick scans of the search results and stuff on element saying its old, use pro element (with no links to pro element, which I finally found, - now has me out trying to learn how to use Kubernates or whatever - so another detour to other places to learn things before getting to 'is it possible to install this thing on current debian today'.
before I can even get to seeing if the install info is updated or complete these days.
I'd love it if someone that writes docs there could watch somebody try to install this thing, and all the going back and forth and searches and 20 different websites and tutorials from so many different places to do things to make it work.
It's worth it, but it's a lot of moving parts to get started,
and the moderation - that was 10 times easier with RealChat system Eugene released to the world 22 years ago.
Still there's nothing better self hosted that I have found.
Then a downloads page (which I clicked to wonder if it was 'you need a client to interact with our cloud service' kind of page.. seems to point to self hosting as an option - so I will give this a go.
I recently gave a presentation for another biz about chat community options. During the research I stumbled upon rocket chat with a totally grown up look and feel quite shockingly, and found trillian.im as possible self host contenders.
There were a couple others but some things in my features matrix made them less likely as a replacement for matrix as an option for those needs.
I'm still hopeful for matrix to become easier to deploy and easier to use, as it has real potential.
One reason wordpress got so popular is it's famous 5 minute install; and that was doing it manually.
Any noob can rent a $10 shared host, login to cpanel (or other panel these days) and click a button that installs wordpress, it's needed DB, creates the admin and emails you the details. Up an running in seconds.
somebody get matrix to run via one click with softalicious / fantistico like abilities please!
Of course wordpress benefits from lots of paid addons (for hundreds of developers not just wp/automattic) and a healthy 'pay for development ecosystem' - but most of that grew from the ease of install (and at the time lots of fancy free themes that were subsidized from many groups with different reasons).
With matrix I wish there was a chart of wanted features / fixes and people could escrow vote with dollars for things and they get released to everyone.
I think I group funded a feature for rocket chat years ago with options via bug county source? Something like that.
I also think Matrix would be better as a no federated self hosted install and connect some sort of bridge on a different server if someone wants to connect the federated stuff - less complaints and support issues with being bogged down.
The agony of trying to install has made me find other things to do so I can avoid having to do it this weekend, and I should of redone it last weekend. sigh.
I mean, I'm admittedly biased here, but the "easy to deploy, $10 shared host IM" already exists and is XMPP. Matrix is doomed to be inefficient, and that's baked at the protocol level. It won't ever get easy and cheap to deploy and run, judging from the recent year's trajectory, with more and more components being added to the mix.
> somebody get matrix to run via one click with softalicious / fantistico like abilities please!
https://www.process-one.net/download/ejabberd/ ← Docker, RPM, DEB, binary, pick your poison. It really doesn't have to be that hard.
> I also think Matrix would be better as a no federated self hosted install and connect some sort of bridge on a different server if someone wants to connect the federated stuff
You just described federation. Anyhow, do you know what's the world's largest non-federated ejabberd instance? It's WhatsApp. Yes, that WhatsApp: https://www.process-one.net/blog/whatsapp-facebook-erlang-an...
Another software delivering a slack-lite experience geared towards corporations is prose: https://prose.org/ it's also XMPP, their client can be used with ejabberd but they have an easy-deployment bundle that ships Prosody instead (yeah, unlike the Matrix ecosystem, XMPP has multiple completely viable and compatible implementations, ejabberd and prosody being only the two most popular).
As a small self-hoster, the pile of growing services (that I presume are/will be de-facto required) that come with Synapse is not a good outlook.
Kind of sad that this is touted as a 'feature' in 2025.
No idea how that is supposed to improve things really. Why is it always necessary to break user's muscle memory with this types if extreme "improvements"?
I'm still trying to find out where to manage my Sessions in the newer Element versions (I have to keep a very old one around to do that).
I'm probably going to switch back to using nheko which also has the benefit of being much lighter on resources. Nheko I can collapse the name list right down to icons if I want.
However, in practice, I've rapidly found that I genuinely don't mind the new layout, and actually prefer it. (And I tend to be have a bad attitude to change in general). The reasons are:
* It's way faster to switch rooms
* You can filter on People by hitting the People filter button rather than having a dedicated section.
* I spent my life scrolling around the previous sections, or manually resizing them, etc, whereas the simplicity actually feels a bit refreshing and lighter weight.
That said, this is an initial release of the new room list, and there's a bunch of work to be done still:
* Need to support collapsing the LeftPanel like we used to be able to.
* There's a plan to re-introduce Sections again (so you can see your favourites etc separately to the main contents if you want - and reclaim muscle memory)
In terms of where to manage Sessions in Element Web/Desktop - it should always be the 'Sessions' tab in Settings? If your server is using native OIDC (i.e. matrix-authentication-service) then some of the management gets delegated to MAS and links through to account.matrix.org (or wherever your MAS lives). But if you can't see any way to manage Sessions, then it's likely a misconfiguration or a bug; please let us know the details.
This might be the point where I give up on Element (or Matrix entirely), I was willing to excuse some of the jank in exchange for it having all the features in a somewhat reasonable UI, but if they break that what's the point. Messing with it while Element X is still incomplete feels like a very weird choice.
For that to have a chance they need user-interfaces that are just as easy to use, and almost feature parity with what chat program people currently are used to.
Search, for instance, is a major weak spot; it sometimes gets its index messed up and resetting it a bunch of times still doesn't work. Even when it does work, it fails to find what I'm looking for. This is partly because because the protocol doesn't actually define any particular search behavior, so there's no way to even know what the search is doing (i.e., whether it's searching for literal text, some kind of "smart" search, or what).
Another obvious UI gap is moderation tools, which are woefully inadequate to actually handle the kind of spam that sometimes floods in. Some of this also has to do with things that probably should be fixed on the protocol or server level (e.g., some kind of flood detection).
For people looking to Element as a Discord replacement, what would help are changes that make things work more like Discord in various ways (e.g., joining a space auto-joins you to various rooms), but again these require protocol-level support.
Overall I'm actually pretty satisfied with the Element desktop UI, and the main issues I've had with it (apart from the above) are in the onboarding/verification stuff, which is an area where things have noticeably improved over the past year or two. I wouldn't say that the Element desktop UI is a major weak point for Matrix. There are much bigger problems that need to be tackled, and my prediction is that as long as they remain untackled, small-scale UI changes like the ones mentioned in the post aren't going to move the needle.
> ...lays the groundwork for a more resilient technical foundation
Let's hope the protocol improves
Good summary of what's wrong: https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg...
For anyone who doesn't know the difference between XMPP and Matrix (like me): https://claude.ai/share/a2624334-d21e-455a-a1b3-9025c69a921a
Matrix problem statement/what it set to do differently is "rooms should survive their server going down". Although nice-sounding, it's never realized in practice: your server going down means your account is unavailable too, and you can't use the network. Rooms syncing is essentially "old IRC net splits" with more steps (and much more RAM/CPU). This way of tackling this sort of "high availability" at the protocol level makes implementing the Matrix spec impossible (there is only one almost-compliant server implementation to talk with almost one feature-complete client, all by the same entity, selling it as opencore). Now compare that with the half dozen or so well-maintained XMPP servers (and plethora of clients), most of which support a form for HA/resilience that happens at runtime-level instead of protocol-level (via Erlang clustering/distributed JVM). In other words, if that's what you care about, XMPP implements Matrix mission statement better, more efficiently and with less organisational centralisation than Matrix.