We have lift-off Element X, Call and Server Suite are ready

We have done a huge amount of work on fixing E2EE issues - when running latest matrix-rust-sdk clients (e.g. Element X) and matrix-js-sdk using matrix-rust-sdk-crypto (e.g. Element Web/Desktop), "unable to decrypt" bugs should be unheard of.

So, the point of this blog post is to try to spell out that we've fixed this.

Meanwhile if you see ANY unable to decrypt errors, PLEASE submit debug logs on both the sender & receiver, and we will jump on it aggressively.

In terms of threads: yes, the stuck unread notification bug(s) were a disaster, but also fixed last year. Behind the scenes, 2023 was an absolutely awful year for Matrix & Element along many axes, c.f: https://matrix.org/blog/2023/12/25/the-matrix-holiday-update.... Sorry that you got caught in the disruption.

I have had similar experiences, but not on professional context. Random E2EE key issues (not often) that maybe sometimes resolve themselves or with some additional action like bringing all clients online. Matrix is still the best choice for me, though, and I expect it to improve like it has over the years.

Last time I tried the threads-feature (with Element) maybe a year ago, it was still in beta.

Anyhow, if you're ok with Slack, then you probably could have just not use E2EE at all and avoid issues related to that?

i havent seen any encryption issues since about q3 2023, notifications are still a thing tho, they are reliable but setting them up the way you want is still a pain

my experience is based on regular old element clients and my own server and will be moving to x and sliding sync probably at the end of the year

First of all, we're shifting to generating a recovery key (like FileVault or similar) rather than forcing users to pick a recovery passphrase which they promptly get confused with their account password and/or lose.

Secondly, we're making it much less likely to actually need to ever enter a recovery key - with QR login meaning you just scan a QR code to launch your account, complete with all e2ee state (assuming you're already logged in somewhere; same as WA or Discord etc).

In the end, though, if you lose all your devices, you have no choice but have some kind of recovery key to get back in. We could use your account password, but (particularly in an OIDC world) it's then challenging to avoid exposing the account password to your server admin (thus breaking E2EE).

So instead, we're hoping that users will either save their recovery key, or worst case, if they do, they can reset it... but that will inevitably mean they won't be able to access their old messages from backup any more.

In my experience, there was issues of lost/undecryptable messages also when you did backup/restore your keys.

That was the annoying issue, I could not trust it.

as always, the result of more security without taking into account real-life human behaviour, only leads to less security overall as people will just use services that don't have this behaviour and always allow getting back your account

The registration flow on matrix.org was a last minute sprint to get something that works there, given we haven't finished the OIDC migration for matrix.org migration. It landed 4 days ago here: https://github.com/element-hq/element-x-android/pull/3467 and while we tried to QA it on a range of devices & OSes I'm not surprised we missed some. The good news is that it can be easily improved serverside given it's "just" a helper webapp which is doing the registration flow.

Sorry you got bitten by this. I'd be very interested if you can compare it with the flow if you specify beta.matrix.org as the homeserver.

I'm honestly not sure what you're talking about here - the roomlist is pure SwiftUI, and looks almost identical to iMessage or WhatsApp to me. What is the "glaring spacing/padding issues" you're talking about? Similarly on the timeline views...

Can you link to a bug on github.com/element-hq/element-x-ios/issues please?

I'm probably biased by the fact that the first time I got Synapse running it was the release where it'd endlessly try and fail to join a room with more than 10 people.

But, every time I've looked at Matrix Chat it's been a disaster. That it tries, at all, to authenticate every personal(?home?) server as soon as you join #matrix is... Bad, from a lot of perspectives.

Privacy? Just put up your own DNS and find out what new servers are joining.

Security? Easy slowloris type attacks at several layers- DNS, http, etc.

Performance- eagerly enumerating all federated servers before joining a channel places a hard cap on channel and overall network size. And it provides a terrible experience.

The more I look, the less I like what I see. As a potential user, a software dev, and an admin it leaves me with two impressions: sloppy at best, braindead at worst.

Plus it also supports federation. Oh, and it's open-source.

Matrix as a protocol, and synapse / element, the most common backend and client for the protocol (I believe), have existed for quite some time. Our co-op has been using synapse for about a year and a half now and I'm sure the majority of our members use Element as the client. Our managed hosting comes with an Element web deployment as well.

We used it as a drop in replacement for slack including automations etc. The bonus was we got, I can't remember the technical term but mirrors or duplicators for Instagram etc set up, so people can use the element app to message people on Instagram, Whatsapp, etc, if they'd like. I like it because I can message people without Instagram first trying to suck me in with Algo bs.

We did improve things massively (like, 5x) with Faster Remote Room Joins: https://github.com/matrix-org/matrix-spec-proposals/pull/390... and https://element-hq.github.io/synapse/latest/development/syna....

We did all the super-hard groundwork to make non-atomic joins possible - but then ran out of time & $ to go further (plus none of the Element paying customers are complaining about it). There's another order of magnitude speedup to be had there, though.

Between this and https://github.com/matrix-org/matrix-spec-proposals/blob/mat... we should be able to fix things unrecognisably, but just haven't got there yet.

