Aurora is a big deal! I’ve been waiting for the Rust SDK to come to the web.
I’m not fully through the talk yet, but it looks like they’re first modernizing the old application and planning to eventually switch base to Aurora, which seems sensible!
Either way, Rust SDK on the web, finally! This will hopefully make it easier to write other Matrix clients, since the JS SDK is pretty undocumented (and outdated).
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.
I noticed that they renamed the Element mobile app to Element Classic. Has Element X reached feature parity and stability yet? For how long will Classic be maintained?
> 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
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.
Good to know! These are very important features and not having them really gets in the way of switching off of classic. I am worried about "intial" support - what is going to break with threads and spaces that I try to join with thr new Element X?
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)
I regret to concur. On an iPhone PRO MAX with iOS 18.7-latest, my stopwatch says:
- Element X loads to list All Chats in 3 seconds.
- Element Classic loads to list All Chats in <1 second.
And Element X is supposed to be the "fast one", due to Rust SDK, etc. etc.
I'm giving Element X etc. the benefit of the doubt and will see them through.
But there NEEDS TO BE a user-advocate or project-manager just wailing on usability internally at Element. If you need such a person, find someone, and if you can't find anyone, hit me up, but I would think someone should be filling this role already.
In addition to bundling and network effects, one magic thing that helped grease the skids for some apps like AOL Instant Messenger or Facebook Messenger (in its glory days) or WhatsApp/Discord/Telegram or whatever gain very wide adoption was their relatively seamless user experience.
As much as the Parent sounds like complaining, I think it's complaining in good faith. We want Matrix to succeed.
Hm. Something sounds wrong here, then. On my iPhone 12 Pro Max on iOS 26, my account (~5000 rooms) opens in about 2s in Element X iOS. On the classic app it’s about 10s (ie unusable).
Roughly how many rooms are you in? and what server is this on (it could be a serverside problem)? And what precise build of the app?
> and what server is this on (it could be a serverside problem)?
It's a hosted SaaS personal homeserver. So yes, quite possibly a server-admin issue. I've just put in a ticket to find out.
EDIT: Synapse 1.139.0
> And what precise build of the app?
Element X Version 25.10.0 (190)
EDIT: After updating to Element X Version 25.10.1 (192) [latest Update from App Store], about 2 seconds is observed -- still slower than Classic, but a little better than before. I will still finish following up regarding Server issues/info with server admins; hopefully that fixes it.
Thanks a ton for all you do! Good to know it's not the expectation.
This is really surprising. Can you do a clean launch (ie kill the app and relaunch it) and then submit a bug report from both apps and let me know what mxid to look for? (DM to @matthew:matrix.org if needed). The logs will say where the time difference is coming from. EX should always be way faster than classic Element.
what guide were you following that told you to install coturn for Element X? It shouldn't be /that/ surprising that Element X's group-capable calling requires a group call server, and in general most people seem happy to not have to worry about coturn given the server acts as a relay.
Element (not ElementX), the official/preferred app, works with coturn for 1-on-1 calls. But ElementX does not. IMO it is surprising to break 1-on-1 call functionality.
In Matrix 2.0, all calls are group capable (much like Matrix itself doesn’t specialcase DMs - they are just rooms with 2 people). So yes, no coturn is needed.
We haven’t got as far as interop between legacy Matrix 1:1 calling and Matrix 2.0 style MatrixRTC though, which I can see being annoying - but overall the admin burden should be simpler than running a coturn.
We’ll update the synapse docs to explain that coturn isn’t needed for MatrixRTC calls.
Compared to Signal, where does element stand today in terms of privacy and encryption? Due to the decentralized nature they werent able to offer the same guarantees from what I remember
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).
> Matrix allows for unencrypted messages so it's inherently less encrypted than Signal.
But that logic, Matrix is less encrypted than Whatsapp, too, which is a crazy thing to say.
> The federation capability also means messages leak metadata.
It's the opposite: The centralized architecture means that there is a single target server to attack for the metadata. With decentralization, you can't easily scale up your attack to all users.
Somewhat related - Can someone explain this to me? France and Germany want to lessen dependence on American organizations, so they choose Matrix, also an American organization.
Matrix, the organisation, takes care of the open source side of things.
BwMessenger is a partnership with "ELEMENT SOFTWARE SARL" (according to https://messenger.bwi.de/datenschutz), the French entity of the commercial side of the people originally behind the open Matrix ecosystem (https://element.io/legal/company-information). I'm not sure why the French entity is doing business with the Germans as Element also has a German entity, but either way the American side is not the one doing the work.
For the American entity, a lot (most?) of the work that's not from unrelated open source contributors seems to be coming in from either EU countries or the UK.
Element is also UK headquartered, albeit with French/German/US subsidiaries when selling to those respective governments. BWI buy via France because when we started working with them we didn’t have a German legal entity yet.
Signal and any kind of Slack SaaS: US infrastructure, US law around data governance. Matrix (and Zulip, for that matter, and mattermost too) encourage self-hosting on your own infrastructure, or at least in-country, even if the upstream security patches are coming from US developers.
If it's open source (and libre software) then it's not as important where the main development offices are (or where the company is incorporated). You still have control.
Thank you, and I see it's registered in the UK.
I think it started in the US? Well, not like it's relevant anymore.
And can you answer this question:
If everyone has secure chat, then won't that benefit criminal organizations?
I struggle to understand the love for private communication when it seems like that would benefit, for example, religious sects and sex abuse rings.
NOT that I like that Zuckerborg keeping all my messages.
> If everyone has secure chat, then won't that benefit criminal organizations? I struggle to understand the love for private communication when it seems like that would benefit, for example, religious sects and sex abuse rings. NOT that I like that Zuckerborg keeping all my messages.
Yes, sort of.
The thing is, the government is already not permitted to wiretap people, at least without reasonable suspicion.
Wiretaps themselves are not admissible in court, and can only be offered as a mechanism to correlate behaviour anyway. At least in the UK. (Which, is ironic when you consider what's going on there with online speech, but I digress).
Factually speaking, in order to do a crime you have to physically do a crime, the police knowing when and where do not require access to your communications to figure out. They will sting people, get people to turn on other people or simply catch red-handed when doing ordinary police work.
If we legitimately believe what the governments of the world are saying: that we need to embolden the police. Then funding them properly is the right start, yet nobody seems to be doing that. The EU has been making cross border communication easier though, which is in-line with emboldening the police, so I'll give them that.
Having more information will do very little to help, for the same reason that phone taps aren't given out freely (and never have been) - because even if you have the data, you have to choose how to act on it, and you'd need the resources to investigate and follow-through.
There is a distinct irony that unencrypted SMS is more secure than online messengers, because there are legal protections.
Are you European? I don't understand that use of hinder. You mean prevent from using? Then no, I don't think preventing normal people from using encryption will prevent criminals from using encryption, and didn't mean to imply that
> If everyone has secure chat, then won't that benefit criminal organizations?
Probably. But criminal organizations also benefit from having electricity, or cars, or a million other things that we all would be much worse off if we didn't have them. Just because something benefits criminal organizations as a side effect is not really a reason to not do it for the benefit of ordinary citizens.
My point wasn't that we should or shouldn't have it. I just get the impression that the same people calling for privacy will be highly outraged the next time, for example, an Austin Wolf (gay porn 'star' who used Telegram to share thousands of files showing abuse of children) situation arises, or it's inevitably revealed that religious sect xyz coordinated over it. Europeans trash talk Telegram (and that is fine), but somehow Matrix is different? How?
Oh I don't think it's different at all in that respect. I think that many people are very ignorant about the inherent double-edged sword that is freedom, and think that it's possible to deny it to only bad people. On top of that, many people don't particularly value private communications, considering it to be a theoretical issue that doesn't affect them. So yeah there will certainly be outrage in cases like you mentioned.
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.
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?).
> So far matrix is the best attempt in my book, but it's also not there (yet?).
IMO XMPP is the best attempt so far, but it's completely outdated by today's standards. Matrix is a modern attempt, but it's just bad. I doubt that Matrix will actually get anywhere usable in the future.
It's absolutely possible to build such a protocol with high performance, seamless UX, Signal's level of privacy and security, and Discord's level of features. It's just a lot of work to actually build the specifications and flagship implementations, compared to just building a good centralized option.
> Matrix is a modern attempt, but it's just bad. I doubt that Matrix will actually get anywhere usable in the future.
Obviously I’m biased, but I seriously suggest looking at the various vids from the Conference. Matrix has definitely had some ups and downs in the past, but right now it is in a good place.
>I think requirements also changed a lot over the years with smartphones and mobile internet access everywhere.
I recently started using an XMPP client on a smart phone (Cheogram, fork of Conversations). It handles that stuff remarkably well. Switching between, say, mobile data and WiFi takes seconds. It seems to have some way of noticing the loss of connection and immediately fires up a new TCP connection on the new medium.
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:
The vast majority of people using "end to end encrypted" messaging systems fail to verify the identity of their contacts. So those running the servers can fairly trivially MITM the messages. So in practice it does matter who controls the servers.
It's less encrypted. E.g. you'd think that emoji reactions are end-to-end-encrypted (as they are in Signal). But they aren't[1]. I expect similar implementation issues wrt. the encryption in Matrix.
Signal uses a whole suite of modern cryptography, including post-quantum ratchets for key agreement and zero-knowledge proofs for group membership.
Meanwhile, Matrix has a plaintext mode and knowingly shipped libraries with side-channels for years, by their own admission (and left many clients in the ecosystem depending on the vulnerable C implementation when they rewrote their cryptography protocol in Rust).
Even today, they are not the same protocol. Olm/Megolm is distinct from Signal in a lot of ways that I've outlined in my previous blog posts.
I don't particularly care if people like Matrix, but please don't spread falsehoods about the cryptography being used.
The fundamental difference boiling down to trust isn't primarily in the cryptography; it's entirely down to the infrastructure and the root of control.
Signal is widely regarded as the gold standard for centralised E2EE, but its architecture forces you into two massive, non-negotiable trust compromises:
1) You must trust the Signal corporation with all your metadata. Every routing and handshake detail passes through one single choke point that they control. That is an unacceptable risk for security-minded users.
2) You rely completely on Signal to truthfully publish a pre-compiled binary that actually reflects the open-source code. For the vast majority, this is unverifiable in practice. It's a critical client-side act of faith.
Matrix’s design fundamentally eliminates these single points of failure, shifting the root of trust squarely to the user (or a group you trust):
1) Self-hosting; This is the game-changing feature. Host your own Synapse/Dendrite instance. Your metadata never leaves your control. You move the trust boundary from a corporation to yourself. You genuinely achieve "no communication outside your control."
2) Matrix uses an open specification. You can use FluffyChat, Nheko, or Element. This breaks the coupling between the server and the client. Even if you rely on a third-party server, you can use a client built by a completely different team, making the client-side code independently auditable and verifiable across projects. This is the ultimate defence against subtle backdoors in a single vendor's binary.
TL;DR: Signal offers "trusted third-party" crypto running on a single, unauditable binary. Matrix is decentralised, verifiable zero-trust communication. The comparison isn't about the strength of the AES key or which data it has been applied to; it's about the architectural freedom to not have to trust another entity with either your data or your code. That freedom represents an essential leap in trustworthiness.
Super nice summary. Makes me want to use Matrix again, but the clients have all been very poor in my experience. Element on desktop was okay and I used it for work without issue, but it's not nearly as slick as "scan this QR code and import your contacts" (oh that's another difference, your ability to use the network is governed by Signal allowing you to register an account, typically requiring a phone number for bot prevention, which seems like an extreme step for an app that aims to keep you anonymous.)
You might be making good points, I'm not familiar enough with the context to tell, but whining about downvotes is in bad taste, so a large part of your downvotes probably come from there, mine included.
Apologies, it's frustrating watching my comment go from +5 to -2 in a handful of seconds.
Not that I'm into karma farming (or that it even means anything), but it irritates me to think that people are gaming the discourse here.
There's an implicit groupthink when it comes to seeing greyed out comments; to the point that people may (and do) think that the comment is non-factual or at the very least unpopular. This is especially true in subjects that are critical of Signal.
Quoting the guidelines [0], if you think that's really what's happening, you can try reaching out to the mods.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
In theory you can do the same with Signal, as they source dump their server code every now and then.
If you reject that on the basis of "we can't know if it's what they're running" or "it's a partial dump", then I don't see how Matrix is any different. Not only we can't know if Matrix servers have modified software, but we also have to trust/verify several servers instead of a single one.
I apologize if it was mentioned anywhere but has there been any retrospectives on the August security update and v12 room roll out.
The v12 room upgrade in particular seems to be difficult, and still not supported by many of the bridges. Is there a plan to force upgrade all rooms on matrix.org at some point?
User report from 2025: Both the application and web UI are still buggy and slow. This is not acceptable in an application this simple in nature, that has been around for so long.
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.
I use thunderbird for email and they now let you connect to matrix, irc, xmpp, and whatever Odnoklassniki is. It's quite barebones however, like it looks like people are just adding lines to a google doc, barely any interface at all. Really a stylesheet would go along way, looks like userChrome.css works, so maybe I'll mess with that.
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.
Latest Element X Testflight and nightly both crash for me very consistently when navigating back from two or more levels deep (like from Chats > room > room info and then going back). iOS 26.1 beta (23B5064e). I’ve been blaming it on iOS for now since I can’t go back to not running a beta yet :( Also seems like the notification badge is always = real notifications + 1 which i’ve read happens with Synapse or something but I’ve never found a way to fix it.
Also seems like spoiler messages in Element X appear as just an empty chat bubble that i’ve been meaning to report. And why does sending spoilers on Element require using /spoiler when discord and telegram use `||spoilered text||`?
I really want to love Matrix. I’ve been using it with my girlfriend (on a self hosted Synapse server for us) who barely tolerates it, some other friends who range from also tolerating it to hating it (and having decryption errors a lot with a friend who has several clients they switch between, mostly whenever I send a message from another client like when going from element to nheko). I bridge Telegram, Signal, and IRC to matrix (and probably will add more soon). I’m not sure why I care so much about this chat protocol, but I do for some reason and I really want to see it work.
Unfortunately that really does sound like an iOS beta problem - iOS betas are infamously unstable, and effectively used by Apple to hunt crashes that they've introduced when existing apps run.
Hoping there’s a new iOS version soon then so I can get off the beta, has been annoying dealing with crashes but at least element x launches really fast.
Really glad to hear that notification badges are almost fixed! I left an upvote on the spoilers issue but don’t really have anything to add other than it’s annoying to not have a way of even seeing the contents.
Right, thanks for clarifying. Yes, the desktop app isn’t as fast as it should be. On mobile we fixed this with Element X; on desktop we’re in the middle of the transition still. The conf talk on Element X Web is pretty good at explaining where it’s at: https://youtu.be/z0ULOptq2vk?t=240
Edit: also, on macOS on Apple Silicon, you can use Element X on macOS as a desktop app, and it works impressively well.
again, which app are you talking about? it's like saying "the web is buggy" but not saying what browser you're using. Looking at the App Store reviews for Element X at https://apps.apple.com/us/app/element-x-secure-chat-call/id1..., there are no complaints about bugs at all (only missing functionality, which has since been added)?
It's good to see Matrix getting more adoption. I still feel a bit uneasy when so much of it is focused on big institutional deployments, but hopefully that can trickle down to a better experience for average users.
So honest question as I am now looking into matrix as a solution to combine multiple messaging channels. Does it play well with signal/telegram these days or do I need to constantly update various connectors and hope for the best?
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.
Aurora is a big deal! I’ve been waiting for the Rust SDK to come to the web.
I’m not fully through the talk yet, but it looks like they’re first modernizing the old application and planning to eventually switch base to Aurora, which seems sensible!
Either way, Rust SDK on the web, finally! This will hopefully make it easier to write other Matrix clients, since the JS SDK is pretty undocumented (and outdated).
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.
I noticed that they renamed the Element mobile app to Element Classic. Has Element X reached feature parity and stability yet? For how long will Classic be maintained?
> 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.
Good to know! These are very important features and not having them really gets in the way of switching off of classic. I am worried about "intial" support - what is going to break with threads and spaces that I try to join with thr new Element X?
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.
> It's [Element X is]...sluggish...
I regret to concur. On an iPhone PRO MAX with iOS 18.7-latest, my stopwatch says:
And Element X is supposed to be the "fast one", due to Rust SDK, etc. etc.I'm giving Element X etc. the benefit of the doubt and will see them through.
But there NEEDS TO BE a user-advocate or project-manager just wailing on usability internally at Element. If you need such a person, find someone, and if you can't find anyone, hit me up, but I would think someone should be filling this role already.
In addition to bundling and network effects, one magic thing that helped grease the skids for some apps like AOL Instant Messenger or Facebook Messenger (in its glory days) or WhatsApp/Discord/Telegram or whatever gain very wide adoption was their relatively seamless user experience.
As much as the Parent sounds like complaining, I think it's complaining in good faith. We want Matrix to succeed.
Hm. Something sounds wrong here, then. On my iPhone 12 Pro Max on iOS 26, my account (~5000 rooms) opens in about 2s in Element X iOS. On the classic app it’s about 10s (ie unusable).
Roughly how many rooms are you in? and what server is this on (it could be a serverside problem)? And what precise build of the app?
EDIT: Synapse 1.139.0
Element X Version 25.10.0 (190)EDIT: After updating to Element X Version 25.10.1 (192) [latest Update from App Store], about 2 seconds is observed -- still slower than Classic, but a little better than before. I will still finish following up regarding Server issues/info with server admins; hopefully that fixes it.
Thanks a ton for all you do! Good to know it's not the expectation.
This is really surprising. Can you do a clean launch (ie kill the app and relaunch it) and then submit a bug report from both apps and let me know what mxid to look for? (DM to @matthew:matrix.org if needed). The logs will say where the time difference is coming from. EX should always be way faster than classic Element.
After installing and configuring coturn, and then finding out that ElementX requires Element Call instead feels like a "fuck you" from developers.
what guide were you following that told you to install coturn for Element X? It shouldn't be /that/ surprising that Element X's group-capable calling requires a group call server, and in general most people seem happy to not have to worry about coturn given the server acts as a relay.
The instructions are from Synapse docs:
https://element-hq.github.io/synapse/latest/setup/turn/cotur...
Element (not ElementX), the official/preferred app, works with coturn for 1-on-1 calls. But ElementX does not. IMO it is surprising to break 1-on-1 call functionality.
In Matrix 2.0, all calls are group capable (much like Matrix itself doesn’t specialcase DMs - they are just rooms with 2 people). So yes, no coturn is needed.
We haven’t got as far as interop between legacy Matrix 1:1 calling and Matrix 2.0 style MatrixRTC though, which I can see being annoying - but overall the admin burden should be simpler than running a coturn.
We’ll update the synapse docs to explain that coturn isn’t needed for MatrixRTC calls.
Compared to Signal, where does element stand today in terms of privacy and encryption? Due to the decentralized nature they werent able to offer the same guarantees from what I remember
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).
> Matrix allows for unencrypted messages so it's inherently less encrypted than Signal.
But that logic, Matrix is less encrypted than Whatsapp, too, which is a crazy thing to say.
> The federation capability also means messages leak metadata.
It's the opposite: The centralized architecture means that there is a single target server to attack for the metadata. With decentralization, you can't easily scale up your attack to all users.
It's not a crazy thing to say. It's a complicated question.
Somewhat related - Can someone explain this to me? France and Germany want to lessen dependence on American organizations, so they choose Matrix, also an American organization.
Matrix, the organisation, takes care of the open source side of things.
BwMessenger is a partnership with "ELEMENT SOFTWARE SARL" (according to https://messenger.bwi.de/datenschutz), the French entity of the commercial side of the people originally behind the open Matrix ecosystem (https://element.io/legal/company-information). I'm not sure why the French entity is doing business with the Germans as Element also has a German entity, but either way the American side is not the one doing the work.
For the American entity, a lot (most?) of the work that's not from unrelated open source contributors seems to be coming in from either EU countries or the UK.
Thank you, it looks like my assumption was wrong
Matrix isn’t US at all; it’s a UK Non Profit.
Element is also UK headquartered, albeit with French/German/US subsidiaries when selling to those respective governments. BWI buy via France because when we started working with them we didn’t have a German legal entity yet.
It appears to have been started by Americans: https://en.wikipedia.org/wiki/Matrix_(protocol), https://en.wikipedia.org/wiki/Amdocs
Who perhaps chose the UK in an effort to distance themselves from the US
As I said, I see now my assumption was wrong
Signal and any kind of Slack SaaS: US infrastructure, US law around data governance. Matrix (and Zulip, for that matter, and mattermost too) encourage self-hosting on your own infrastructure, or at least in-country, even if the upstream security patches are coming from US developers.
Thank you, that helps me understand it better
Oh, and as everyone has said. Only some of the developers are from the US
If it's open source (and libre software) then it's not as important where the main development offices are (or where the company is incorporated). You still have control.
Seems like the majority of the team are in the EU anyway: https://matrix.org/foundation/about/
Thank you, and I see it's registered in the UK. I think it started in the US? Well, not like it's relevant anymore. And can you answer this question: If everyone has secure chat, then won't that benefit criminal organizations? I struggle to understand the love for private communication when it seems like that would benefit, for example, religious sects and sex abuse rings. NOT that I like that Zuckerborg keeping all my messages.
> If everyone has secure chat, then won't that benefit criminal organizations? I struggle to understand the love for private communication when it seems like that would benefit, for example, religious sects and sex abuse rings. NOT that I like that Zuckerborg keeping all my messages.
Yes, sort of.
The thing is, the government is already not permitted to wiretap people, at least without reasonable suspicion.
Wiretaps themselves are not admissible in court, and can only be offered as a mechanism to correlate behaviour anyway. At least in the UK. (Which, is ironic when you consider what's going on there with online speech, but I digress).
Factually speaking, in order to do a crime you have to physically do a crime, the police knowing when and where do not require access to your communications to figure out. They will sting people, get people to turn on other people or simply catch red-handed when doing ordinary police work.
If we legitimately believe what the governments of the world are saying: that we need to embolden the police. Then funding them properly is the right start, yet nobody seems to be doing that. The EU has been making cross border communication easier though, which is in-line with emboldening the police, so I'll give them that.
Having more information will do very little to help, for the same reason that phone taps aren't given out freely (and never have been) - because even if you have the data, you have to choose how to act on it, and you'd need the resources to investigate and follow-through.
There is a distinct irony that unencrypted SMS is more secure than online messengers, because there are legal protections.
Funding police outweighs the benefit organized crime may get from communicating securely ?
So you think that if normal people aren't allowed to use encryption that would hinder organized crime to use encryption? :-0
Are you European? I don't understand that use of hinder. You mean prevent from using? Then no, I don't think preventing normal people from using encryption will prevent criminals from using encryption, and didn't mean to imply that
I'm not referring to hinder meaning prevent, I'm referring to how "hinder someone to use" is not grammatical. https://www.merriam-webster.com/sentences/hinder
To "hinder" means to make it more difficult to use something, or "to restrict" or "to prevent" someone from using it.
https://www.merriam-webster.com/thesaurus/hinder
Very much so.
> If everyone has secure chat, then won't that benefit criminal organizations?
Probably. But criminal organizations also benefit from having electricity, or cars, or a million other things that we all would be much worse off if we didn't have them. Just because something benefits criminal organizations as a side effect is not really a reason to not do it for the benefit of ordinary citizens.
My point wasn't that we should or shouldn't have it. I just get the impression that the same people calling for privacy will be highly outraged the next time, for example, an Austin Wolf (gay porn 'star' who used Telegram to share thousands of files showing abuse of children) situation arises, or it's inevitably revealed that religious sect xyz coordinated over it. Europeans trash talk Telegram (and that is fine), but somehow Matrix is different? How?
Oh I don't think it's different at all in that respect. I think that many people are very ignorant about the inherent double-edged sword that is freedom, and think that it's possible to deny it to only bad people. On top of that, many people don't particularly value private communications, considering it to be a theoretical issue that doesn't affect them. So yeah there will certainly be outrage in cases like you mentioned.
Freedoms tend to also benefit criminals, yes. That's kind of unavoidable.
Then crime will increase
See also: https://support.torproject.org/abuse/#abuse_what-about-crimi...
the Matrix foundation is a UK company.
so what? all the specification and all the code is open.
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.
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?).
> So far matrix is the best attempt in my book, but it's also not there (yet?).
IMO XMPP is the best attempt so far, but it's completely outdated by today's standards. Matrix is a modern attempt, but it's just bad. I doubt that Matrix will actually get anywhere usable in the future.
It's absolutely possible to build such a protocol with high performance, seamless UX, Signal's level of privacy and security, and Discord's level of features. It's just a lot of work to actually build the specifications and flagship implementations, compared to just building a good centralized option.
> Matrix is a modern attempt, but it's just bad. I doubt that Matrix will actually get anywhere usable in the future.
Obviously I’m biased, but I seriously suggest looking at the various vids from the Conference. Matrix has definitely had some ups and downs in the past, but right now it is in a good place.
On XMPP, I agree. I think requirements also changed a lot over the years with smartphones and mobile internet access everywhere.
And yeah it's definitely possible, but it's a lot of work, both technically and from an organizational perspective (funding, governance, etc).
>I think requirements also changed a lot over the years with smartphones and mobile internet access everywhere.
I recently started using an XMPP client on a smart phone (Cheogram, fork of Conversations). It handles that stuff remarkably well. Switching between, say, mobile data and WiFi takes seconds. It seems to have some way of noticing the loss of connection and immediately fires up a new TCP connection on the new medium.
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
If the open source client encryption is good enough, it shouldn't matter if the CIA itself is openly running the centralized portion of Signal.
The vast majority of people using "end to end encrypted" messaging systems fail to verify the identity of their contacts. So those running the servers can fairly trivially MITM the messages. So in practice it does matter who controls the servers.
I'm not an expert, but it doesn't look so simple:
https://news.ycombinator.com/item?id=39421128
https://news.ycombinator.com/item?id=39445976
It's exactly the same encryption tech, but a bit more trustworthy than signal.
It's less encrypted. E.g. you'd think that emoji reactions are end-to-end-encrypted (as they are in Signal). But they aren't[1]. I expect similar implementation issues wrt. the encryption in Matrix.
[1]: https://github.com/matrix-org/matrix-spec/issues/660
This is factually incorrect.
https://soatok.blog/2025/02/18/reviewing-the-cryptography-us...
https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
Signal uses a whole suite of modern cryptography, including post-quantum ratchets for key agreement and zero-knowledge proofs for group membership.
Meanwhile, Matrix has a plaintext mode and knowingly shipped libraries with side-channels for years, by their own admission (and left many clients in the ecosystem depending on the vulnerable C implementation when they rewrote their cryptography protocol in Rust).
Even today, they are not the same protocol. Olm/Megolm is distinct from Signal in a lot of ways that I've outlined in my previous blog posts.
I don't particularly care if people like Matrix, but please don't spread falsehoods about the cryptography being used.
can you expand on how its more trustworthy than signal?
The fundamental difference boiling down to trust isn't primarily in the cryptography; it's entirely down to the infrastructure and the root of control.
Signal is widely regarded as the gold standard for centralised E2EE, but its architecture forces you into two massive, non-negotiable trust compromises:
1) You must trust the Signal corporation with all your metadata. Every routing and handshake detail passes through one single choke point that they control. That is an unacceptable risk for security-minded users.
2) You rely completely on Signal to truthfully publish a pre-compiled binary that actually reflects the open-source code. For the vast majority, this is unverifiable in practice. It's a critical client-side act of faith.
Matrix’s design fundamentally eliminates these single points of failure, shifting the root of trust squarely to the user (or a group you trust):
1) Self-hosting; This is the game-changing feature. Host your own Synapse/Dendrite instance. Your metadata never leaves your control. You move the trust boundary from a corporation to yourself. You genuinely achieve "no communication outside your control."
2) Matrix uses an open specification. You can use FluffyChat, Nheko, or Element. This breaks the coupling between the server and the client. Even if you rely on a third-party server, you can use a client built by a completely different team, making the client-side code independently auditable and verifiable across projects. This is the ultimate defence against subtle backdoors in a single vendor's binary.
TL;DR: Signal offers "trusted third-party" crypto running on a single, unauditable binary. Matrix is decentralised, verifiable zero-trust communication. The comparison isn't about the strength of the AES key or which data it has been applied to; it's about the architectural freedom to not have to trust another entity with either your data or your code. That freedom represents an essential leap in trustworthiness.
Super nice summary. Makes me want to use Matrix again, but the clients have all been very poor in my experience. Element on desktop was okay and I used it for work without issue, but it's not nearly as slick as "scan this QR code and import your contacts" (oh that's another difference, your ability to use the network is governed by Signal allowing you to register an account, typically requiring a phone number for bot prevention, which seems like an extreme step for an app that aims to keep you anonymous.)
You might be making good points, I'm not familiar enough with the context to tell, but whining about downvotes is in bad taste, so a large part of your downvotes probably come from there, mine included.
Apologies, it's frustrating watching my comment go from +5 to -2 in a handful of seconds.
Not that I'm into karma farming (or that it even means anything), but it irritates me to think that people are gaming the discourse here.
There's an implicit groupthink when it comes to seeing greyed out comments; to the point that people may (and do) think that the comment is non-factual or at the very least unpopular. This is especially true in subjects that are critical of Signal.
Unfortunately, many people work this way: "I don't like this, therefore it's false"
There's eight billion something humans on the planet, I think it's pretty okay if seven of them disagree with what you're saying.
Yeah.
Just weird that they all found my comment at the same time.
.. and it happens, every time, a slow build up of points, maybe some ups and downs, then suddenly it falls off a cliff. It's.. it's too perfect.
Quoting the guidelines [0], if you think that's really what's happening, you can try reaching out to the mods.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
[0] https://news.ycombinator.com/newsguidelines.html
You can validate the code that's running on the client and the server, in theory
You can validate the code running on the client (well, not on iOS, but that's true for all iOS apps unless you've jailbroken your phone).
If Signal works well, you shouldn't need to validate what code is running on the server in the first place.
In theory you can do the same with Signal, as they source dump their server code every now and then.
If you reject that on the basis of "we can't know if it's what they're running" or "it's a partial dump", then I don't see how Matrix is any different. Not only we can't know if Matrix servers have modified software, but we also have to trust/verify several servers instead of a single one.
I apologize if it was mentioned anywhere but has there been any retrospectives on the August security update and v12 room roll out.
The v12 room upgrade in particular seems to be difficult, and still not supported by many of the bridges. Is there a plan to force upgrade all rooms on matrix.org at some point?
User report from 2025: Both the application and web UI are still buggy and slow. This is not acceptable in an application this simple in nature, that has been around for so long.
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.
I use thunderbird for email and they now let you connect to matrix, irc, xmpp, and whatever Odnoklassniki is. It's quite barebones however, like it looks like people are just adding lines to a google doc, barely any interface at all. Really a stylesheet would go along way, looks like userChrome.css works, so maybe I'll mess with that.
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.
Latest Element X Testflight and nightly both crash for me very consistently when navigating back from two or more levels deep (like from Chats > room > room info and then going back). iOS 26.1 beta (23B5064e). I’ve been blaming it on iOS for now since I can’t go back to not running a beta yet :( Also seems like the notification badge is always = real notifications + 1 which i’ve read happens with Synapse or something but I’ve never found a way to fix it.
Also seems like spoiler messages in Element X appear as just an empty chat bubble that i’ve been meaning to report. And why does sending spoilers on Element require using /spoiler when discord and telegram use `||spoilered text||`?
I really want to love Matrix. I’ve been using it with my girlfriend (on a self hosted Synapse server for us) who barely tolerates it, some other friends who range from also tolerating it to hating it (and having decryption errors a lot with a friend who has several clients they switch between, mostly whenever I send a message from another client like when going from element to nheko). I bridge Telegram, Signal, and IRC to matrix (and probably will add more soon). I’m not sure why I care so much about this chat protocol, but I do for some reason and I really want to see it work.
Unfortunately that really does sound like an iOS beta problem - iOS betas are infamously unstable, and effectively used by Apple to hunt crashes that they've introduced when existing apps run.
The notification badge issue is this mess: https://github.com/element-hq/element-x-ios/issues/3151 and is almost solved (but not deployed yet).
Spoilers is https://github.com/element-hq/element-x-ios/issues/2839 but isn't really on our radar - please can you upvote / comment on it.
Thanks for keeping the faith :)
Hoping there’s a new iOS version soon then so I can get off the beta, has been annoying dealing with crashes but at least element x launches really fast.
Really glad to hear that notification badges are almost fixed! I left an upvote on the spoilers issue but don’t really have anything to add other than it’s annoying to not have a way of even seeing the contents.
Hi! I'm referring to the one on element.io/download marked "Desktop" I haven't tried element.x. Seems to be phone only?
Right, thanks for clarifying. Yes, the desktop app isn’t as fast as it should be. On mobile we fixed this with Element X; on desktop we’re in the middle of the transition still. The conf talk on Element X Web is pretty good at explaining where it’s at: https://youtu.be/z0ULOptq2vk?t=240
Edit: also, on macOS on Apple Silicon, you can use Element X on macOS as a desktop app, and it works impressively well.
For Desktop, use nheko as the client app. It's lightning fast.
It's not buggy? You should try going to the app store(s) and looking at reviews.
again, which app are you talking about? it's like saying "the web is buggy" but not saying what browser you're using. Looking at the App Store reviews for Element X at https://apps.apple.com/us/app/element-x-secure-chat-call/id1..., there are no complaints about bugs at all (only missing functionality, which has since been added)?
Brother, look at reviews for element x for android on play store. Come on, you're being intentionally obtuse.
It's good to see Matrix getting more adoption. I still feel a bit uneasy when so much of it is focused on big institutional deployments, but hopefully that can trickle down to a better experience for average users.
So honest question as I am now looking into matrix as a solution to combine multiple messaging channels. Does it play well with signal/telegram these days or do I need to constantly update various connectors and hope for the best?
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.