I'm nervous. They stopped working on the Dendrite home server, which does not support sliding sync. They stopped working on the sliding sync proxy, which uses an old version of sliding sync that is no longer supported by Element X. Element X requires sliding sync. There is no way to migrate data from Dendrite to Synapse or Conduit, either. It kinda seems like they're creating a situation where we inevitably have to lose a bunch of data. I get that Dendrite was never stable, but the documentation made it seem like 1. It was the future, 2. It was lighter weight than Synapse, 3. It would work just fine for small home servers.
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.
Well, I give a damn, and i'm responsible for both Matrix & Element :)
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 guess I'm somewhat sympathetic, but I don't really think you are giving credit to how dire the situation is right now. My homeserver, among surely many others, is trapped on a dead end program that barely works nowadays. Large federated room joins takes literally hours, and that isn't just exaggeration. Nevermind the several month long period where the only version of Dendrite that was safe from serious security vulnerabilities was one that locked up for several minutes at a time many times per day... and on top of that, more and more clients don't even support it. There was even a brief period where I couldn't use Element! I guess credit to you guys, you did roll it back, but as an end user that was a pretty "interesting" experience.
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.
"We’ve also removed the duplicative meta-spaces (People, Favourites). Filters are the new foundation — more flexible, more future-proof, and built for growth."
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.
As I mentioned here (https://news.ycombinator.com/item?id=45377920), sections may well return - they just didn't make the first cut. Meta-spaces ARE duplicative though, if you already have filter buttons which do precisely the same thing - and these are the filter buttons which have been added.
Still rooting for y'all but did you do any user testing of this? It constantly collapses the filters meaning it's absolutely more thought and clicks every time than just having the favorite button. It would be so, so easy to just not collapse those filters. Or, potentially consider that "duplicative" is not a reason for an unpopular UX change.
It's possible that I'm totally missing what everyone's talking about. The design team did do a tonne of user testing on this, and this is the result.
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 mean that every single time I reload Element I have to re-expand the filters to get to favorites. It's hidden. It's an extra click. It's extra cognitive load.
Does this depend on sliding sync and their standalone authz server like Element X does?
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.
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...
I've lucked out and haven't had any issues like that on my tiny home server.
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.
We're actively trying to fix that - we're finally launching an official Web admin interface as FOSS (AGPL) for Synapse in the next day or two (it was meant to ship today in fact, but got blocked on a debate on how to distribute the containers).
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.
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}.
> 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.
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.
On the "Space" sidebar I used to have a button list rooms outside of any "Space" and a button to list only DMs.
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.
> Meanwhile, the company appears to have begun quietly phasing out the classic Element app in favor of Element X, even though it still misses crucial features like threads and spaces, besides the less important things like widgets, grouping by priority, and live location sharing.
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.
> 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.
The real crucial missing piece in Element X compared to Element is key/device/session/verification management and insights. Fully self-managing a user account or chat sessions currently can not be done in EX. Verification ceremony becomes meaningless without the degree of control and detail which is available in Element but not Element X.
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.
> The real crucial missing piece in Element X compared to Element is key/device/session/verification management and insights.
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.
This all assumes that things are always consistent, free of bugs and clears throat database issues (yeah we got hit by that too - I don't see how we'd been able to troubleshoot and salvage it as well as we managed if we had been on EX only - MAS or not)....
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.
I suspect we'll end up bundling MAS inside Synapse for situations like this - trying to limp along on the legacy auth stack when stuff like 2FA/MFA/QR-login etc are all handled by MAS/OIDC will be painful.
Still, keys and sessions should all be managable from the client and not depend on a separate server/browser flow, no?
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.
user-user authn is indeed orthogonal to client-server authz.
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.
This is interesting timing because I self-host a Matrix server (Conduit) for some friends and we were lamenting the dearth of good apps. I'm currently using Cinny as a Safari app on desktop and PWA on my phone, and Element.
I am about to embark on my 8th attempt to install matrix / synapse / element in a fresh debian box.
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.
I admire your perseverance, I gave up on Matrix personally. When was the last time you had a shot at XMPP? Have you tried ejabberd? That's probably one of the most "fire and forget" services I sysadmin, and it does everything out of the box as a single server (STUN/TURN, audio/video calls, …). That's refreshing.
Does this update break calls? I recently set up coturn along with Synapse, but found out that ElementX cannot call Element and now requires Element Call (whatever it is).
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.
I noticed it yesterday and I have to say I hate it. The "Peoples" section seems to be entirely gone (it's now intermingled with rooms in the "Home" section). You no longer can see favorite/ normal/ low priority DMs or rooms in proper order at once. E.g. in Spaces I had my one or two favourite rooms at the top in a separate section; now it's somewhere messed up in the middle with the normal priority stuff. You constantly have to fiddle with the space-wasting bubble buttons to find stuff.
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'll just go and say I hate the design changes in desktop, it's more cluttered without good reason. Feels like they made the text bolder and added a bunch of borders or increased them where they weren't before. You can't collapse the names down as far as you could in the past to save space so when this app runs tiled it's stuck with like a third less functional space than it used to have.
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.
Honestly, this was the reaction I expected to have when I first started using the new roomlist (which was built by the Element design/product/eng teams, rather than the old one, which was originally written by me).
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.
Yes, it's pretty terrible. Especially since the filters reset every time you switch spaces, so you need to set them again constantly. And filters only is just worse than dedicated sections where you can actually see multiple at a glance in smaller spaces.
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.
I second the sibling comment recommending XMPP. Take a mature server like ejabberd, set up your DNS and firewall, and you are good to go. Easy, secure, extremely reliable and scalable.
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.
Yeah, no. I lost hope that they have any idea of what they are doing, or any willingness to improve and drop out of the sunk cost fallacy that paralyses them. Every two years or so they break protocol and implementations with big promises that "this time the charm, finally", and it's essentially the same slow mess with some new bugs.
I think it would be nice to get even more people using something like Element rather than a Meta-owned app, Microsoft Teams, etc.
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.
This doesn't make anything easier to use, the old interface was more like other chat apps. On top of it being large-ish changes in the "old" client, when the new one that's supposed to replace it and be so much better still doesn't do everything (and they've already pissed of a good chunk of users by hyping that before it was ready, so they stuck with the old client for now waiting, just for that to get messed up too).
I'd agree with that, but based on this post I don't see that this is a huge step forward. From my perspective the big UI issues are not with this kind of stuff. Some of the bigger problems are intertwined with the server and protocol.
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.
I'm nervous. They stopped working on the Dendrite home server, which does not support sliding sync. They stopped working on the sliding sync proxy, which uses an old version of sliding sync that is no longer supported by Element X. Element X requires sliding sync. There is no way to migrate data from Dendrite to Synapse or Conduit, either. It kinda seems like they're creating a situation where we inevitably have to lose a bunch of data. I get that Dendrite was never stable, but the documentation made it seem like 1. It was the future, 2. It was lighter weight than Synapse, 3. It would work just fine for small home servers.
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.
Well, I give a damn, and i'm responsible for both Matrix & Element :)
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 guess I'm somewhat sympathetic, but I don't really think you are giving credit to how dire the situation is right now. My homeserver, among surely many others, is trapped on a dead end program that barely works nowadays. Large federated room joins takes literally hours, and that isn't just exaggeration. Nevermind the several month long period where the only version of Dendrite that was safe from serious security vulnerabilities was one that locked up for several minutes at a time many times per day... and on top of that, more and more clients don't even support it. There was even a brief period where I couldn't use Element! I guess credit to you guys, you did roll it back, but as an end user that was a pretty "interesting" experience.
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.
Self-hosting XMPP with servers like Prosody and Ejabberd are pretty easy. Much easier than Matrix.
"We’ve also removed the duplicative meta-spaces (People, Favourites). Filters are the new foundation — more flexible, more future-proof, and built for growth."
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.
As I mentioned here (https://news.ycombinator.com/item?id=45377920), sections may well return - they just didn't make the first cut. Meta-spaces ARE duplicative though, if you already have filter buttons which do precisely the same thing - and these are the filter buttons which have been added.
Still rooting for y'all but did you do any user testing of this? It constantly collapses the filters meaning it's absolutely more thought and clicks every time than just having the favorite button. It would be so, so easy to just not collapse those filters. Or, potentially consider that "duplicative" is not a reason for an unpopular UX change.
It's possible that I'm totally missing what everyone's talking about. The design team did do a tonne of user testing on this, and this is the result.
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 mean that every single time I reload Element I have to re-expand the filters to get to favorites. It's hidden. It's an extra click. It's extra cognitive load.
oh! well, that's trivial to fix.
Does this depend on sliding sync and their standalone authz server like Element X does?
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.
> I don't really have an appetite to spend 12 hours of my free time standing up sliding sync
This has been built into synapse now for months, maybe a year. Does not require a second sliding-sync component anymore.
That's great!
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...
> What about Matrix Authentication Service?
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've lucked out and haven't had any issues like that on my tiny home server.
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.
We're actively trying to fix that - we're finally launching an official Web admin interface as FOSS (AGPL) for Synapse in the next day or two (it was meant to ship today in fact, but got blocked on a debate on how to distribute the containers).
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}.
> 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.
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.
On the "Space" sidebar I used to have a button list rooms outside of any "Space" and a button to list only DMs.
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.
> Meanwhile, the company appears to have begun quietly phasing out the classic Element app in favor of Element X, even though it still misses crucial features like threads and spaces, besides the less important things like widgets, grouping by priority, and live location sharing.
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.
> Meanwhile, the company appears to have begun quietly phasing out the classic Element app
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.
The real crucial missing piece in Element X compared to Element is key/device/session/verification management and insights. Fully self-managing a user account or chat sessions currently can not be done in EX. Verification ceremony becomes meaningless without the degree of control and detail which is available in Element but not Element X.
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.
> The real crucial missing piece in Element X compared to Element is key/device/session/verification management and insights.
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.
This all assumes that things are always consistent, free of bugs and clears throat database issues (yeah we got hit by that too - I don't see how we'd been able to troubleshoot and salvage it as well as we managed if we had been on EX only - MAS or not)....
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.
I suspect we'll end up bundling MAS inside Synapse for situations like this - trying to limp along on the legacy auth stack when stuff like 2FA/MFA/QR-login etc are all handled by MAS/OIDC will be painful.
Still, keys and sessions should all be managable from the client and not depend on a separate server/browser flow, no?
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.
user-user authn is indeed orthogonal to client-server authz.
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.
This is interesting timing because I self-host a Matrix server (Conduit) for some friends and we were lamenting the dearth of good apps. I'm currently using Cinny as a Safari app on desktop and PWA on my phone, and Element.
The new Element design is nice.
I am about to embark on my 8th attempt to install matrix / synapse / element in a fresh debian box.
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.
I admire your perseverance, I gave up on Matrix personally. When was the last time you had a shot at XMPP? Have you tried ejabberd? That's probably one of the most "fire and forget" services I sysadmin, and it does everything out of the box as a single server (STUN/TURN, audio/video calls, …). That's refreshing.
Does this update break calls? I recently set up coturn along with Synapse, but found out that ElementX cannot call Element and now requires Element Call (whatever it is).
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.
Seems heavily inspired by MSTeams
Should add a link to the main site from the blog on the mobile layout
> We’re dialling down the drama (yes, that red !) and turning up readability
Kind of sad that this is touted as a 'feature' in 2025.
The back button does not work on my phone, android.
A little bit of slack here, a little bit of teams there and a smidge of discord. Really not sure about it.
I noticed it yesterday and I have to say I hate it. The "Peoples" section seems to be entirely gone (it's now intermingled with rooms in the "Home" section). You no longer can see favorite/ normal/ low priority DMs or rooms in proper order at once. E.g. in Spaces I had my one or two favourite rooms at the top in a separate section; now it's somewhere messed up in the middle with the normal priority stuff. You constantly have to fiddle with the space-wasting bubble buttons to find stuff.
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'll just go and say I hate the design changes in desktop, it's more cluttered without good reason. Feels like they made the text bolder and added a bunch of borders or increased them where they weren't before. You can't collapse the names down as far as you could in the past to save space so when this app runs tiled it's stuck with like a third less functional space than it used to have.
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.
Honestly, this was the reaction I expected to have when I first started using the new roomlist (which was built by the Element design/product/eng teams, rather than the old one, which was originally written by me).
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.
You'd think Element would have enough "we'll fix it in the future, we promise" problems that you didn't intentionally cause...
Yes, it's pretty terrible. Especially since the filters reset every time you switch spaces, so you need to set them again constantly. And filters only is just worse than dedicated sections where you can actually see multiple at a glance in smaller spaces.
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.
The only design issues I ever had with Matrix was the protocol design. This is lipstick on a pig.
From the post:
> ...lays the groundwork for a more resilient technical foundation
Let's hope the protocol improves
I have no hope for matrix.
Good summary of what's wrong: https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg...
What do you recommend as a better (secure/private) alternative?
I second the sibling comment recommending XMPP. Take a mature server like ejabberd, set up your DNS and firewall, and you are good to go. Easy, secure, extremely reliable and scalable.
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.
I haven't come around to actually look for an alternative but XMPP will the first I'll try.
Poor performance, UX, and reliability issues. WELP, seems like XMPP is much simpler to use.
For anyone who doesn't know the difference between XMPP and Matrix (like me): https://claude.ai/share/a2624334-d21e-455a-a1b3-9025c69a921a
Yeah, no. I lost hope that they have any idea of what they are doing, or any willingness to improve and drop out of the sunk cost fallacy that paralyses them. Every two years or so they break protocol and implementations with big promises that "this time the charm, finally", and it's essentially the same slow mess with some new bugs.
Whats Bad with the protocol design?
https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg...
For example.
I don't really get why they're spending their time on this kind of window dressing.
The client sorely needed it. It’s really not weird to devote some resources/cycles to this.
To me the client feels so massively bloated it's almost unusable... I'd much rather they focus on speed.
I think it would be nice to get even more people using something like Element rather than a Meta-owned app, Microsoft Teams, etc.
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.
This doesn't make anything easier to use, the old interface was more like other chat apps. On top of it being large-ish changes in the "old" client, when the new one that's supposed to replace it and be so much better still doesn't do everything (and they've already pissed of a good chunk of users by hyping that before it was ready, so they stuck with the old client for now waiting, just for that to get messed up too).
I'd agree with that, but based on this post I don't see that this is a huge step forward. From my perspective the big UI issues are not with this kind of stuff. Some of the bigger problems are intertwined with the server and protocol.
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.