From April 2026, only verified devices can send or receive end-to-end encrypted message on Element.
Act now: continue sending & receiving encrypted messages
In April 2026, we will be rolling out a significant update to strengthen the security of your conversations: unverified devices will no longer be able to send and receive end-to-end encrypted messages via Element. This change follows the Matrix specification update that was announced at the Matrix 2025 conference on October, 17 and benefits everyone by enhancing security, but may require an action from you to continue sending & receiving encrypted messages on your existing devices.
This security update will give you assurance that when you receive a message from a contact, you can effortlessly assume it’s really from them.
It’s a big step towards making Element an even more safe and reliable messaging experience. We mean it when we say that we want to provide the most secure communication technology in the world.
So here’s what’s changing and why it matters to you.
Unverified devices are a potential attack vector
Imagine you’re messaging a colleague and suddenly a warning shield icon appears on your screen. Is this just a harmless unverified device and you can safely ignore the warning, or has someone’s account been compromised? At best this is a distraction and, at worst, it is someone malicious trying to impersonate one of your contacts - neither is ideal. What’s worse is that ignoring these warnings leaves unmitigated risks to proliferate throughout your network.
With Element, trust is critical - a non-negotiable. For example, we provide end-to-end encryption by default to all of our users to ensure that you and the person you're messaging - and only the person you're messaging - can read the messages. This forthcoming change aims to eliminate uncertainty and the likelihood of malicious activity by requiring all devices to be verified.
Device verification matters
Device verification acts like a hand shake between your devices, proving cryptographically to your contacts that they belong to you. Without this verification step, messages sent from your new devices must be marked as untrusted in your conversations. By making verification mandatory, users can be confident in every message sent and received via Element and are not distracted by warnings about insecure devices.
Trust by design and default
Going forward devices will be either verified or unable to participate in conversations - it’s that simple. No more warning or shield icons that can be easily ignored, these ultimately undermine the impact of important warnings/notifications (users become desensitised).
By verifying your devices, you’re not just protecting your own communications, you’re creating a more trusted environment for everyone.
We’re designing a system that prioritises the security of your communications and making verification an integral part of the process is a great example of that.
If you’re already in the habit of verifying your devices and have your recovery key set up there’s nothing you need to do to prepare, you’re good to go.
For everyone else, now is the time to take action:
- Check if your existing devices - mobile, web or desktop - are verified.
- Set up recovery if you haven’t done that already.
Note: although setting up recovery is strictly not mandatory, it is highly recommended, as it simplifies the verification of new devices, and enables you to do that even when you lose all of your current devices.
For the details of how to do this on various platforms, please read more in the user documentation.
What if you don’t verify…?
From April 2026:
- Unverified devices will no longer be able to send messages.
- Content of the messages received from unverified devices will not be shown (you can still see that there was a message).
In short, unverified devices will effectively become unusable in end-to-end encrypted (E2EE) conversations. You’ll still be able to participate in conversations where E2EE has been deactivated, but in all other circumstances you will be excluded.
Building trust together
As stated above, trust is fundamental to secure communication. By requiring verified devices, we are raising the bar for what users can expect from your secure communication. This is a small change that makes a big difference. We have to work together with our users to ensure success. We’re doing this work to ensure every message you send and receive is as trustworthy as a face-to-face conversation.
We’re here to make the transition as smooth as possible. If you have questions or need help, our support team is ready to assist. Together, let’s make digital communication as secure as possible for everyone.
Read the original article
Comments
By unbolted3032 2025-11-202:1311 reply I decommissioned my server 3 months ago and migrated my community back to IRC. I still had the IRC Podman containers kicking around, so that was easy.
I dealt with ~monthly issues around my devices not being correctly verified, messages not correctly decrypting, and various other rough UX edges. There seemed to be a lot of velocity in the beginning but the last couple of years have addressed approximately nothing in terms of the UX and it's a crying shame as Matrix/Element (I no longer fully understand the difference/relationship between these entities) had a lot of potential.
Let's not forget the shock image spam issue. Public Matrix channels are plagued with horrendous shock images (including CSAM). The development team seems to not care, they have a proposal for "policy servers" which is still incomplete and not supported by all server implementations.
Let's not forget a team making a great free product. Yeah we can complain about filthy materials but imagine you working hard to build something as nice as Matrix/Element only for these low-lifes to do these horrible things to it. How annoying it must be to have to spend time battling such things.
> Let's not forget a team making a great free product.
I am fully appreciative of the work that goes into making a product like this, but I’m also tired of this mentality that nobody is allowed to talk about the problems with the product. Even simple comments from people who tried to use the product but encountered show-stopping issues are getting downvoted into gray text in this thread.
This mentality that we must only speak praise and cannot speak of problems because a product is free is further off putting. I’ve given Matrix/Element an honest try many times because some of the OSS projects I’m involved with use it, but month after month it’s the most troublesome of all of the apps in this space that I use, and it’s not even close. If I’ve gone a month without dealing with Matrix and I have to open it again it feels like there’s a 50:50 chance something is going to either be inexplicably broken or cause problems even though I thought I finally had it all working last time.
The contrast between how hard we’re told that Matrix is the great and superior option and the reality of what it’s like to use it as a casual or occasional user is really wearing me out on the project.
By eredengrin 2025-11-2017:06 > I’m also tired of this mentality that nobody is allowed to talk about the problems with the product
I think there's a pretty big difference between constructive criticism vs statements like "The development team seems to not care". To me, it seems pretty clear that the team absolutely cares, but they are also a small and very underfunded team, and things take time. Assuming the worst intentions of a team is the problem and is disappointing to see here.
> I’ve given Matrix/Element an honest try many times because some of the OSS projects I’m involved with use it, but month after month it’s the most troublesome of all of the apps in this space that I use, and it’s not even close.
I don't doubt that, but it does not resonate with me. There have been a few hiccups over the years, eg the database corruption earlier this year (unrelated to the protocol or synapse) resulting in stuck invites, but overall I've had quite a good experience. Far less problems than Teams, and even slack has had issues (mainly, notifications not happening) that I have somehow avoided with Element, although I am aware others have had issues in this area. There are even some things I do with matrix that are simply not possible/practical with the others to begin with.
It is super annoying but you have to be very naive to not understand that anything that can be abused will be abused so you need to bake in countermeasures from day #1 or you might as well not bother with the launch.
Aren't there any moderators in those channels? I have 0 issues in the channels I am in (some podcasting channels, some tech, some FOSDEM.)
I find a lot of value in Element as is, I'm glad they bothered.
By Saris 2025-11-2220:23 A lot of the spam I got was from being sent room invites, and the room names were really nasty stuff. And their client doesnt let you mass delete invites, I tried to do it one at a time but gave up and deleted the account instead.
Their server clearly doesnt care that a single federated server was sending out thousands of invites, and there's no way to avoid the spam.
In general using matrix was always a pain in the rear for one reason or another.
By tcfhgj 2025-11-2010:16 with that strategy you won't launch ever if you have limited budget, especially because Matrix isn't exactly a system/protocol off the self
By wkat4242 2025-11-2018:19 It's free for us but not for businesses. I think this is why they are ruining the UX, because they're adapting it to their target market, like making it more like MS Teams.
By gmerc 2025-11-2015:48 A product as unsuitable for the adversarial internet as ChatGPT and coding agents
If you make anything public, you will have to deal with it. You should be mentally prepared for that from the start.
By kldg 2025-11-2021:18 in defense of this comment, you do need to do a heck of a lot of preparation (including psychologically) to do anything publicly anymore. wild west days are long gone, at least for US-based servers. I spend a lot of time thinking about how to stop users from interacting too freely, to censor and moderate them so I don't wind up on some news site in 20 years being accused of hosting a site *Widely Used* by pedophilic narcoterror jihadists; I would like to not, but user content (and especially their information) is a huge liability to host... unless you're Equifax or Facebook or Google or some other large corporation -- then you can accidentally dump out everyone's sensitive financial information and only pay them $9 in compensation (or whatever the amount was; I keep throwing the cards they send me in the trash).
(yes I'm salty about that still)
By johnisgood 2025-11-209:002 reply I mean I could just as easily say you as an user should be mentally prepared.
Matrix is developing a privacy IM, you do not really moderate that now, do you? Leave the rooms that raise your cortisol level.
Wait a minute, doesn't receiving child porn even if unintentionally like the situation above open up the receiver to legal liability?
It isn't reasonable to expect users to be 'mentally prepared' to have their devices download child porn because they visited a chat room for support about the chat app they're using.
By johnisgood 2025-11-2013:284 reply As someone else have said, then that is an issue with the law.
Imagine someone sending you a link that you open and then now you have child porn or whatever else on your hard drive, cached. Quite a shitty situation to be in.
Perhaps avoid non-technical rooms or rooms in which you do not trust people.
"Imagine someone sending you a link that you open and then now you have child porn or whatever else on your hard drive, cached. Quite a shitty situation to be in."
I guess the correct legal approach would be to go to police with this.
And the correct technical approach to keep online spaces clean, is the ability to kick, mute or ban people who violate the rules.
Saying, "just be mentally prepared" sounds to me like accepting it. Well, I don't. I go somewhere else.
By johnisgood 2025-11-2015:471 reply I did not use the term "mentally prepared" because I thought it was appropriate, I was just quoting the other guy. I find it silly, too. I will not "accept" child porn or other degeneracies.
> Saying, "just be mentally prepared" sounds to me like accepting it. Well, I don't. I go somewhere else.
Exactly! You should be going somewhere else. Another Matrix instance, or at the very least another room, and you will be fine.
"You should be going somewhere else. Another Matrix instance, or at the very least another room, and you will be fine."
Well, but I never decided to hang around for longer. Maybe it is because the moderation tools are simply lacking? I would miss the option of not restricting certain users to send pictures in a group.
By johnisgood 2025-11-2017:141 reply I am not sure if it is currently possible in Matrix, but it is not a bad idea to be able to restrict sending pictures (among other things), I agree.
By lukan 2025-11-2017:35 I just read some complaints with links in sibling comments and sadly no, not possible. Maybe even hard to implement, because of the protocol.
And then imagine you have windows with recall enabled (that you repeatedly disabled but keeps enabling after updates), and/or cloud backup with automatic CSAM detection. You're screwed
By johnisgood 2025-11-2014:41 Yes, and we are screwed either way if we use Windows with Recall, or even in general.
I would not consider Windows secure at all, and it seems futile to use a privacy-oriented IM on Windows, it really defeats the purpose.
Imagine using Windows with Recall enabled that takes screenshots of your conversations all the time. You can be using the most effective IM for privacy but it would not help.
So what is the moral of the story? We have shitty laws, and you should not use Windows. :P
By jasonvorhe 2025-11-211:42 I don't know. I've read of this alleged nightmare scenario in hundreds of forum posts, mailing lists and threads and it's not something that's actually being followed up on in any capacity. The opposite is the case in that law enforcement doesn't have the resources to get as many perpetrators as they would like to. They're not going to raid your home because you idled in a channel that got spammed or because you received and email or because some service you hosted briefly cached a csam jpg on disk. If you've made political enemies and are under observation already than perhaps this might work as a way in but even then it would be easier to just do something illegal and construct the evidence to point to another cause.
I mean, when does this actually end up with consequences for anyone? Even on managed and surveilled company devices I'm not expecting this to cause any harm to anyone involved. IT staff at previous employers and clients had other things to worry about.
Maybe I'm just not familiar with some legal jurisdictions or cases where this was a cause of concern. Let me know.
By Teever 2025-11-221:48 The issue with the law could be rectified and I'd still be in a scenario where I'm exposed to hideous child pornography when I wake up and check my phone messages with bleary eyes because I'm a member of an official support channel for Matrix.
This is unacceptable.
By tcfhgj 2025-11-2013:13 I'd blame the law if it does.
> I mean I could just as easily say you as an user should be mentally prepared.
Users tend to be less aware of these things than the operators of such servers (or at least, that's how it should be).
> Matrix is developing a privacy IM, you do not really moderate that now, do you?
No, but you can create mechanisms for the users to flag problematic accounts.
> Leave the rooms that raise your cortisol level.
The filth will follow the users. That's the whole game plan here: to cause grief.
By johnisgood 2025-11-2010:10 I have been in many rooms that are completely fine; technical rooms.
As for flagging problematic accounts: how would that work in a decentralized E2EE system, and do you think it cannot be abused? What would you want them to do if I flag your account a million times? Keep in mind they probably may not be able to keep up with it, nor do I expect them to. Additionally, you still should be able to use the service due to its decentralized, privacy-preserving nature, so the worst thing that may happen is getting banned from a Matrix instance, or a room.
By jasonvorhe 2025-11-211:33 It's not just their servers, it's the architecture, the difficulties in self hosting, the meh origins of protocol, the resource hogging official clients, multiple implementations with differing protocol support. It's just a mess and I've given up on it this year.
It's kind of wild to me that they haven't prioritized this more. This issue has been open for almost exactly 6 years: https://github.com/matrix-org/matrix-spec/issues/565 . This one even longer: https://github.com/matrix-org/matrix-spec/issues/836 . The Matrix permission system still doesn't even have a way to say "sending images is not allowed" (either per room or per user).
building a more flexible solution for blocking content, rather than hardcoded rules like "no images": https://matrix.org/blog/2025/04/introducing-policy-servers/
By Teever 2025-11-211:15 Is there something fundamental to the matrix architecture and permissions system that makes it impossible or difficult to allow room/server operators the ability to limit certain users from posting multimedia content?
By tcfhgj 2025-11-2016:08 having a usable technical foundation, staying financially afloat
By joecool1029 2025-11-204:552 reply It’s terrible. I had to leave most channels on the matrix.org namespace because they won’t properly moderate their own server from CSAM. I dropped to 7 day media retention to lower legal liability on my own server, since there’s no way to know when one of my users will be in a channel hit with abuse.
At this point the majority use case I have for matrix is to bridge to IRC with heisenbridge and be able to use signal on my laptop through mautrix-signal and nheko. The number of native channels I’m in continues to shrink.
By mystraline 2025-11-2017:06 I know the matrix honeserver I use has taken our recommendations to NOT cache images from matrix.org due to their non-existent moderation. And the admin put out a bulletin to also recommend disable downloading images as well.
There's also the split room bug (feature?) that allows banned users to still be in rooms where the honeserver doesnt ban them. And then, distributes connection shows ongoing banned content (primarily, you guessed it, CSAM) and the better-moderating admins can't do anything about it.
I'm basically in a few well moderated rooms (Gnuradio, other topics). They do extraordinarily well in not getting many trolls, and for garbage collection.
The only one we're seeing spammed is for some cryptocurrency site Liquid something. But its just commercial spam.
By indolering 2025-11-206:551 reply Have they done anything to mitigate this? Like client side filters or message scanning for new direct messages?
The main things are https://matrix.org/blog/2025/04/introducing-policy-servers/ (for flexible serverside moderation) and the rest of the stuff in https://matrix.org/blog/2025/02/building-a-safer-matrix/. Clientside filters already existed, but given they only apply per client and there are a lot of different clients, we focused on serverside filtering.
By BrenBarn 2025-11-216:28 What are the plans to improve the moderation experience for room admins who do not run their own server (of any kind)?
Considering the thread context I'm curious how would IRC help with that other than people running command line or TUI clients?
Also do you want the development team to moderate self hosted chat servers? How would that work?
By Macha 2025-11-2016:22 Must irc clients do not automatically download or show images which means joining a room and spamming a bunch of them is less impactful on recipients and so less appealing to trolls, so it doesn’t happen.
By Saris 2025-11-2220:19 The image spam I got was on their official server.
By j-krieger 2025-11-2110:03 I still can not blacklist homeservers by domain instead of ever changing IPs. Great stuff.
By tcfhgj 2025-11-2010:13 policy servers show that they indeed do care
You did better than I did. I installed the recommended Element app, created an account on matrix.org, tried to send a message to another user, and… gave up. Every try got stuck and eventually created an empty room or whatever they call it. I have literally never succeeded in sending or receiving a single message.
There really is no winning in the org comms/chat apps space when it comes to OSS. Matrix+element, rocket, mattermost, Zulip and so on.. feels like there’s either massive gotchas on free/self hosted or it’s wildly complicated to configure and set up. I’ve been thinking about this a lot. Hosting a private irc server and you lose out on rich embeds and will need your own pastebin-like service to use, video conferencing is probably a big challenge, the need for a mobile app at many workplaces. Bleh. I look at something like slack and I’m like damn that is literally irc+ and I just hate that I don’t have the skills to build up something completely free that I could host at my org. Teams literally owned everyone when they started bundling it in and rug pulling slack. Ofc the execs at my workplace were like “hell yeah this is great” but so did my IT dept. I was so pissed. Out of the box it’s just instantly compliant which was a major driver then of course at the time it was seen as a free offering (I know they’ve since had to decouple that) which completely nuked slack at our org. I can’t even believe I’m saying this but teams actually makes collaborating slower. No one on my team uses the channels we all pin chat groups and exclusively use that. It’s literally garbage. I guess I’m just venting, I really hoped I could find something in the oss world to supplant this and I think the bar for organizations is: compliance, chat, video conf and sigh the ability to schedule in outlook.
What do you see as the gotchas with Zulip for community use? Zulip is 100% open-source, and we sponsor our hosted services (mobile notifications, etc.) free for OSS projects.
Hi ! So zulip is actually probably top of this list as the best self managed solution and I’m sorry if I conveyed that it was even near the same ballpark of some of the others. I actually think it’s pretty neat. Interestingly the thing that made us spin down our zulip instance after ten minutes was the “async conversations”. I understand this is a core differentiator for zulip but it immediately felt like the teams channel threading which none of us can stand. The intentions are noble, and the implementation is way better than teams, but it’s interesting to me that solutioning for preventing things from getting buried became the core UX philosophy at play. Really there is something that just works with an absolutely straight forward chronological list of chat messages used in conjunction with a capable search indexer. It’s not that we aren’t willing to try new paradigms, we have tried this paradigm. For a while now. Our topic’d channels are a ghost town these days, our entire org has just moved to making group chats in teams that serve as channels and pinning them because it’s just way easier to work together with regular chat. Ironically we fail to respond to things and struggle more to find things in a topic/threaded paradigm as it seems to go a little too far in isolating “noise”. A lot of serendipitous participation and aha moments and memes come from just glancing a chat discussion that might not immediately involve your attention, and we just operate way better in the open chat space needing only channels/members for the right amount of organization.
By MatthiasPortzel 2025-11-2115:101 reply I also found the Zulip UX to be really confusing at first. The issue is messages show up in multiple places which is unintuitive for someone with a spacial brain like me. What I do (because I use Zulip every day) is read messages only in their threads. I click on one thread in the sidebar, get caught up, then move to the next thread. (This is also how I use Discord and Slack.) So I treat it as if channels contain threads which contain messages.
But Zulip’s default view is a list of all messages in all threads in all channels which has no context for the individual messages, like
By alya 2025-11-2116:34 Zulip's product lead here. Yep, reading messages thread by thread is the recommended way for most folks. (There's even a keyboard shortcut for going to the next one.) The inbox view, which lists the threads where you have unread messages, is the default home view (unless your org admins changed that setting).
The combined feed is helpful for some (e.g., in lower-traffic organizations, or if you like to see messages as they come in), and was the default home view many years ago.
By trueno 2025-11-2021:32 Great question! Next question please.
(I have no idea that’s the BS I was told when we left slack for teams)
By BrenBarn 2025-11-203:59 I feel they underestimated what the MVP really is and started touting Matrix as great before it was really there, which has backfired and led to disappointment. They also went a bit too overboard on the overgeneralized idea of it being "a decentralized eventually consistent JSON database", which led to a lack of focus on its concrete usability as a chat system. I still use it and it's not bad in some respects, but it's a long, long way away from being able to attract a mass of ordinary users.
If IRC suffices for your purposes, then Matrix, with its encryption and all, is apparently overkill.
If I were to upgrade an IRC-based community to something newer and richer, I'd go with Jabber, well-known, well-established, with a ton of various clients and several servers. Yes, it's not ideal, but it's still a massive upgrade compared to IRC, if your server supports a good list XEPs and your community members agree to use non-esoteric clients that also support them.
By ErroneousBosh 2025-11-208:291 reply > If IRC suffices for your purposes, then Matrix, with its encryption and all, is apparently overkill.
IRC has encryption too. You run it over TLS.
For E2EE there is the very old unofficial and only-partially-secure extension of using Blowfish with a static key.
By ErroneousBosh 2025-11-2010:111 reply I guess it's not end-to-end, it's decrypted on the server.
Presumably if you want to send an encrypted message from one literal endpoint to another, you'd use some other technology. I'm prepared to bet there are enough people doing just that, too.
By immibis 2025-11-2013:54 The extension I just mentioned is E2EE.
By OberstKrueger 2025-11-202:46 Unfortunately how I feel about it too. I gave an honest effort at getting into the ecosystem and tested it out with a few close friends. The rough edges brought the experience down compared to other stuff that “just works”, and losing community support for the IRC bridge took a huge use of my own away from it.
By colordrops 2025-11-202:24 The rough edges are too much for even very technical users and admins, so there's no way we're going to get friends and family to adopt this.
By tcfhgj 2025-11-2010:11 > There seemed to be a lot of velocity in the beginning but the last couple of years have addressed approximately nothing in terms of the UX and it's a crying shame as Matrix/Element had a lot of potential.
It still has.
And with Element X they have greatly improved the UX.
Plus utd errors have been reduced by a lot.
That said, I haven't ever had issues with devices not being correctly verified ( I use that feature since it was released - and can still recover the encrypted messages of that time).
By Timshel 2025-11-208:11 Anecdotal but running a server with multiple bridges for multiple years. Had such issues initially but none recently.
By bigfudge 2025-11-206:37 It’s that hard even with a user in the loop to press buttons. Verifying bots is even worse and the docs are either non existent or wrong. This is such a shame because element otherwise does exactly what we want but it makes me nervous it’s so badly supported and buggy.
By solarkraft 2025-11-202:34 > but the last couple of years have addressed approximately nothing in terms of the UX
This sucks to hear. I thought they had made massive improvements in the last year or so (I don't know because I feel too burnt by past experience).
By phantasmish 2025-11-2016:27 When I looked into it the complexity of standing up and admin'ing a Matrix server was clearly either a massive "architecture smell" so bad the project was likely long-term doomed, or a deliberate choice to make it terrible to get people to pay for managed hosting.
In either case, that's a no for me dawg.
By jerrythegerbil 2025-11-201:183 reply As someone whose devices randomly became unverified just a few months ago, signed out, and then tried to use my recovery keys: I was authenticated, but unverified.
When attempting to verify iOS, Desktop linux didn’t work. When attempting to verify Desktop Linux, Desktop Windows didn’t work. When verifying Android, iOS didn’t work. Every verified official client for every platform was verified, tried a different verification method than expected, and failed.
All of this to say, this isn’t the first time this has happened to myself and others. Forcing verification is otherwise known as unexpected “offboarding”. If some verification methods have problems, publish a blog about their deprecation instead.
I love element, but this can’t be done without prior work to address.
By Groxx 2025-11-2016:31 I've had constant problems with the verification ever since it was introduced. As far as I can tell it hasn't improved at all. Sometimes it works, sometimes it repeatedly kicks me out moments after succeeding, and it's still prompting me to verify some old devices that I removed Element from years ago and I can't find any way to make the constant pop-ups go away (when they feel like appearing again - sometimes they go away for a couple months).
All this will do is make me lose EVERY profile.
By Aurornis 2025-11-2014:08 I went through the same frustration recently. I only occasionally use it, but every second or third time I have to open it up to talk in some channel I lose 30 minutes chasing my tail trying to work through the latest set of problems.
I like the idea, but the effort to reward ratio for using the product has not been good. It has caused visible churn and attrition in the few channels I’ve tried to participate in and it’s become a problem for the OSS projects I’m part of that try to use it for their communication. Of course, there are some people who like it that way and think making communication spaces difficult to access is a bonus, but that’s another topic.
By tcfhgj 2025-11-2010:24 are you using your own server?
I have never heard of such issue and not experienced it despite intensive use, so it's a bit strange that you and people you know have experienced this repeatedly.
I think Matrix as a protocol has been pretty ineffective, as their top priority seems to be keeping data permanent and duplicated. Both performance and privacy are at the bottom of their priority list. The one good thing I can say about it is that encryption of message contents is enabled by default in conversations and available in groups, but that's about it - nothing else is, or can be, encrypted. In other words, every participating server knows who is talking to who, and how much, and when, and in what rooms, and what those rooms' names are, and what those rooms' descriptions are, and who moderates them, etc.
Meanwhile, an app like Signal can do none of that, and that's by design.
If you're looking for a privacy oriented messaging system, you'd best look elsewhere.
I'm new to Matrix and found this comment on reddit. How much of it is accurate and does it actually contribute to whether or not the future of the protocol is promising?
@Arathorn would be an objectively better person to discuss this, but the Redditor isn't completely off the mark: metadata is (currently) not nearly as well-guarded on Matrix compared to Signal.
However, work is ongoing to improve the situation; more importantly, Matrix is a different threat model (in my opinion), and allows for different trade-offs.
When I use Signal, I have to trust Signal's servers and their admin team. With Matrix, we get to keep trust circles smaller (friends and family on smaller servers, where we already trust the people running them). We have no hard requirement to federate either - if I want something just for people I know, we leak less data than Signal does to the outside world. We also get to host Matrix servers in areas we're comfortable with, whether that's our living room, or any nation that isn't America.
Matrix isn't perfect, but I appreciate how quickly they're improving, and the areas they're focusing on.
Matrix and Signal have very different objectives. Matrix wants to be an encrypted IRC or Slack. Signal wants to be a secure messenger you can entrust your life to. They are both worthy projects; there's not as much overlap as people think.
I trust my life to the server I host in my own closet. People can lecture me all day long about the superiority of Signal's encryption, and I'll just slowly rotate my chair to point my index finger at the Dell OptiPlex behind me.
That's fine. You'll pardon me if I'm unwilling to trust my own safety to your Dell OptiPlex. Whatever you think about Signal, the fact is that Matrix --- which is what the thread is about --- makes decisions that serve the IRC/Slack use case at the expense of the "absolute most possible safety" use case. That makes sense: some of larger-scale group chat's goals are in tension with "absolute most possible safety".
By dwohnitmok 2025-11-203:372 reply I wouldn't characterize Signal as "absolute most possible safety" as you are implicitly doing here.
I would probably characterize Signal as "most possible safety for the average nontechnical user" which entails trade-offs against absolute safety for certain UX affordances (and project governance structures that allow for these decisions to be made), because if said affordances are not given, the average nontechnical user either simply won't use Signal or will accidentally end up making themselves even less secure.
I couldn't be less interested in arguing with you about Signal. My point is that it doesn't make as much sense to compare Signal and Matrix as people think it does. Large-scale group chat is intrinsically less safe than the kind of chats most people use Signal for. You can substitute whichever other secure messenger you prefer.
This "average nontechnical user" stuff, though, miss me with. For 2 decades people have been encouraging the "average nontechnical user" to do incredibly unsafe things on the premise that any kind of message encryption is the best alternative to sending plaintext messages. No: telling people not to send those kinds of messages at all, unless you're dead certain the channel they're using is safe, is the only responsible recommendation.
By JuniperMesos 2025-11-208:36 I have started using Signal for large group chats in the past year or so, after spending many years using it as an encrypted replacement for SMS texting. Signal has gotten noticeably better at the UX of group chats during that time, although I am still annoyed that they basically require you to use their client to access the network in the name of security. I can't easily run a legitimate 3rd party Signal client on my server, and when I've tried I've accidentally broken my access to my account on my phone, which is quite annoying since I use Signal pretty frequently.
I want there to be something like Matrix that is designed first and foremost as a large-group realtime chat program (really, as a meaningful FOSS alternative to Discord), and it should make different tradeoffs than Signal. I'm actually willing to entirely forego encryption, at least at first, to make this happen - IRC wasn't encrypted and Discord isn't either, and these are things I want to replace with something better. Matrix's UX is still noticeably worse than Discord's, and I'm skeptical that the ostensible security gains from the encryption are worth it, especially given the problems with device verification UX, metadata leakage, and the fact that as the number of people in a group chat grows the possibility that they will take a screenshot of the encrypted message sent to them and leak it to the press grows higher and higher.
By dwohnitmok 2025-11-2021:441 reply > This "average nontechnical user" stuff, though, miss me with. For 2 decades people have been encouraging the "average nontechnical user" to do incredibly unsafe things on the premise that any kind of message encryption is the best alternative to sending plaintext messages. No: telling people not to send those kinds of messages at all, unless you're dead certain the channel they're using is safe, is the only responsible recommendation.
Eh. You misunderstand me. I don't really have too much of a view on this personally. Unless you specifically think that the term "average nontechnical user" is a bad term.
N.B. for other readers of this thread to flesh out my initial point:
Signal specifically didn't do that recommendation until they got sufficient critical mass of users in 2022. In particular Signal gracefully degraded to unencrypted SMS if the other side didn't have Signal.
Likewise Signal required phone numbers until 2024 when it shifted over to usernames, with all the security vulnerabilities that entails.
Signal has repeatedly made trade-offs that prioritize UX over absolute security even in 1-1 chat settings. That's not to criticize those trade-offs, there's a variety of reasons why they make sense or don't. But Signal has consistently demonstrated that it is not willing to make severe compromises to the UX and understandability in the name of absolute security and that it will balance the two.
I disagree with basically all of this but none of it is on topic for this thread and none of it has anything to do with the point I was making.
By dwohnitmok 2025-11-213:52 The point of HN comments are for tangents, so I'm happy to hear why you as a domain expert disagree with any of what I raised there.
Also to your point
> For 2 decades people have been encouraging the "average nontechnical user" to do incredibly unsafe things on the premise
Sure I can agree with that. But that wasn't my point either? Unless again you specifically object to the term "average nontechnical user."
By Forgeties79 2025-11-203:43 This is basically the same logic for why I often recommend Plex over jellyfin to people. Yes Plex is not proper self hosting. Yes Plex the org is making increasingly questionable decisions. But for people who want to get away from the major streaming services and maybe even want to dip their toes into something that resembles self hosting, there really is no other option like Plex. It’s so insanely turnkey and easy to install on every device. You also don’t have to worry about exposing your network if you don’t know what you’re doing.
If nothing else it’s an incredible foot in the door for a lot of people to make the leap to something like jellyfin later.
I obviously can't speak for you, but there's not a freaking chance I'd trust my life to the servers I run.
To go maybe too literal: when I'm working on machines that could physically eat me, I don't trust myself with just one off switch -- I want redundancy. And since computers are horrible piles of ridiculous complexity, the closest I can get (and not really get close) is trusting some of the top minds to overthink the crap out of it in a way that I can't do with the systems I manage.
But again, YMMV.
By pkulak 2025-11-207:33 Well, when US-EAST-1 went down, my family was still chatting. Same with Cloudflare. Even if I lose internet, we can all chat so long as we’re on the network.
That said, the uptime is still probably worse than Signal. I didn’t mean trust the reliability. I meant the security.
> Matrix wants to be an encrypted IRC or Slack
matrix's users want it to be a decentralized/encrypted irc/slack, but unfortunately matrix's maintainers believe their mandate is to build a next-gen tcp/ip (or something very close to that)
which dooms the project
By butvacuum 2025-11-205:56 When you leak that much metadata, it's disenginious to call it encrypted.
By Gigachad 2025-11-203:43 In the real world friends and family aren’t running their own matrix servers. At most they are signed up for whatever random one came up first in the search results.
So you end up with a similar problem to Mastodon where either you are facing problematic or inexperienced admins, servers shutting down, and everyone centralising on the main server.
It's pretty accurate. I was a bit shocked when I saw that room names were not encrypted. I thought that was such a basic privacy requirement, and it's not hard to implement when you already have message encryption.
Matrix seems to have a lot of these structural flaws. Even the encryption praised in the Reddit post has had problems for years where messages don't decrypt. These issues are patched slowly over time, but you shouldn't need to show me a graph demonstrating how you have slowly decreased the decryption issues. There shouldn't be any to begin with! If there are, the protocol is fundamentally broken.
They are slowly improving everything, with the emphasis on "slowly". It will take years until everything is properly implemented. To answer the question of whether the future of the protocol is promising, I would say yes. This is in no small part because there are currently no real alternatives in this area. If you want an open system, this is the best option.
The decryption problems I've experienced have a been fixed a while ago. There was a push to fix these last year or the year before that, and at this point I'm pretty sure only some outdated or obscure clients with old encryption liberties still suffer from these problems.
The huge amount of unencrypted metadata is pretty hard to avoid with Matrix, though. It's the inevitable result of stuffing encryption into an unencrypted protocol later, rather than designing the protocol to be encrypted from the start.
I've had similar issues with other protocols too, though. XMPP wouldn't decrypt my messages (because apparently I used the wrong encryption for one of the clients), and Signal got into some funky state where I needed to re-setup and delete all of my old messages before I could use it again. Maintained XMPP clients (both of them) seem to have fixed their encryption support and Signal now has backups so none of these problems should happen again, but this stuff is never easy.
By Klaus23 2025-11-2011:23 Yes, messaging protocols, especially federated ones, are never easy. I just wish we could have skipped the three or four years when Matrix was basically unusable for the average user because end-to-end encryption was switched on by default. Perhaps a clean redesign would have been better. Now they have to change the wheels on a moving car.
> These issues are patched slowly over time, but you shouldn't need to show me a graph demonstrating how you have slowly decreased the decryption issues. There shouldn't be any to begin with! If there are, the protocol is fundamentally broken.
This is wrong, because afaik these errors happen due to corner cases and I really don't like the attitude here.
It's not just a corner case. The issue was so prevalent for years that if it was limited to just a few corner cases, the entire protocol must consist of nothing but corner cases.
It frequently occurred on the "happy path": on a single server that they control, between identical official clients, in the simplest of situations. There really is no excuse.
I'm not saying that building a federated chat network with working encryption is easy. On the contrary, it is very hard. I'm sure the designers had the best intentions, but they simply lacked the competence to overcome such a challenge and ensure the protocol was mostly functional right from the outset.
> The issue was so prevalent for years that if it was limited to just a few corner cases, the entire protocol must consist of nothing but corner cases.
for me it wasn't really; occasionally it would hit me, but mostly it worked, and I have been using it for encrypted communication since 2020.
> It frequently occurred on the "happy path": on a single server that they control, between identical official clients, in the simplest of situations. There really is no excuse.
There still can be technical corner cases in the interaction of clients
a talk for details: https://www.youtube.com/watch?v=ZUSucR2axWI
> I'm sure the designers had the best intentions, but they simply lacked the competence to overcome such a challenge and ensure the protocol was mostly functional right from the outset.
well, even if this was true, they still were brave enough to try and eventually pull it off eventually. Perhaps complain to the competent people who haven't even tried.
> for me it wasn't really; occasionally it would hit me, but mostly it worked, and I have been using it for encrypted communication since 2020.
I think the statistic said that around 10% of users receive at least one "unable to decrypt" message on any given day. That's a lot. Perhaps not for devs who are accustomed to technical frustrations, but for non-technical people, that's far too frequent. Other messaging systems worked much better.
> There still can be technical corner cases in the interaction of clients
> a talk for details: https://www.youtube.com/watch?v=ZUSucR2axWI
You linked to a German political talk show. If you wanted to show me the talk in which the guy listed reasons such as "network requests can fail and our retry logic is so buggy that it often breaks" and "the application regularly corrupts its internal state, so we have to recover from that, which is not always easily possible", let's just say I wasn't that impressed.
> well, even if this was true, they still were brave enough to try and eventually pull it off eventually. Perhaps complain to the competent people who haven't even tried.
It isn't a problem that the Matrix team are not federated networking experts. At the time, they had already received millions in investment. That's not FAANG money, but it's still enough to contract the right people to help design everything properly.
I'm not mad at them. Matrix was a bold effort that clearly succeeded in its aims. I'm just disappointed that it was so unreliable for such a long time, and still is to some extent.
By tcfhgj 2025-11-2014:30 Correct link: https://www.youtube.com/watch?v=FHzh2Y7BABQ
> I wasn't that impressed.
If you think, I want to impress you, you are wrong.
By the_gipsy 2025-11-2015:21 To be fair: signal means everybody trusts one central authority. Doesn't matter that it's a foundation or non-profit or whatever.
And: a phone number is still required, a PIN is not, so by default it's susceptible to phone/SIM spoofing attacks. This one really boggles my mind, it's not that I personally am afraid of this vector, but I don't understand why they would insist on phone numbers at this point.
I think part of the problem may be that Matrix is just pretty complex, because of its modular and decentralised design. Meanwhile, Signal is much more centralised and monolithic. And while they have added a few features over the years, its core functionality is relatively simple, and they were initially just focussed on getting that right.
By AJ007 2025-11-2015:24 The "decentralization" of Matrix is true in some respects, and false in others. Which would be ok, but if all of the complex architecture and issues are in the support of being decentralized, then this seems like an early planning failure.
My suspicion is the real problem that exists now originated from the bifurcation of desktop and mobile. Mobile broke the true p2p decentralization which was easy on desktop, and the split between Android and iOS makes it worse. Users expect an experience on iOS and Android which has parity with desktop. And the entire thing has to be as good as Discord.
I've taken a hard look at all of the truly open source alternative messaging options, and almost nothing handles multi-platform very well. Even when you expand it to commercial options, for a very long time, all of the Slack clones had mediocre mobile apps -- which basically was a death sentence if you weren't Microsoft. This is true today, but I expect it will change in 2026 and onward with the rapid increase in software development driven by AI agents.
By Gigachad 2025-11-203:46 I remember reading some of the pdf on state management in matrix. The math and logic behind working out what the current name of the group chat is made my head spin.
By kachapopopow 2025-11-202:18 it's pretty on point, it's mostly a "trusted" platform as long as you trust the host with the messages between two people (or more?) being (optionally) encrypted.
By RicoElectrico 2025-11-2016:231 reply I wish FOSS communities that want an alternative to Discord or Slack ditched Matrix altogeter. It sucks for that. Better use Zulip or Mattermost, both of which are self-hostable.
Edit: I looked up and apparently Mattermost would be out of the question for their feature downgrades in the community version as of late...
By broken-kebab 2025-11-2022:451 reply Correct me if I'm wrong but I believe Zulip's licensing de facto restrict self-hosting solution for 10 users (others won't see notifications on their mobiles or something like that). This is important for non-commercial communities.
By tabbott 2025-11-2023:03 No. See the "Sponsorship and discounts" section on the pricing page, which makes clear the 10 users limit for free usage of the mobile notifications service is for workplace use, not communities.
By jrm4 2025-11-2016:52 Okay so -- this and Bluesky.
REALLY feels like no one talks about how "permanent and duplicated" is very much an anti-feature if autonomy and safety and freedom is your goal?
Like, no actually - automatically saving everything all the time is bad. I thought we sort of already knew that.
By sroerick 2025-11-203:32 Pretty crazy, right? It almost seems like a honeypot
