So Aurora (https://github.com/element-hq/aurora) is a proof-of-concept we put together of rust-sdk on Web, using the new MVVM components from Element Web. However, the plan is likely not to actually switch base to Aurora, but instead migrate SDK within the existing app codebase eventually. (We might end up using Aurora for other purposes though). Either way, the ground work is the same: to split up the current app into MVVM components which can run on either js-sdk or rust-sdk.

> The outgoing Element mobile app (‘classic Element’) will remain available in the app stores until at least the end of 2025, to ensure a smooth transition

https://element.io/blog/mas-migration-unleashes-element-x-on...

I can't find any other communication from Element Creations other than that.

The renaming to Element Classic doesn't bode well considering that Element X still doesn't support a vast number of home servers and a number of Synapse authn/authz features.

If they remove it from the app store, my advice for my users is going to be to switch to fluffychat, and I'll eventually migrate away from Synapse to some flavor of Conduit.

Element X now has initial support for threads & spaces (as of last week), which were the main things missing from full parity with Element Classic.

As of lately, Spaces are now supported in Element X which possibly brings it to feature parity (at least I wouldn't know what's missing, and I've been using Element X now for some months because of these plans)

You can learn more about Element X migration plans from last weekend's Matrix conference here https://youtu.be/_cahXxr8d-4?si=0b9qyjiEYVpMczDy&t=442

Absolutely not. It doesn't have commands and probably a lot more.

It also does not have parity by having deliberate breakage like calls.

It's a sluggish buggy mess, so I guess you could say it has parity in that aspect.

Matrix allows for unencrypted messages so it's inherently less encrypted than Signal. The federation capability also means messages leak metadata. Furthermore, encrypted messages also contain some metadata in the unencrypted envelope. Some protocol features (emoji reactions) also ended up outside of the encrypted envelope because of that. It's a risk with any protocol that has encryption bolted on and optional.

On the other hand, you can host your own Matrix server and still participate in the network, whereas Signal will have you convince your friends and family to install a custom Signal client if you want to run your own Signal server, for instance because you don't want to rely on Amazon's servers (Signal was down when Amazon went down this morning).

Signal sacrifices network openness for encryption capabilities.

There's also the MLS/MIMI side of things, but AFAIK that work hasn't been completed yet (MIMI isn't even a full RFC yet).

Element/Matrix, with some modifications, has been chosen as the messenger of choice by the French government (Tchap) as well as the German military (BwMessenger, BundesMessenger) and healthcare (TI-Messenger).

I think these two topics need to be looked at a bit separately, similar to for example WhatsApp, where you have e2ee but there are still lots of privacy risks.

In the matrix ecosystem, as far as I understand, having only one user from the matrix.org homeserver in your room already undermines metadata privacy to some degree. Also, there still are issues with decrypting messages from time to time with certain combinations of clients, rooms and homeservers, which effectively means that the "failsafe" option for getting messages across the network is using unencrypted rooms.

Having free, secure, federated, usable instant messaging is still not solved imho, and I think it's not easy to solve. So far matrix is the best attempt in my book, but it's also not there (yet?).

I don't think this is a super useful comparison, because the two services have wildly different threat models. I think of Matrix as a secure replacement for Discord. Signal is about small group messaging. It's literally a replacement for the built-in texting app on your phone, and that's its intended userbase. Signal is what you use when you need to know, to the limit of best practices available to ordinary users, that your messages will be as private as they can be made to be. That's a goal that isn't compatible with many of the affordances people want for project discussion platforms and things like that.

If you pit Signal against Matrix and make the competition purely about security, Signal will win for the foreseeable future. But I think it makes much more sense to think about different sets of tradeoffs being more appropriate for different kinds of problems.

Signal requires a phone number, and AFAIK the PIN to prevent carrier-level attacks (well known) is not enabled by default.

Signal is a cryptographically well thought out protocol that reduces meta data.

Matrix does not even encrypt emoji reactions.

Signal is centralized, so it becomes a huge target of all kinds of hackers and three-letter agencies. This alone is sufficient for me to never touch it. And then, there is this:

https://news.ycombinator.com/item?id=42788647

https://news.ycombinator.com/item?id=39445976

It's exactly the same encryption tech, but a bit more trustworthy than signal.

Aside from the other comments, I would say that a modern chat application is anything but 'simple' - there are a vast amount of features that you expect, from pinned messages to file downloads to threads, to say nothing of end to end encryption.

The only desktop messenger with smooth performance I'v used was Telegram. Signal, WhatsApp, Element, and all the other Electron applications all introduce hard-to-pinpoint latency somewhere. Unfortunately, Telegram is... Telegram.

For XMPP/Matrix/etc. there are plenty of (more) native alternatives but they're not as feature complete as Telegram or their Electron counterparts, unfortunately.

My lack of C++ and Qt experience has still managed to keep my urge to rip out the Telegram protocol and replace it with something else. Maybe I'll try throwing AI at the problem and release a slop POC. Secretly, I'm hoping someone else will do the hard work for me...

The mobile apps for all are fine, though. Electron hasn't hit mobile phones just yet.

which app are you talking about? as per the conference keynote, there are loads of different ones now, written in different stacks without any overlapping implementations.

If you're talking about the old Element Classic mobile app, then yes, it's now been replaced by Element X (which now has spaces & threads support, and so pretty much has parity with the old app), and it is super fast, and not buggy.

I have been self hosting a matrix setup for a few years now, using the spantaleev ansible playbook. It does require updates roughly once a year to keep up with changes of the 3rd party chat APIs. Generally that involves logging into the server and running 'just update' followed by 'just install-all', but occasionally there are changes that need updates to the playbook as described in the release notes. In the worst case, if one of your bridges does go down you can always fall back to the vendor client for that protocol until you get the bridge updated.

Overall it has been absolutely rock solid, and the new element x app has been night and day compared to the old one.

Feels a lot like the days of using Pidgin chat, but since the bridges run on the server you only need to authenticate once instead of going through the process for every device.

I've been hosting Matrix Synapse and mautrix-WhatsApp bridge for many years. Due to WhatsApp changes, bridge has to be updated periodically (about 1-2 times a year IIRC), but it has worked pretty reliably otherwise.

You do have to keep bridges up to date, because they need to remain compatible with the internal APIs of other platforms. Beeper.com (mentioned by a sibling comment) is a commercial deployment of the mautrix matrix bridges, along with some propietary components. You can deploy the exact same bridges using their documentation: https://docs.mau.fi/bridges/ - although you won't have access to the propietary beeper client or hungryserv.

Your best bet for that is almost certainly beeper.com, which isn't FOSS, but specialises in combining messaging channels and is built on Matrix. Otherwise, you do have to run your own bridges and hope for the best, and moreover the bridges re-encrypt Signal and so miss the point of its end-to-end encryption. On the Element side, we're not focusing on bridging currently.

There was an internal retro, but nothing external - from our perspective the upgrade was overall successful. What bridges are you thinking of which don't support v12?

We will start force-upgrading foundation-managed matrix.org rooms sooner or later; the only reason we haven't yet is trust & safety manpower rather than there being a problem with v12.

the rationale is to get element (and the foundation) sustainable by funding from big institutions. meanwhile the competition is typically whatsapp & signal, so the hope is that whatever works for institutions will also work for average users.