> Matrix is mostly a victim of the government forks taking up their time in different directions instead of having just one app like signal.

It's a double-edged sword. On one hand, it generates $ to work on Matrix. On the other hand, it means that if none of the $-payers care about faster remote room joins, they get deprioritised :|

omg I want this to work so much. But the first message i send on element x crashes the app. (counter party did not have all devices verified)

done - thanks! not linked to Fdroid as it's stuck on a reproducible build nightmare currently

It's also on FDroid :)

Personally, I don't think it's anything unfixable. At least slow joins with large rooms got improvements last year or something. E2EE is nowadays on by default, and I haven't had any decryption issues recently, but E2EE is not mandatory. Notifications have had some changes too, but I can't comment much on that or your other issues.

Is Jabber still around?

just not implemented on mobile yet - sorry. it will be much easier to add for Element X though given the e2ee text indexer (Seshat) is already written in rust and does the right thing though.

Or like the actual title of the blog entry?

> We have lift-off! Element X, Call and Server Suite are ready!

Just some url/tag parsing/generation gone wrong.

so that when someone pwns your chat server, they don't walk off with all your communication history.

If you want audit, you then add it on separately, in a separate locked-down deployment, compartmentalised from the rest of your infra and the chat server, so that an attacker would need to pwn an audit client connected to that instead.

... So that the content of the chats isn't trivially read by unauthorised third parties?

> the typical reaction from an Element dev is “it works fine for me, make a PR or something”,

This is false. We check issues which people file and try to reproduce them, and we certainly don't ask randoms to contribute PRs to fix stuff - we'd much much rather fix them ourselves.

Meanwhile, you can see the issue stats at github.com/element-hq/element-x-ios/issues and github.com/element-hq/element-x-android/issues - it's not like we're ignoring or failing to close issues.

I meant “room directory”, not “room list”. Can’t edit the comment anymore :(

I for one am shocked and stunned that early Element X builds had bugs. Now that we've finally launched it for general availability, hopefully the situation is better :)

hm, i wrote an answer on this but it seems to have vanished.

ESS uses Matrix Authentication Service (https://github.com/element-hq/matrix-authentication-service/) which is a very lightweight Matrix-aware rust OIDC IdP intended for embedding into Matrix homeservers to make them OIDC-capable. It provides the same featureset as pre-OIDC Matrix auth, and then lets you delegate to an upstream IdP (keycloak, authentik, forgerock etc) for a full featureset (2FA, MFA, etc).

I don't know about ESS, but for selfhosting I can recommend Zitadel or Authentik, I've used both and currently I'm using Zitadel.

Seems like ESS ist their managed solution, which uses Synapse but with an admin UI.

Thats at least how I understand it, because to "get" ESS you need to fill out a contact form.

https://try.element.io/get-started

https://github.com/element-hq/ess-starter-edition-core

They ship a k8s operator that deploys Synapse, will try that later. Supposedly it's free up to 200 users. But it seems like there's 0 documentation past the README.

It is generally not a good idea to run web services on a file server.

Seems like this is a paid product meant for enterprise use.

Have you tried desktop to register your account?

Yes, it's included (and enabled by default) since v1.114.0, which came out 3 weeks ago. It's a modified version of Sliding Sync (called Simplified Sliding Sync), but it works just the same. So you can deprecate/shut down existing sliding sync proxies.

They already excluded older iOS devices before - on my older Air I had to switch to Fluffychat until I've got a newer device

lets give them a break they have so many forks to maintain already

[dead]

They wanted to reduce the duplicate work of maintaining multiple clients for each Platform, and created a rust library which can be used on all platforms.

And for the UI they use Jetpack Compose for the Android App and SwiftUI (I think that's how its called, correct me if I'm wrong) for iOS.

This way only the UI is "duplicate" but the core logic is maintained in the rust library.

EDIT: Okay just found my comment from 300 days ago: https://news.ycombinator.com/item?id=38402710

Element X is a totally new implementation, done in Rust. It's fast and nice but for now some features are missing compared to the old one.

it's a rewrite. it'll replace the old app once it has full feature parity with it.

browsing rooms is deliberately not implemented in Element X yet; it's intended more as an imessage/whatsapp style messenger - plus exposing the matrix.org room directory make appstore review & age-rating etc much more complicated.

:D

what OS, build, and can you please link me to GH issues so i can chase them? We're not aware of any push problems.

Matrix: Protocol (like SMTP/IMAP)

Element: The most popular client (like Thunderbird)

Element X: Rewrite of Element based on Rust and native UI components

Synapse: Most popular Matrix server (like Dovecot)

Element Call: Video/Audio conferencing (like Jitsi)

Element Server Suite (ESS): Paid SaaS solution that wraps all of the mentioned components into a simple turnkey solution.

Matrix is the protocol, Element X is one of many clients for the Matrix protocol.

Element is a client, matrix is a protocol, synapse is a mainline backend server. There are other clients (front-ends) and servers available on top of the matrix protocol. Hope that helps.

Looks crisp on my iPhone SE 2020, and scrolling does not make it lag - something that happens frequently on HUGE images encounter. Didn’t look at the media queries but I’m happy the default/broken state is the one easily accessible.

No such issue on my end.

Not for me?