Matrix Conference 2025 Highlights
element.io
element.io
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.
Not that many clients have actually adopted it though, because the MSC is still not 100% finalised - it's currently entering the final review stages at last now over at https://github.com/matrix-org/matrix-spec-proposals/pull/418.... Right now Element X uses it (exclusively), and Element Web has experimental support for it; I'm not sure if any others actually use it yet.
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.
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.
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.
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.
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.
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?
> how many rooms are you in?
> and what server is this on (it could be a serverside problem)?
EDIT: Synapse 1.139.0
> And what precise build of the app?
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.
I think we're getting closer.
Your "good experience" on Element X iOS matches my "bad experience" on Element X iOS.
See, with my Server and Chats, Classic is actually very snappy:
- Element X: ~1.5 seconds avg (rounds to 2 sec if using a non-decimal stopwatch, but more like 1.5 when measured more precisely)
- Element Classic: ~0.6 second avg (actually slightly faster visually, this includes my response time to stop the timer, probably more like just around/under 0.5 sec)
But X loads in 2-3 times the time. I sit there waiting for content to load, even if it's just for a second.
Is this the best Issue to watch?: https://github.com/element-hq/element-x-ios/issues/4102
Because I really hope speed does not regress for people already with very fast load times in Classic, when X becomes the only flagship App in the App Store.
So, I'll try to come back here and comment if I get it resolved.
If Signal works well, you shouldn't need to validate what code is running on the server in the first place.
on the signal.org website, there is a direct download link right below the google play button.
it's still just a binary, but you can control updates. incidentally i just did an update this way.
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.
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.
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.
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.
> 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.
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.
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?).
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.
And yeah it's definitely possible, but it's a lot of work, both technically and from an organizational perspective (funding, governance, etc).
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.
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 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).
Seems like the majority of the team are in the EU anyway: https://matrix.org/foundation/about/
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.
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
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.
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.
Who perhaps chose the UK in an effort to distance themselves from the US
As I said, I see now my assumption was wrong
- Neither 'Hodgson' or 'Le Pape' sound Israeli
- Likely they went to American universities
etc
here is discussion about start of matrix: https://news.ycombinator.com/item?id=45495134
Oh, and as everyone has said. Only some of the developers are from the US
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.
From a protocol perspective, it is. Without an open-source WhatsApp client and independent protocol security analysis, it's hard to judge the effectiveness of the encryption, of course.
> means that there is a single target server to attack for the metadata
Signal does not collect or provide much metadata. It has IP:port mappings, for sure, and keeps track of when a user last checked in, but the protocol itself is extremely well-suited to resist analysis.
A lot of information Matrix provides you for "free" once you break the HTTPS tunnel needs advanced analysis to get it out of Signal. Signal's protocol security is really impressive, I don't think there's anything comparable out there.
Matrix does not even encrypt emoji reactions.
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’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).
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.
Edit: also, on macOS on Apple Silicon, you can use Element X on macOS as a desktop app, and it works impressively well.
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.
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 :)
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.
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.
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?
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 appservice-irc bridge has this issue which is more of a question: https://github.com/matrix-org/matrix-appservice-irc/issues/1... which hasn't been answered.
These are keeping our space on an earlier version.
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.
And most importantly, is there a completely new approach that Element / Matrix can bring to messaging that doesn't feel like it's replacing something?