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.
> 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.
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.
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.
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).
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.
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.
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.
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
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
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.
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.
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.
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.
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?
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.
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.
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.
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.
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
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.
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.
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.
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.
> 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).
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.
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.
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.
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).
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.
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".
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.
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.
> 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.
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.
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'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)
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.
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
> 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
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.
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.
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.
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.
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.
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...
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.
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.
I tried implementing a Matrix bot a few months back, and it was an absolutely miserable experience, since Device Verification/E2EE was not working with any of the available open source Python implementations I found.
I then stumbled upon their internal Rust SDK[1] that they use for Element X, which is actually quite nice, and even has FFI bindings for Python and Kotlin[2]. Unfortunately the documentation was really lacking at the time. I managed to put something together with the help of an LLM and the source code and examples to find my way around the various APIs, and it actually works with emoji verification and E2EE (although there are weird bugs around synchronization, but that's probably just an API misuse on my end).
It seems they've improved the documentation since and even provide a reference client[3] to see how things work.
What is verification? What does it involve doing? A lot of information on why it's useful, but how is it implemented? I hope it's not something like the Play Integrity API, but with no information to go on, I can't say either way.
> After Alice logs in on a new device, she uses her cryptographic identity to demonstrate to Bob that the new device genuinely belongs to her, rather than being added by someone else with access to her account. She can do this either by entering her recovery key (which gives the new device immediate access to her cryptographic identity ), or by carrying out an interactive verification from an existing verified device.
So is this like the Signal PIN which is required when installing on a new device? If you forget, the cryptography changes and old contacts are warned that signatures are rotated, right?
Quite. I have yet to manage a verification between clients.
I have had all variations of clients ignoring requests, reporting requests only for the requesting client to ignore the response. Both ends quitting declaring that the other end cancelled, asking for the other end to input a code while the other end shows no interface for doing so.
It marked the end of me using Matrix as a platform. I'd go back to the old IRC channels if there were anyone still there.
In this case, it's what you do when signing in from a new device (or browser) to attest that it's yours. It avoids warnings to you and your contacts that a device has gained access to your account without your approval.
It involves doing one of these things:
- Comparing a short sequence of emoji on each device and confirming that they match.
- Using one device to scan a QR code displayed by the other.
- Entering a recovery key (a line of text) that you were given when you first set up the account.
Pretty quick and easy in most cases, although some clients can be glitchy in this area and require trying again.
(Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
The experiences reported here seem to say otherwise...
As others, anyhow, I haven't tried again recently
> (Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
I last tried Element about six months ago, but for years using the recovery key was either impossible or close to it, and mostly just for idiotic UI mistakes that were never corrected (something like you had to enter the key where they wanted the passphrase or the opposite).
To my recollection the version from six months ago worked better in that regard, but it was still asking to enter the passphrase where you actually had to enter the recovery key.
I think current Element versions accept either a recovery key or recovery passphrase in the same input field, so there's no getting it wrong. Since you seem focused on UI, it's worth noting that Element X (their beta mobile app) has a greatly simplified interface; their team clearly has been working to make it easier.
Also, other clients exist.
For whatever it's worth, I've been using Matrix for about five years, including some of its roughest times. I seldom see errors these days, but I can understand how folks who were frustrated with earlier iterations would still be soured to it. Such is the nature of an ambitious work in progress, I suppose.
I use it because there is nothing else with the combination of features that are most important to me, and because (despite my gripes) I can see slow and steady improvement. I think it's moving in the right direction overall. I could picture introducing family members to it once Matrix 2.0 is released and the implementations shake out any early problems.
In short, the passphrase works with both and the recovery key with neither, specifically:
Element classic has two separate fields; if I input the recovery key (in the correct field), I get told "Backup could not be decrypted with this PASSPHRASE: please verify that you entered the correct recovery passphrase."
That's how it was the last time I used it, and if I'm not mistaken it's been for years.
Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
Funnily, by the way, it seems that with Element X you can't do anything if you don't manage to get verified, there just doesn't seem to be a way to skip it.
Furthermore, after signing out from Element X I'm unable to even just logging back in, I get an error ("Sorry, an error occurred") after I enter the credentials; even after clearing all the app's storage. Very, very weird.
The new login-via-browser is pretty problematical, by the way, I could only make it work with Chrome.
> Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
I have just tried this on Android.
I am directed to
1) "Device verified - Now you can read or send messages securely, and ... - [Continue]"
2) "Help improve Element X ... [OK] [Not now]"
3) list of chats
Element X Android fyi. No problems logging in using Firefox.
Since you didn't share all the details of your tests, I'm having trouble picturing how I could try reproducing what you did. (That's okay; I'm not an Element maintainer.)
However, a couple of things occur to me:
- No Matrix client that I know of supports setting both a randomly generated recovery key and recovery passphrase on the same account. So in order to test both, you would have to use a separate account for each. If you tried to test both on the same account, it's expected that one of the two would be rejected.
- You didn't specify a platform, but since you wrote "Element classic", I guess you must mean Android or iOS. I used Element Desktop / Web to set up my accounts, which could explain why I saw different prompts.
I hope you reported the error message referring to a passphrase when a key had been entered. I imagine that could leave the user wondering whether they had made a typo or the app had misinterpreted what they typed, which would not inspire confidence in it.
That is true, but what weakens my confidence is that the Element/Matrix team often doesn't present it that way. So much communication from them is about how it's amazing and great and the best messaging app in the world. If they presented it more like a typical slow-growth open source app I think they'd garner more goodwill. By setting high expectations they increase the likelihood of disappointment.
Discord does not do any sort of end-to-end encryption. All messages are fully readable and writable by Discord. Discord decides whether you are who you say you are, and all clients trust whatever Discord says to be trustworthy.
> The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.
honestly it's the best thing ever they have done:
- I have heard of someone who failed to use Matrix, because he got frustrated of having not a secure enough passphrase
- people don't choose secure passphrases
- it provides options making things more complex (especially when guiding others)
- you know you won't memorize it, so you are more likely to put it down
1. Generating a random key by default (but still allowing advanced users to prefer a passphrase) would solve your "secure enough" problem.
2. Better yet, a "secure enough" passphrase could be generated by default, à la Correct Horse Battery Staple. A user wouldn't be forced to choose one.
3. When adding an option, interface complexity can be avoided by simply not showing it by default, or by placing it off to the side in collapsed state where it doesn't draw attention.
4. If you're worried about people writing down a passphrase, you should be even more worried about a string of 50 random characters.
That last one is important. Nobody is going to memorize a random key, which means everyone has to write it to a file (or painstakingly write it on paper) for long term storage. When verifying remote devices, they also have to get the key to the other devices, so they are likely to use copy/paste, which will put it on at least two devices' clipboards, where it will be available for harvesting by nosy apps/websites or accidental pasting to random ones. They also have to figure out a way to transport the key from one device's clipboard to another, which might be email or SMS or some other insecure channel that they're accustomed to using. Or in the unlikely event that they choose paper, they have to painstakingly transcribe it again at the other end.
In other words, forcing the use of a random key does not increase security vs. a well-implemented passphrase system, but instead pushes responsibility for security out of the software and into the hands of people who aren't trained in it. Inviting more big mistakes.
A passphrase would avoid most of those exposure risks by not having to be written down or copy/pasted or sent through insecure channels. And with the right UI, it wouldn't be more complex to use or less secure.
Fortunately, Matrix supports passphrase-derived keys at the protocol level, so client developers who understand how to implement them well for humans can still do so. I hope Element's product managers will come around eventually.
I was afraid of that as well given the wording but, no, it's nothing to do with third parties at all. Just when you log into a new device, you confirm it on your old device so it knows it can transfer encryption keys for old messages to the new device
This has been in Element/Matrix since forever and I found it the easiest verification mechanism of all the encrypted messengers I've tried. I'm not surprised they're making this part of the standard process, but the wording in 2025 is... unfortunate. Or perhaps that adjective should be applied to the rest of the world since it's not the Matrix Foundation which changed. For the reader to decide ^^
In the current state, it's basically just a self verification. When you use a new device it shows a series of emoji on each device and asks you if they're the same, then the device is verified.
Thankfully, no, it's not anything evil like Play Integrity is. The simple explanation is that the first time you log in to an existing account from a new device, you need to go on one of your old devices and confirm that the new one is yours.
I’m a server admin and I still couldn’t tell you why when I sign new endpoints in and verify for cross-signing it still also asks me for a recovery key.
For encrypted search on desktop it has to fetch batches of messages and this is configurable in settings. It just had a number? what is that? how large the batch is, how many ms? no clue! good thing we can’t do encrypted search on mobile/web.
Yeah, I was wondering this as well. At the very least, this appears to be an Element requirement that was just enabled by a Matrix protocol update, so moving would be possible, but afaik Element is extremely popular as far as Matrix goes.
Despite all the gnashing of teeth in this thread, this seems reasonable. This seems to only prevent you from logging into your account, with only a password, NOT verifying it (by dismissing all the prompts asking you to do so), and then sending (and receiving new!) encrypted messages anyway. I've never used an unverified Matrix account in the 6 years that I've been an active user. Verification used to be a bit finicky, but it's pretty seamless now. And once the QR code login stuff is better supported, it will be dead easy.
> Despite all the gnashing of teeth in this thread, this seems reasonable
I empathize a lot with the negative experiences shared in this thread.
I think the problem is that every little decision in Matrix might be reasonable to the people who have complete context about the decision, but all of the churn and rough edges have added up to a very bumpy ride. Not only that, but it has been a poorly communicated and documented ride as many in this comment section can attest.
I suspect all of these issues and changes feel like no problem to people who are active in Matrix every day and have a support network to chat with where they all get through the issues by sharing tips and info. For the rest of us who are casual users who only occasionally log in it feels like I’m rolling the dice every time I have to use it. Some times it works like it did last time, some times I have to go on a 30 minute adventure with Google and play games across devices to get it back into a working state again.
> Not only that, but it has been a poorly communicated and documented ride as many in this comment section can attest.
The guides are written for cryptographic infrastructure nerds and not regular normal users that have a habit of forgetting their own passwords after six months. Not to mention the fact that the Element UI tends to churn a lot.
I didn't even know that they deprecated creating new passphrases, and that's what I was telling my users to do!
Doesn’t verification also exchange encryption keys, letting you decrypt messages from before you logged in? I remember that being a huge issue where you would see unable to decrypt messages.
Probably just bad UX to let people skip the verification step.
But it also asks for recovery key and complains about it being out of sync until entered even if you do the verification step! Entirely possible to only get a partial recovery of messages until this is entered.
That's not normal. It doesn't happen on any of my accounts or clients. Verification takes a moment if you're in a lot of rooms, but it exchanges all keys.
been a pretty reliable issue when I've set up a new device. Whatever keys the client is getting, they're apparently not useful.
(This general flakiness of features just sometimes not working as they should is probably the main reason I haven't tried to recommend friends to switch to element)
> Despite all the gnashing of teeth in this thread, this seems reasonable
I think it's not the requirement itself that's the crucible of discussion but the issues are rather that the blog post should have explicitly defined what verification is in it's second sentence and that matrix/element still is barely useable even for reasonably technical users.
Scale matters. Once you achieve over a hundred of users, you got all the random bugs, and glitches appearing, and you can't guide everyone personally across UX issues. This is when lack of decent documentation, unpolished UI, and even the fact that it uses its own terminology (like "spaces") starts to hurt. I don't mean Synapse/Element combination is bad, but so far it's not great either.
I use Thunderbird as my main Matrix client since it's already always open on my PC and is Lightweight. Whenever I open Element or any other client (Nheko, etc.) they all complain about each-other being unverified.
Clicking verify in any client does nothing. No popups in any other clients - doesn't ever seem to do anything. Sometimes Element will pop up a QR reader but there's no QR presented in the other clients. The UX around Matrix is a nightmare.
Not sure how often they update these pages, but Thunderbird is still listed as beta on matrix.org clients page [0], and I remember trying it out some time back and it was indeed very beta (maybe not even beta). It didn't feel like it was getting much maintenance so I stopped using it. I think it's fair to expect bugs in beta releases.
I tried out an alpha client once & can’t get the stupid pop-up about unverified devices to go away now. Another client didn’t have the verification flow even set up—this will end up being yet another barrier to entry for new clients. With the clients (yes, multiple) crashing often, constantly syncing for ages, & feature sets not on parity + without graceful fallbacks, I do not like the Matrix client space (nor the server space, but that is a different topic).
There has never been a better time to (re)embrace XMPP as your decentralized chat option. The clients are less buggy, handle missing features gracefully, & best part is, not being built on an eventual consistency model, you don’t have the constant syncing issue with delayed messages. If you wanted you could make an XMPP client in a day since the base spec is small/simple—& features like device verification would be seen as mandatory in the base specification.
> I tried out an alpha client once & can’t get the stupid pop-up about unverified devices to go away now.
Open app with device management (e.g. Element Desktop) and remove the unverified devices you don't intend to verify.
Regarding XMPP: With the lack of Cross Signing, key backup and consistent storage of messages, it can't be expected to provide the convenience Matrix does for the foreseeable future - just my personal opinion. The matrix-rust-sdk should it also make easy to get started with a client.
I used to consider myself a HUUUGE matrix fanboy....while i still respect what the teams have done over time, I have been feeling a little, i don't know, deflated maybe? Maybe its the UX/UI aspect, i don;t know...i have not run a homeserver since like maybe 2019 or so? But nowadays, i have less interest in running a homeserver, and as far using the various clients: meh. Element feels bloated, and others either might be more snappier but might have an odd bug, or don't implement all features that might be expected, etc.
So, last year i tried to play briefly with Prosody server to re-acquaint myself with xmpp...and it wasn't so bad. Not as great as i expected for this day ana age, bbut not terrible. The server setup felt like i needed to study a bunch of different docs...and ultimately was smoother than expected....so i think documentation is either outdated, or was written a little less clear than expected. That being said, the low resource usage was ridiculously pleasant compared to matrix homeserver! The fact that an xmpp server allows for such scalability on such low resources is a great testament! And, that was prosody, which some folks state is not even as performant, scalable as ejabbered....so they say...so wow, that's impressive if that's true. Regardless, xmpp servers that can run on such low resource hardware but enable so many users to chat...is quite awesome!!! The client side of xmpp was a different matter; i wasn't so happy. I blame myself because maybe there might have been plugins that maybe i didn't install correctly on server side, i don't know...but it felt not as easy as i expected. The clients were a little disappointing; again not terrible but not great.
Maybe i'm spoiled? Or, maybe i did too much wrong? But if that's the case, the maybe there's an opportunity for better documentaiton? I don't know....i really like both matrix and xmpp because both live in the realm of free and open source software.....so i really want both or either to succeed. I want to live in a world where we are not beholden to only proprietary options, like whatsapp, crappy sms/text messaging, etc. I want to give props to all the folks who made and maintain all aspects of xmpp...as much as i am whining, i don't want to take away from all the hard work that they have freely given; super props to them!!!
What i really want is a modern, free and open source version of IRC, with plenty of modern features (E2EE, file uploads, presence detection, etc.), decent desktop and mobile clients, easy server installation and management, and said server-side software would ideally not need such beefy hardware to run...Or, is my wish too far fetched?
One thing I would note on the client side of xmpp - there does seem to be a lot of work happening under the surface. Snikket is working on an SDK to streamline modern client development. There are a couple of alpha stage clients written on it already, and maturatoin of the SDK should lower the bar for pushing clients forward.
Also independently, Movim keeps advancing and Libervia is doing a ton of cool work. I'm sure I am missing others.
I had only heard about Snikket as I was spinning down my xmpp experiment... maybe I can take a look nowadays (including moving and others). Thanks for sharing!
This is what frees a barrier to decentralization & actually owning one’s data. A few of my friends are now running their own single-user or small XMPP servers since it doesn’t use much in terms of resources or storage in comparison.
> The server setup felt like i needed to study a bunch of different doc
I believe this is what the Snikket project is trying to be. That said, XMPP servers are used for a lot more than just chat which is why most of them don’t have good defaults for merely chatting with friends since that isn’t the only or a generic enough use case (XMPP is behind Zoom, Jitsi, Fortnite, etc.).
> The clients were a little disappointing; again not terrible but not great
True. But I appreciate that there are many options & most features gracefully fallback even on TUI clients (like ‘reactions’ just being a message reply with a single emoji). If Element adds a feature (like polls), the other clients, the new feature just doesn’t show up. For a web client, the NLNet funding is really giving a boost to Movim as a reasonable alternative to Discord that is self-hostable & federated so users—taking back the meaning of “join my server” to literally mean someone’s server & without needing to create another account just to join that server.
As for the wish… this is what XMPP MUCs are—IRC with niceties like moderation, optional encryption, & file uploads. You said yourself the resources for servers is small & for your stated use case, most existing clients can handle being IRC+features while also not being centralized unlike IRC.
> ...that isn’t the only or a generic enough use case (XMPP is behind Zoom, Jitsi, Fortnite, etc.
Great point! I forgot that xmpp can/is used for other use cases that are not just chat.
Also I guess I should be a little more forgiving about the MUCs, and client features in particular because you are right that fallbacks tend to be graceful.
I think we all want that. The fact that it doesn't exist is an indicator that it isn't trivial to build. All those modern features are at odds with performance.
FYI: here are the videos of the latest matrix conference: [1]. I think there's a lot of interesting stuff going on!
also, instead of hosting your own server or using some (more or less well-financed) public servers, you can simply throw some money at [2] to pay for hosting for your group of friends or family or whatever. (not affiliated, but I like the idea)
This basically means that Matrix will stop working for my parents and other family: the only people I use matrix for. We started during the pandemic for the video chat element. But Riot.im/Element.io changes to the homeserver over these many years have made it so none of our accounts properly verify. I can't even get my account to properly verify and I'm a huge nerd. We put up with it because of inertia and chat still working fine. But this? I guess it's the end.
Riot.im/Element.io really knows how to shoot themselves in the foot.
I love Martix/Element, and about the only thing I don't like is that I need moar features!
We have a space with several rooms for our FOSDEM devroom, it's been working flawlessly, including for all our video calls with many participants. Thanx Element team!!
I have a private matrix server for a few friends. Whenever someone logs on with a new device or client it lists them as being unverified. Eventually it goes away. I really have no idea at what point verification occurs.
They verify their device. Usually means opening Matrix on a other device, clicking the pop-up, and scanning a QR code or matching emoji. One device signs proof of verification of the other and exchanges encryption keys so the new device can read encrypted conversations.
Unverified devices are indistinguishable from a hacker logging in through credential stuffing/password leaks until verification is done.
It's a process similar to adding devices to Signal or WhatsApp, except with Matrix you can still log in without having physical access to another device. Useful if you only ever visit unencrypted rooms perhaps.
I am not sure the founder is reading this. I tried googling but couldn't find it - I recall the hn handle being something like Atheon. Not that hn sends mention notifications.
Matrix is something that had my eyes lit after years or being burnt/disappointed by communication apps (Signal included). I had converted/migrated a lot of people to it (I mean of course they didn't "convert" but they had it and were replying to me) from a country where WhatsApp is essentially "basic need" today – along with water, air, food, and shelter and that too in an era when it was not even stable. After that I just didn't know what the hell happened. Matrix, Vector, Riot, Element – things just kept happening. App was never an end user app and it became very clear that it was not the intention either. To be honest it didn't look like a replacement for something like Slack or something like IRC either. It was trying to become something which it seemed/seems has no end goal or destination i.e a clear roadmap. As if the goal is to develop cool features and just put them haphazardly together which I am afraid often results in something Mary Shelley wrote.
I still login from time to time and I don't understand what is happening. Something I see this notification, something that, sometimes I see there's a message pending, sometimes I see I have a chat recovered (old/stale; because there's no one I know uses it anymore), sometimes I see a certain chat is not recovered because some verification or decryption (or something) failed, sometimes I see (or understand it) that I might another active and verified device to recover certain messages. I had created some groups and of course they remain abandoned - but no, few og them were filled were porn and the kind of some was scary because that vector/riot/element account is connected to my real ID including the email and I was scared shitless. I tried deleting them but I couldn't. Next time I will try harder or just try to make it private after kicking everyone out. I will still keep the account. Never say never :)
I sadly have moved from writing enthusiastic to sad to disappointing comments to not even paying attention to it when there's a Matrix/Element news now. I think I don't even notice it. I think that's the worse kind of eventuality in this context. Anyway, I wish you all luck and I am sure you all know what you are doing.
> Matrix, Vector, Riot, Element – things just kept happening. App was never an end user app and it became very clear that it was not the intention either.
"The authenticity of this encrypted message cant be guaranteed on this device"
both sides verified, but this still randomly pops up, what happens then? will i lose those messages in the future?
I've been using Delta Chat with a lot of success. It is easy, it works, bots are easy and the concept is improving. They even plan to have forward secrecy. So, give it a try. If you explored it a long time ago, try again, many things have improved in that ecosystem.
Ugh.. I loved Matrix but I'm starting to hate the way they force these things through. Also last month they removed the categories (People, Rooms, Favourites) from Element Web just like that. Making it very hard to use as I use it. I had to roll back to an older version. They seem to be focused on whatever commercial or consumer experience but they are ruining it for power users.
My matrix server isn't even publicly accessible and users can't sign up. I don't federate with the network. So these issues are irrelevant to me. There should still be a way to turn it off. Because many of the bridge bots I run can't verify.
That's correct, but E2EE also allows for unverified devices[0]. Key distribution and device verification are separate issues, and the former doesn't enforce the latter until April 2026 as they've announced in the HN article.
Both XMPP (via OMEMO) & Matrix use libsignal for double-rachet encryption—so they have the same encryption properties. The biggest practical differences for the average user in my opinion is XMPP has a separate concept for DMs (not a 2-user room with encryption like Matrix), XMPP allows encryption to be both enabled then later disabled, & Matrix offers better resilience as messages & attachments get synced to all servers a room (which has a massive downside of resources, storage sizes, & moderation; if a server goes offline, you still have a history of the chat but if someone shares something explicit, such as CP, it will propagate thru the network & there is no way to delete it across nodes).
Lots of open source projects have matrix servers and not XMPP servers. Some bridges don't have XMPP equivalents (and some bridges don't have Matrix equivalents either).
XMPP also does E2EE of course, though I've found it to be a worse experience on most clients compared to Matrix.
To your contacts; if I understand correctly, the public keys are uploaded to the server
> What happens if I'm on holiday in Paris and drop my phone, which is the only device I have with me, in the Seine?
1) use your recovery key (to recover your identity (prooven by private keys) from the server) - I believe it only works if you enabled server side key storage
Or
2) create a new identity (contacts will be notified)
Or
3) wait until you have access to another device again
One of the super confusing things is that even if you only use a single client it can be verified or not.
That's confusing even for very technical people; because, it simply doesn't make sense.
Saying "verified or primary client with recovery keys generated" seems too long, so they should just say something like "less secure" on the "unverified" sessions.
Last time I used Matrix for our internal team notifications were beyond broken and we moved to Zulip, verification and authentication were also very funky at the time, I don't dare to try it again.
I want to switch to SimpleX Chat[1] but at the moment there are issues with battery usage on android devices because of the way notifications are done. I hope this[2] or some other solution get merged soon even if there is a slight impact on anonymity.
I had a more pleasant experience with SchildiChat hosted on a web server than the desktop Element clients.
I don't like the way groups/chatrooms are displayed to be honest. Its confusing. It feels like its trying to get away from the "server room/#somechat" model that works well with IRC and even with trendy current products like Discord.
Is this the ritual of getting together with a person and checking that their fingerprint match what you see on the app?
If this is that case what will happen is that people will start verifying everyone (because they might want to text to strangers that they can't bother verifying because the stakes are so low) and so verification will lose all meaning.
Not in current practice. That is why you have to get a certificate from a trusted CA. If your CA isn't in the browser's cert database they will reject the connection even on the first time. If browsers allowed TOFU we would still be able to use self-issued certificates, without manually distributing certs to anyone that uses your service.
With PKI you're trusting a certificate chain up to a CA you already trust, by way of your OS or browser vendor.
A domain can layer on HSTS to that, which directs clients to additionally refuse to trust a new cert for a domain until the one you currently trust has expired.
That’s not what HSTS does. It asks the client to remember that you want to only use TLS for that domain and refuse to use unencrypted HTTP in the future.
"Now the end-to-end encryption will leak into the UX even more and you better like it"
I'll say it again: E2EE will never become mainstream unless someone somehow manages to implement it such that it's completely transparent to the user while keeping all the features that people have come to expect from IM apps, like server-stored conversation history or support for multiple devices. By "completely transparent" I mean that the user doesn't have to do any extra actions whatsoever to make it work.
If that's true, then E2EE will never become mainstream. Consider this scenario: "My phone got lost/stolen/broken, so I just got a new one. I haven't logged in to this app since I got my last phone, so I forget my credentials for it. I'll reset them through my email. What do you mean my conversation history is gone?"
That's not really far-fetched. If you can get your conversation history back in that scenario, then so can the server operator so it's not real E2EE, and if you can't, then by your statement it won't become mainstream.
I more or less agree. And I also agree with the other commenter who says this may mean e2ee will never become mainstream. I think a lot of e2ee enthusiasts don't realize that the overwhelmingly most important feature for a messaging system is "when I log in, I can see all my messages". If there is a chance of that not happening, you're going to lose a lot of users.
I think there's the potential for a slight middle ground, but it would involve giving up a lot of the e2ee bells and whistles that privacy enthusiasts enthuse about (like perfect forward secrecy). You could image for instance a system where you have a single e2ee password and your data is encrypted on the server with that password. When you log in, you supply two passwords: your login password and your e2ee password. Then you have access to everything.
This tends to irritate people on both sides, since you can still lose your messages if you forget your e2ee password, and your privacy guarantees are also weaker, since the e2ee password can be a single point of failure that allows someone to read your messages. But people already rely on this level of security in other contexts. For instance, some cloud backup solutions encrypt your backup with a single passphrase. People are okay with having one password to unlock their entire hard drive's worth of data but not with one password to unlock their chat history?
I think it's worth exploring the space of e2ee solutions to find something that finds the balance between the levels of privacy and convenience that most users want. The thing is that existing apps that tout e2ee often do so to appeal to hardcore privacy advocates or people like dissidents in authoritarian states who are at risk of death if their messages are discovered. This level of security simply isn't a concern for the average person, and so they're not willing to take on the inconveniences that go along with it.
Technically they are, but neither of them fits the strict definition of a E2EE messaging app, while also still hurting the UX.
Whatsapp is very insistent about backing up your messages to cloud services without encryption. To use it on desktop, you have to make everything go through your phone. And, afaik, you still can't transfer message backups between Android and iOS.
Even disregarding the extreme gatekeeping, iMessage relies on Apple managing your encryption keys so there are no confidentiality guarantees. Apple can, at any moment, give themselves a key to decrypt your messages.
Both Whatsapp and iMessage are proprietary, so it's also the case of "please trust us that we've implemented it the way we claim we did".
> iMessage relies on Apple managing your encryption keys so there are no confidentiality guarantees. Apple can, at any moment, give themselves a key to decrypt your messages.
It relies on Apple device managing your encryption keys, no? Which, yes, Apple can still access if it really wanted to simply by virtue of being able to push an iOS update that does that. But the same exact vulnerability applies to any app running on your iPhone.
>Both Whatsapp and iMessage are proprietary, so it's also the case of "please trust us that we've implemented it the way we claim we did".
This is simply not true, any serious analysis of Signal would be performed on the binaries and not the source code. Having access to the source code does not make it any easier to discover well-hidden backdoors, but it is possible to exploit e.g. compiler behaviour in a way to create a backdoor that is essentially impossible to detect by reviewing source code.
Access to source code might very well make it easier to discover non-intentional bugs, but does not solve the problem of trust.
I mean we’re there for Signal. The parts that suck still are regarding access/retention of old messages which is an area Matrix is ironically slightly better about. But Signal we don’t need to think about verification, at worst it says this asshole has a new identity and then I have to tell them I’ve reset my iPhone for the 4th time this week…
Normal users do find retention important even if privacy/security minded users find value in ephemerality.
Officially it supports linking other devices like their desktop app as a secondary. I currently use this to link into signal-mautrix on my matrix homeserver. This way I can access signal from multiple phones and multiple computers using a matrix client instead.
But you still need one "primary" device and it has to be a phone, right? That's different from Matrix where you can have arbitrary devices that are all on an equal footing.
Yes. And, annoyingly, when you only use Signal occasionally, these desktop sessions expire. And you have to link again. And when you do, you end up with a gap in your conversation history because "security".
What exactly does this entail? I'm willing to be charitable in assuming that their use of "verify" isn't the modern usage of "give us your ID!" but I'm not enmeshed enough in the ecosystem anymore to know.
Respectfully, not even close. Verification is when I sign in from a new device, I use an existing device or second passphrase (either-or) to ensure that yes, it is me on both devices. I never have to reveal my ID, name, phone number, or email address to anyone. Not to Element, the Matrix Foundation, or the person running my home server where all my [encrypted] messages live.
My understanding is that there's two different types of verification.
Self-verification means that any new secondary devices you log into your account with will need to be verified by an existing login by way of an automatic popup that asks if you trust the device. It used to just be a Yes/No button but I think now they've added QR codes and/or emoji matching.
The other kind is verification between two different people, like when starting a direct message conversation, you might get the same emoji matching window to verify each other.
Yeah, IMO "verify" was a poor choice of wording for what this is. It has nothing to do with remote attestation or any other form of Treacherous Computing, and it has nothing to do with your real-life identity. It's just "go on your old device and confirm that the new device is really yours."
seems like it's just that element (the official, and most popular client) will ignore messages from unverified devices, but since it's part of the spec, other clients that want to be spec-compliant will implement this too. I don't think most other clients follow the spec that closely though.
I'm in favor of the change, the only downside I can think of is users with esoteric clients or simple bots that don't support verification won't be able to post to encrypted rooms with element users.
I feel like I'm alone in having good luck with matrix. I've been self hosting for nearly a decade to a handful of users, and it was a bit rough troubleshooting the encryption problems back when element was still called riot, but it's been a number of years since any of us have had a single encryption issue, and we added a new user recently with no trouble. we're still on 'element classic' though, the new 'element x' is a bit of a mess and loses the background sync feature, you need to set up a unified push server which I'm not looking forward to.
For what it's worth, I've been using element x with unified push for a month or so now and I get notifications with message contents without any delay. Maybe they fixed the issue you're worrying about?
Self hosting the call/video feature became a lot more complicated though (and it's incompatible with the old system).
my issues with element x are with the client itself, mostly missing features and bad UX. the main reason I don't want unified push is, it's just yet another thing for me to install and maintain, plus all my users need the client app installed. the ntfy server app even defaults to having a full web interface, fortunately it's possible to disable but it's just so much stuff to replace what used to be built-in to the app, to supposedly solve a battery life problem that I've never experienced.
I'm still going to get around to it, because element classic will be deprecated eventually. one of my users is on iOS and has a well-known bug with images not loading, which will probably never get fixed because they're focusing on the new client. and unfortunately I do have users that expect voice calls to work, so it sucks to hear that'll be annoying too.
I've had mostly good luck with Matrix too. Been self-hosting since 2022 and while there have been frustrations it has been pretty stable for basic chat.
There seems to be a lot of confusion regarding what verification is all about. I'm going to list out what it means, based on my reading of their documentation[1] and on what worked for me. It includes some essential preparations that you MUST TAKE if you have access to your account. This is to ensure that all your devices are verified, that they all have access to all encrypted messages and that you don't ever get fully locked out.
DISCLAIMER: I have no direct experience with Matrix or Element code base. I have no affiliation with them either. So this isn't official and a few errors can be expected. Please let me know if you notice any. I will keep this corrected for as long as I can. Otherwise I'll add the errata as child comments.
1. Matrix has TWO levels of authorized access.
2. The first level is where you enter your regular username and password, that's unique to your homeserver (like matrix.org). It looks like OIDC/OAuth2 to me. On being authenticated at this level, your client (Element, Fluffy, Cinny, etc) is able to access the messages meant for you. At this stage, you're able to read any unencrypted messages. Most community chatrooms are unencrypted by choice.
3. The encryption used for your encrypted messages is end-to-end. Their encryption keys are named 'room keys' in Element (there are several of them). They are not directly available to your homeserver (otherwise, it wouldn't be end-to-end). Similarly, there seems to be an 'Identity key' (presumably a cryptographic private key that makes you the owner of the account and is needed for some account operations). This key is also not directly available to the homeserver.
4. The client app just logged in and the server doesn't know your room keys or ID keys. They're known only to your other clients. So now you need to transfer them from those clients to the new client without divulging them to any servers in between. Once that's done, your new client will be able to decrypt all your encrypted messages and join those discussions.
This process of transferring your room keys and the ID key to your new client is the second authorization step known as 'Verification'. (I presume it's called verification because your new client can now prove its authenticity using your ID key.)
5. Verification can be done in three different ways. The first two are manual methods and are rarely used. We will discuss these two later. The other is using a 'verification request'. This is straightforward. Your new client requests the already verified clients attached to your account for your room and ID keys. Any verified client can respond. However, it needs to first verify that your new client is really yours, and not someone who used your leaked password or hacked your account. To do this, the clients currently offer you two methods - one using a QR code and the other using a sequence of icons.
If you select QR code, your verified client will show you a QR code that you need to scan with your new unverified client. Since it proves that both clients are in the possession of the same person, the verified client then proceeds to transfer the keys to the new client, finishing the verification. Now if you chose the Icon sequence instead, then the verified client creates a random sequence of icons that it sends to the new clients. Then both the clients display it to the user. If the user accepts on both device that the icon sequences are identical, it's the required proof that both clients are with same person. The rest of it is the same as before.
6. So far, so good. If you were able to complete till step 5, the new client is verified and now you can carry on with your business. Now we address the situation of what happens if you are not able to do any of these. Just assume that all your clients got logged out together for some reason (yes, it has happened before). Now none of your clients or the server has any of the room keys and the ID key needed to prove your ownership (crypto authn) or access your encrypted messages, even after you log back in. The only solution is to load the room keys and ID key from a backup. This is why it is IMPORTANT TO BACKUP your room and ID keys.
7. There are two ways to backup the room keys and the ID key. These two methods are also the two manual methods of verification that I mentioned above. The first method is to back up the keys on the homeserver itself. It's convenient because all your clients can access them at any time and keep the room keys updated as they change or new ones are added. This feature is called 'Key Storage' in Settings/Encryption tab of Element. It's enabled by default. ALWAYS keep it enabled.
You may be wondering how it can be end-to-end encryption if the private keys are stored on the homeserver itself. If you're, then you're correct. They are stored in encrypted form on the server key storage. The decryption keys for that is available only to the clients. So while the server holds the keys, it cannot access any of them.
8. Here is your first opportunity to do something about accidental losses. The decryption key for the key storage can be downloaded and preserved in a secure manner. Perhaps write it down on a paper or put it in the password manager. This key is called the 'Recovery key'. You can download or change it from Element's Settings/Encryption tab. ALWAYS BACKUP YOUR RECOVERY KEY.
You can use the recovery key instead of the QR code or the icon sequence to verify your new clients. There are two differences from the previous method. The first is that you can enter the recovery key directly into the new unverified client. The verified clients are not needed here. The second is that this is possible even if all your clients gets logged out. Again, this is why it's very important to BACKUP YOUR RECOVERY KEY!!
9. Besides setting up server key storage, you can take one additional step. This is the second manual method of verification. You can download and backup all the room keys and your ID key on your local system. This option is available as the 'Export keys' button on the Settings/Encryption tab. When you do so, you'll be asked for a password. This password is used to encrypt the file with all those keys, so that they don't sit unencrypted on your disk. This file can be backed up as such, but you can encrypt it again if you prefer.
You can use these keys also to verify your account. You'll need the above password to decrypt the keys file. However, this method still has one big CAVEAT. I suspect that the keys file need to be updated regularly, since there will be new keys when you join rooms. So if you use this method to validate, it's likely that your client won't be able to decrypt the rooms/messages for which it doesn't have the copy of their key. But this is still worth doing, because it contains your ID key which can be used to verify all your devices again as a last ditch measure (if your homeserver happens to quit or something).
10. Now let's just say that you're a careless ### who didn't do any of the above. You still have the option to nuke it! That is to Reset your cryptographic identity from Settings/Encryption. I presume that this just discards all your previous keys and creates a new private ID key. Since all the clients can now access this key, your account is verified again. But you will not be able to access any of your previous encrypted conversations. And the homeserver helps you along by discarding all your previous conversations, room subscriptions and settings. So now you're left with a cleanly empty account. But hey! You have your verified account back!
So, in summary:
1. Always verify all your clients
2. Setup server key storage (it is enabled by default, don't disable it) and backup the recovery key
3. Backup the room keys and ID keys on your local system. Use it for recovery/verification only in the worst case
4. Don't forget the password you used to encrypt the above file (just sayin)
NOTE: I intentionally left out some crypto details from the above (like session keys) to avoid making it any more complex. If you're unhappy with those omissions, please just leave a comment.
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.
> 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.
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.
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
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.
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.
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)
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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).
maybe because of limited budget and more urgent issues? who knows
And what could be more urgent than this?
building a more flexible solution for blocking content, rather than hardcoded rules like "no images": https://matrix.org/blog/2025/04/introducing-policy-servers/
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?
having a usable technical foundation, staying financially afloat
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.
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.
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.
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?
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.
The image spam I got was on their official server.
I still can not blacklist homeservers by domain instead of ever changing IPs. Great stuff.
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.
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
https://news.ycombinator.com/newcomments
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.
“Compliance” with what?
Great question! Next question please.
(I have no idea that’s the BS I was told when we left slack for teams)
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.
> 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.
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.
The extension I just mentioned is E2EE.
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.
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.
> 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).
Anecdotal but running a server with multiple bridges for multiple years. Had such issues initially but none recently.
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.
> 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).
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.
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.
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.
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.
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".
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.
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.
> 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.
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."
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.
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
Hey, I've been there!
https://web.archive.org/web/19991128144800/http://sonicity.c...
https://web.archive.org/web/20010223171430/http://www.sonici...
speaking as Matrix’s lead maintainer: we are focused on it powering decentralised and encrypted whatsapp (or teams) alternatives.
unsure what makes you think we want to build a next-gen tcp/ip, but can I have some?
When you leak that much metadata, it's disenginious to call it encrypted.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
Pretty crazy, right? It almost seems like a honeypot
I tried implementing a Matrix bot a few months back, and it was an absolutely miserable experience, since Device Verification/E2EE was not working with any of the available open source Python implementations I found.
I then stumbled upon their internal Rust SDK[1] that they use for Element X, which is actually quite nice, and even has FFI bindings for Python and Kotlin[2]. Unfortunately the documentation was really lacking at the time. I managed to put something together with the help of an LLM and the source code and examples to find my way around the various APIs, and it actually works with emoji verification and E2EE (although there are weird bugs around synchronization, but that's probably just an API misuse on my end).
It seems they've improved the documentation since and even provide a reference client[3] to see how things work.
[1] https://github.com/matrix-org/matrix-rust-sdk
[2] https://github.com/matrix-org/matrix-rust-sdk/tree/main/bind...
[3] https://github.com/matrix-org/matrix-rust-sdk/tree/main/labs...
What is verification? What does it involve doing? A lot of information on why it's useful, but how is it implemented? I hope it's not something like the Play Integrity API, but with no information to go on, I can't say either way.
https://element.io/en/help#encryption-device-verification
> After Alice logs in on a new device, she uses her cryptographic identity to demonstrate to Bob that the new device genuinely belongs to her, rather than being added by someone else with access to her account. She can do this either by entering her recovery key (which gives the new device immediate access to her cryptographic identity ), or by carrying out an interactive verification from an existing verified device.
So is this like the Signal PIN which is required when installing on a new device? If you forget, the cryptography changes and old contacts are warned that signatures are rotated, right?
Yes, the purpose is the same but the UX is a bit different.
Quite. I have yet to manage a verification between clients.
I have had all variations of clients ignoring requests, reporting requests only for the requesting client to ignore the response. Both ends quitting declaring that the other end cancelled, asking for the other end to input a code while the other end shows no interface for doing so.
It marked the end of me using Matrix as a platform. I'd go back to the old IRC channels if there were anyone still there.
I have never failed at that. Worst case I type my recovery key and done.
I still have my encrypted messages available from 2020
People still use IRC
If by bit different you mean absolute nightmare then yes
imho it's the best out there
- no unnecessary coupling to a phone client
- no coupling to any other client - I can just put my recovery key in and be verified without having to deal with other apps.
More like the safety number / QR code.
The numerical Signal PINs are basically just for when you bootstrap your Signal identity from a telephone number.
Except Signal PIN appears to be trivial to bruteforce for Signal itself, unlike this properly secure verification.
In this case, it's what you do when signing in from a new device (or browser) to attest that it's yours. It avoids warnings to you and your contacts that a device has gained access to your account without your approval.
It involves doing one of these things:
- Comparing a short sequence of emoji on each device and confirming that they match.
- Using one device to scan a QR code displayed by the other.
- Entering a recovery key (a line of text) that you were given when you first set up the account.
Pretty quick and easy in most cases, although some clients can be glitchy in this area and require trying again.
(Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
> Pretty quick and easy in most cases
The experiences reported here seem to say otherwise...
As others, anyhow, I haven't tried again recently
> (Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
I last tried Element about six months ago, but for years using the recovery key was either impossible or close to it, and mostly just for idiotic UI mistakes that were never corrected (something like you had to enter the key where they wanted the passphrase or the opposite).
To my recollection the version from six months ago worked better in that regard, but it was still asking to enter the passphrase where you actually had to enter the recovery key.
I think current Element versions accept either a recovery key or recovery passphrase in the same input field, so there's no getting it wrong. Since you seem focused on UI, it's worth noting that Element X (their beta mobile app) has a greatly simplified interface; their team clearly has been working to make it easier.
Also, other clients exist.
For whatever it's worth, I've been using Matrix for about five years, including some of its roughest times. I seldom see errors these days, but I can understand how folks who were frustrated with earlier iterations would still be soured to it. Such is the nature of an ambitious work in progress, I suppose.
I use it because there is nothing else with the combination of features that are most important to me, and because (despite my gripes) I can see slow and steady improvement. I think it's moving in the right direction overall. I could picture introducing family members to it once Matrix 2.0 is released and the implementations shake out any early problems.
I tried the current Element and Element X.
In short, the passphrase works with both and the recovery key with neither, specifically:
Element classic has two separate fields; if I input the recovery key (in the correct field), I get told "Backup could not be decrypted with this PASSPHRASE: please verify that you entered the correct recovery passphrase."
That's how it was the last time I used it, and if I'm not mistaken it's been for years.
Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
Funnily, by the way, it seems that with Element X you can't do anything if you don't manage to get verified, there just doesn't seem to be a way to skip it.
Furthermore, after signing out from Element X I'm unable to even just logging back in, I get an error ("Sorry, an error occurred") after I enter the credentials; even after clearing all the app's storage. Very, very weird.
The new login-via-browser is pretty problematical, by the way, I could only make it work with Chrome.
> Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
I have just tried this on Android.
I am directed to
1) "Device verified - Now you can read or send messages securely, and ... - [Continue]"
2) "Help improve Element X ... [OK] [Not now]"
3) list of chats
Element X Android fyi. No problems logging in using Firefox.
Since you didn't share all the details of your tests, I'm having trouble picturing how I could try reproducing what you did. (That's okay; I'm not an Element maintainer.)
However, a couple of things occur to me:
- No Matrix client that I know of supports setting both a randomly generated recovery key and recovery passphrase on the same account. So in order to test both, you would have to use a separate account for each. If you tried to test both on the same account, it's expected that one of the two would be rejected.
- You didn't specify a platform, but since you wrote "Element classic", I guess you must mean Android or iOS. I used Element Desktop / Web to set up my accounts, which could explain why I saw different prompts.
I hope you reported the error message referring to a passphrase when a key had been entered. I imagine that could leave the user wondering whether they had made a typo or the app had misinterpreted what they typed, which would not inspire confidence in it.
> I can see slow and steady improvement.
That is true, but what weakens my confidence is that the Element/Matrix team often doesn't present it that way. So much communication from them is about how it's amazing and great and the best messaging app in the world. If they presented it more like a typical slow-growth open source app I think they'd garner more goodwill. By setting high expectations they increase the likelihood of disappointment.
Maybe I’m missing something but why does this service need this process while Discord or whatever don’t?
Discord does not do any sort of end-to-end encryption. All messages are fully readable and writable by Discord. Discord decides whether you are who you say you are, and all clients trust whatever Discord says to be trustworthy.
That's easy, Discord is spyware.
> The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.
honestly it's the best thing ever they have done:
- I have heard of someone who failed to use Matrix, because he got frustrated of having not a secure enough passphrase
- people don't choose secure passphrases
- it provides options making things more complex (especially when guiding others)
- you know you won't memorize it, so you are more likely to put it down
1. Generating a random key by default (but still allowing advanced users to prefer a passphrase) would solve your "secure enough" problem.
2. Better yet, a "secure enough" passphrase could be generated by default, à la Correct Horse Battery Staple. A user wouldn't be forced to choose one.
3. When adding an option, interface complexity can be avoided by simply not showing it by default, or by placing it off to the side in collapsed state where it doesn't draw attention.
4. If you're worried about people writing down a passphrase, you should be even more worried about a string of 50 random characters.
That last one is important. Nobody is going to memorize a random key, which means everyone has to write it to a file (or painstakingly write it on paper) for long term storage. When verifying remote devices, they also have to get the key to the other devices, so they are likely to use copy/paste, which will put it on at least two devices' clipboards, where it will be available for harvesting by nosy apps/websites or accidental pasting to random ones. They also have to figure out a way to transport the key from one device's clipboard to another, which might be email or SMS or some other insecure channel that they're accustomed to using. Or in the unlikely event that they choose paper, they have to painstakingly transcribe it again at the other end.
In other words, forcing the use of a random key does not increase security vs. a well-implemented passphrase system, but instead pushes responsibility for security out of the software and into the hands of people who aren't trained in it. Inviting more big mistakes.
A passphrase would avoid most of those exposure risks by not having to be written down or copy/pasted or sent through insecure channels. And with the right UI, it wouldn't be more complex to use or less secure.
Fortunately, Matrix supports passphrase-derived keys at the protocol level, so client developers who understand how to implement them well for humans can still do so. I hope Element's product managers will come around eventually.
I was afraid of that as well given the wording but, no, it's nothing to do with third parties at all. Just when you log into a new device, you confirm it on your old device so it knows it can transfer encryption keys for old messages to the new device
This has been in Element/Matrix since forever and I found it the easiest verification mechanism of all the encrypted messengers I've tried. I'm not surprised they're making this part of the standard process, but the wording in 2025 is... unfortunate. Or perhaps that adjective should be applied to the rest of the world since it's not the Matrix Foundation which changed. For the reader to decide ^^
In the current state, it's basically just a self verification. When you use a new device it shows a series of emoji on each device and asks you if they're the same, then the device is verified.
You can also use a generated security key to verify as a type of second-factor.
Thankfully, no, it's not anything evil like Play Integrity is. The simple explanation is that the first time you log in to an existing account from a new device, you need to go on one of your old devices and confirm that the new one is yours.
I’m a server admin and I still couldn’t tell you why when I sign new endpoints in and verify for cross-signing it still also asks me for a recovery key.
For encrypted search on desktop it has to fetch batches of messages and this is configurable in settings. It just had a number? what is that? how large the batch is, how many ms? no clue! good thing we can’t do encrypted search on mobile/web.
In my case, it transferred my willingness to self-host a chat server to something else.
(I think) It transfers (access to) your keys for end-to-end encryption between devices.
Yeah, I was wondering this as well. At the very least, this appears to be an Element requirement that was just enabled by a Matrix protocol update, so moving would be possible, but afaik Element is extremely popular as far as Matrix goes.
[dead]
Despite all the gnashing of teeth in this thread, this seems reasonable. This seems to only prevent you from logging into your account, with only a password, NOT verifying it (by dismissing all the prompts asking you to do so), and then sending (and receiving new!) encrypted messages anyway. I've never used an unverified Matrix account in the 6 years that I've been an active user. Verification used to be a bit finicky, but it's pretty seamless now. And once the QR code login stuff is better supported, it will be dead easy.
> Despite all the gnashing of teeth in this thread, this seems reasonable
I empathize a lot with the negative experiences shared in this thread.
I think the problem is that every little decision in Matrix might be reasonable to the people who have complete context about the decision, but all of the churn and rough edges have added up to a very bumpy ride. Not only that, but it has been a poorly communicated and documented ride as many in this comment section can attest.
I suspect all of these issues and changes feel like no problem to people who are active in Matrix every day and have a support network to chat with where they all get through the issues by sharing tips and info. For the rest of us who are casual users who only occasionally log in it feels like I’m rolling the dice every time I have to use it. Some times it works like it did last time, some times I have to go on a 30 minute adventure with Google and play games across devices to get it back into a working state again.
> Not only that, but it has been a poorly communicated and documented ride as many in this comment section can attest.
The guides are written for cryptographic infrastructure nerds and not regular normal users that have a habit of forgetting their own passwords after six months. Not to mention the fact that the Element UI tends to churn a lot.
I didn't even know that they deprecated creating new passphrases, and that's what I was telling my users to do!
Doesn’t verification also exchange encryption keys, letting you decrypt messages from before you logged in? I remember that being a huge issue where you would see unable to decrypt messages.
Probably just bad UX to let people skip the verification step.
Yes. If you don’t verify, every conversation is empty.
But it also asks for recovery key and complains about it being out of sync until entered even if you do the verification step! Entirely possible to only get a partial recovery of messages until this is entered.
That's not normal. It doesn't happen on any of my accounts or clients. Verification takes a moment if you're in a lot of rooms, but it exchanges all keys.
been a pretty reliable issue when I've set up a new device. Whatever keys the client is getting, they're apparently not useful.
(This general flakiness of features just sometimes not working as they should is probably the main reason I haven't tried to recommend friends to switch to element)
cannot confirm this either
one method of verification suffices (be it recovery key or using a different device)
> Doesn’t verification also exchange encryption keys, letting you decrypt messages from before you logged in?
if you use key backup
> Despite all the gnashing of teeth in this thread, this seems reasonable
I think it's not the requirement itself that's the crucible of discussion but the issues are rather that the blog post should have explicitly defined what verification is in it's second sentence and that matrix/element still is barely useable even for reasonably technical users.
> barely useable even for reasonably technical users
My entire family (including my elderly mother) would be very interested to learn how technical they are!
Scale matters. Once you achieve over a hundred of users, you got all the random bugs, and glitches appearing, and you can't guide everyone personally across UX issues. This is when lack of decent documentation, unpolished UI, and even the fact that it uses its own terminology (like "spaces") starts to hurt. I don't mean Synapse/Element combination is bad, but so far it's not great either.
Argue with the people in this thread that made this argument.
I use Thunderbird as my main Matrix client since it's already always open on my PC and is Lightweight. Whenever I open Element or any other client (Nheko, etc.) they all complain about each-other being unverified.
Clicking verify in any client does nothing. No popups in any other clients - doesn't ever seem to do anything. Sometimes Element will pop up a QR reader but there's no QR presented in the other clients. The UX around Matrix is a nightmare.
Not sure how often they update these pages, but Thunderbird is still listed as beta on matrix.org clients page [0], and I remember trying it out some time back and it was indeed very beta (maybe not even beta). It didn't feel like it was getting much maintenance so I stopped using it. I think it's fair to expect bugs in beta releases.
I am in the same boat. It is ridiculous and shows no signs of improving.
I tried out an alpha client once & can’t get the stupid pop-up about unverified devices to go away now. Another client didn’t have the verification flow even set up—this will end up being yet another barrier to entry for new clients. With the clients (yes, multiple) crashing often, constantly syncing for ages, & feature sets not on parity + without graceful fallbacks, I do not like the Matrix client space (nor the server space, but that is a different topic).
There has never been a better time to (re)embrace XMPP as your decentralized chat option. The clients are less buggy, handle missing features gracefully, & best part is, not being built on an eventual consistency model, you don’t have the constant syncing issue with delayed messages. If you wanted you could make an XMPP client in a day since the base spec is small/simple—& features like device verification would be seen as mandatory in the base specification.
I like XMPP and I use it with my family (with the Conversation client) but the web interface (converse.js) if pretty rough.
I would like to replace Matrix at work with an XMPP server, but to convince my colleagues I would have to show something better than that :/
> I tried out an alpha client once & can’t get the stupid pop-up about unverified devices to go away now.
Open app with device management (e.g. Element Desktop) and remove the unverified devices you don't intend to verify.
Regarding XMPP: With the lack of Cross Signing, key backup and consistent storage of messages, it can't be expected to provide the convenience Matrix does for the foreseeable future - just my personal opinion. The matrix-rust-sdk should it also make easy to get started with a client.
I used to consider myself a HUUUGE matrix fanboy....while i still respect what the teams have done over time, I have been feeling a little, i don't know, deflated maybe? Maybe its the UX/UI aspect, i don;t know...i have not run a homeserver since like maybe 2019 or so? But nowadays, i have less interest in running a homeserver, and as far using the various clients: meh. Element feels bloated, and others either might be more snappier but might have an odd bug, or don't implement all features that might be expected, etc.
So, last year i tried to play briefly with Prosody server to re-acquaint myself with xmpp...and it wasn't so bad. Not as great as i expected for this day ana age, bbut not terrible. The server setup felt like i needed to study a bunch of different docs...and ultimately was smoother than expected....so i think documentation is either outdated, or was written a little less clear than expected. That being said, the low resource usage was ridiculously pleasant compared to matrix homeserver! The fact that an xmpp server allows for such scalability on such low resources is a great testament! And, that was prosody, which some folks state is not even as performant, scalable as ejabbered....so they say...so wow, that's impressive if that's true. Regardless, xmpp servers that can run on such low resource hardware but enable so many users to chat...is quite awesome!!! The client side of xmpp was a different matter; i wasn't so happy. I blame myself because maybe there might have been plugins that maybe i didn't install correctly on server side, i don't know...but it felt not as easy as i expected. The clients were a little disappointing; again not terrible but not great.
Maybe i'm spoiled? Or, maybe i did too much wrong? But if that's the case, the maybe there's an opportunity for better documentaiton? I don't know....i really like both matrix and xmpp because both live in the realm of free and open source software.....so i really want both or either to succeed. I want to live in a world where we are not beholden to only proprietary options, like whatsapp, crappy sms/text messaging, etc. I want to give props to all the folks who made and maintain all aspects of xmpp...as much as i am whining, i don't want to take away from all the hard work that they have freely given; super props to them!!!
What i really want is a modern, free and open source version of IRC, with plenty of modern features (E2EE, file uploads, presence detection, etc.), decent desktop and mobile clients, easy server installation and management, and said server-side software would ideally not need such beefy hardware to run...Or, is my wish too far fetched?
One thing I would note on the client side of xmpp - there does seem to be a lot of work happening under the surface. Snikket is working on an SDK to streamline modern client development. There are a couple of alpha stage clients written on it already, and maturatoin of the SDK should lower the bar for pushing clients forward.
Also independently, Movim keeps advancing and Libervia is doing a ton of cool work. I'm sure I am missing others.
I had only heard about Snikket as I was spinning down my xmpp experiment... maybe I can take a look nowadays (including moving and others). Thanks for sharing!
> can run on such low resource hardware
This is what frees a barrier to decentralization & actually owning one’s data. A few of my friends are now running their own single-user or small XMPP servers since it doesn’t use much in terms of resources or storage in comparison.
> The server setup felt like i needed to study a bunch of different doc
I believe this is what the Snikket project is trying to be. That said, XMPP servers are used for a lot more than just chat which is why most of them don’t have good defaults for merely chatting with friends since that isn’t the only or a generic enough use case (XMPP is behind Zoom, Jitsi, Fortnite, etc.).
> The clients were a little disappointing; again not terrible but not great
True. But I appreciate that there are many options & most features gracefully fallback even on TUI clients (like ‘reactions’ just being a message reply with a single emoji). If Element adds a feature (like polls), the other clients, the new feature just doesn’t show up. For a web client, the NLNet funding is really giving a boost to Movim as a reasonable alternative to Discord that is self-hostable & federated so users—taking back the meaning of “join my server” to literally mean someone’s server & without needing to create another account just to join that server.
As for the wish… this is what XMPP MUCs are—IRC with niceties like moderation, optional encryption, & file uploads. You said yourself the resources for servers is small & for your stated use case, most existing clients can handle being IRC+features while also not being centralized unlike IRC.
> ...that isn’t the only or a generic enough use case (XMPP is behind Zoom, Jitsi, Fortnite, etc.
Great point! I forgot that xmpp can/is used for other use cases that are not just chat.
Also I guess I should be a little more forgiving about the MUCs, and client features in particular because you are right that fallbacks tend to be graceful.
I think we all want that. The fact that it doesn't exist is an indicator that it isn't trivial to build. All those modern features are at odds with performance.
> ...it isn't trivial to build. All those modern features are at odds with performance.
I suppose both points make sense!
FYI: here are the videos of the latest matrix conference: [1]. I think there's a lot of interesting stuff going on!
also, instead of hosting your own server or using some (more or less well-financed) public servers, you can simply throw some money at [2] to pay for hosting for your group of friends or family or whatever. (not affiliated, but I like the idea)
[1] https://media.ccc.de/b/conferences/matrix-conf [2] https://etke.cc/
This basically means that Matrix will stop working for my parents and other family: the only people I use matrix for. We started during the pandemic for the video chat element. But Riot.im/Element.io changes to the homeserver over these many years have made it so none of our accounts properly verify. I can't even get my account to properly verify and I'm a huge nerd. We put up with it because of inertia and chat still working fine. But this? I guess it's the end.
Riot.im/Element.io really knows how to shoot themselves in the foot.
I love Martix/Element, and about the only thing I don't like is that I need moar features!
We have a space with several rooms for our FOSDEM devroom, it's been working flawlessly, including for all our video calls with many participants. Thanx Element team!!
I have a private matrix server for a few friends. Whenever someone logs on with a new device or client it lists them as being unverified. Eventually it goes away. I really have no idea at what point verification occurs.
They verify their device. Usually means opening Matrix on a other device, clicking the pop-up, and scanning a QR code or matching emoji. One device signs proof of verification of the other and exchanges encryption keys so the new device can read encrypted conversations.
Unverified devices are indistinguishable from a hacker logging in through credential stuffing/password leaks until verification is done.
It's a process similar to adding devices to Signal or WhatsApp, except with Matrix you can still log in without having physical access to another device. Useful if you only ever visit unencrypted rooms perhaps.
I am not sure the founder is reading this. I tried googling but couldn't find it - I recall the hn handle being something like Atheon. Not that hn sends mention notifications.
Matrix is something that had my eyes lit after years or being burnt/disappointed by communication apps (Signal included). I had converted/migrated a lot of people to it (I mean of course they didn't "convert" but they had it and were replying to me) from a country where WhatsApp is essentially "basic need" today – along with water, air, food, and shelter and that too in an era when it was not even stable. After that I just didn't know what the hell happened. Matrix, Vector, Riot, Element – things just kept happening. App was never an end user app and it became very clear that it was not the intention either. To be honest it didn't look like a replacement for something like Slack or something like IRC either. It was trying to become something which it seemed/seems has no end goal or destination i.e a clear roadmap. As if the goal is to develop cool features and just put them haphazardly together which I am afraid often results in something Mary Shelley wrote.
I still login from time to time and I don't understand what is happening. Something I see this notification, something that, sometimes I see there's a message pending, sometimes I see I have a chat recovered (old/stale; because there's no one I know uses it anymore), sometimes I see a certain chat is not recovered because some verification or decryption (or something) failed, sometimes I see (or understand it) that I might another active and verified device to recover certain messages. I had created some groups and of course they remain abandoned - but no, few og them were filled were porn and the kind of some was scary because that vector/riot/element account is connected to my real ID including the email and I was scared shitless. I tried deleting them but I couldn't. Next time I will try harder or just try to make it private after kicking everyone out. I will still keep the account. Never say never :)
I sadly have moved from writing enthusiastic to sad to disappointing comments to not even paying attention to it when there's a Matrix/Element news now. I think I don't even notice it. I think that's the worse kind of eventuality in this context. Anyway, I wish you all luck and I am sure you all know what you are doing.
> Matrix, Vector, Riot, Element – things just kept happening. App was never an end user app and it became very clear that it was not the intention either.
Element X definitely is.
"The authenticity of this encrypted message cant be guaranteed on this device" both sides verified, but this still randomly pops up, what happens then? will i lose those messages in the future?
No, it's just a warning that your client can't prove that the message was really sent by that sender. These will eventually go away once https://github.com/matrix-org/matrix-spec-proposals/pull/404... lands.
I've been using Delta Chat with a lot of success. It is easy, it works, bots are easy and the concept is improving. They even plan to have forward secrecy. So, give it a try. If you explored it a long time ago, try again, many things have improved in that ecosystem.
Yeah it's a lot more "just works" than Matrix, still some limitations but improving quickly.
I really want to love matrix but it always turned bad/broken at some point. I switched to XMPP. No issue ever, but the clients are not very good.
Ugh.. I loved Matrix but I'm starting to hate the way they force these things through. Also last month they removed the categories (People, Rooms, Favourites) from Element Web just like that. Making it very hard to use as I use it. I had to roll back to an older version. They seem to be focused on whatever commercial or consumer experience but they are ruining it for power users.
My matrix server isn't even publicly accessible and users can't sign up. I don't federate with the network. So these issues are irrelevant to me. There should still be a way to turn it off. Because many of the bridge bots I run can't verify.
I don’t use Matrix, but if it’s E2EE, then how is it possible in the current design for an unverified device to even exist?
It has the keys, or it doesn’t, right?
Matrix has E2EE support and many clients are pushing it as the default. But it also supports rooms that are only encrypted in transit.
That's correct, but E2EE also allows for unverified devices[0]. Key distribution and device verification are separate issues, and the former doesn't enforce the latter until April 2026 as they've announced in the HN article.
[0] https://matrix.org/docs/matrix-concepts/end-to-end-encryptio...
You don't have to use E2EE if you don't want to. I personally don't because I don't care about it, and it adds extra difficulties to the experience.
If you don't need e2ee, are there features that make matrix better than xmpp?
Both XMPP (via OMEMO) & Matrix use libsignal for double-rachet encryption—so they have the same encryption properties. The biggest practical differences for the average user in my opinion is XMPP has a separate concept for DMs (not a 2-user room with encryption like Matrix), XMPP allows encryption to be both enabled then later disabled, & Matrix offers better resilience as messages & attachments get synced to all servers a room (which has a massive downside of resources, storage sizes, & moderation; if a server goes offline, you still have a history of the chat but if someone shares something explicit, such as CP, it will propagate thru the network & there is no way to delete it across nodes).
One of the better comparisons out there: https://www.freie-messenger.de/en/systemvergleich/xmpp-matri...
Lots of open source projects have matrix servers and not XMPP servers. Some bridges don't have XMPP equivalents (and some bridges don't have Matrix equivalents either).
XMPP also does E2EE of course, though I've found it to be a worse experience on most clients compared to Matrix.
decentralized rooms, built in video conferencing, consistent chat history storage
This is a good thing. It is (was?) all too inviting to leave clients unverified because verification is (was?) hard and annoying.
The code examples I'm aware of for clients using the first-party library also leave verification and E2EE out, FWIW.
From an outsider's point of view, what is this "verifying"?
Because it sounds like "we'll put them in a database so we can sell it" to me...
cryptographic process to poof that the devices you use in fact belong to you (as cryptographic identity)
To poof to who?
Where is that data stored?
What happens if I'm on holiday in Paris and drop my phone, which is the only device I have with me, in the Seine?
Sounds like more passkeys security theater/inconvenience to me.
To your contacts; if I understand correctly, the public keys are uploaded to the server
> What happens if I'm on holiday in Paris and drop my phone, which is the only device I have with me, in the Seine?
1) use your recovery key (to recover your identity (prooven by private keys) from the server) - I believe it only works if you enabled server side key storage
Or
2) create a new identity (contacts will be notified)
Or
3) wait until you have access to another device again
Source of truth: https://spec.matrix.org/v1.16/client-server-api/#cross-signi...
One of the super confusing things is that even if you only use a single client it can be verified or not.
That's confusing even for very technical people; because, it simply doesn't make sense.
Saying "verified or primary client with recovery keys generated" seems too long, so they should just say something like "less secure" on the "unverified" sessions.
The problem with Matrix adaptation has always been E2EE, or rather, the annoying implementation of it
Last time I used Matrix for our internal team notifications were beyond broken and we moved to Zulip, verification and authentication were also very funky at the time, I don't dare to try it again.
I want to switch to SimpleX Chat[1] but at the moment there are issues with battery usage on android devices because of the way notifications are done. I hope this[2] or some other solution get merged soon even if there is a slight impact on anonymity.
[1] https://simplex.chat/
[2] https://github.com/simplex-chat/simplex-chat/pull/6205
I had a more pleasant experience with SchildiChat hosted on a web server than the desktop Element clients.
I don't like the way groups/chatrooms are displayed to be honest. Its confusing. It feels like its trying to get away from the "server room/#somechat" model that works well with IRC and even with trendy current products like Discord.
Is this the ritual of getting together with a person and checking that their fingerprint match what you see on the app?
If this is that case what will happen is that people will start verifying everyone (because they might want to text to strangers that they can't bother verifying because the stakes are so low) and so verification will lose all meaning.
It is not; I know we don't read articles here, but...
Isn't this how TLS itself already works? "trust on first use"?
Not in current practice. That is why you have to get a certificate from a trusted CA. If your CA isn't in the browser's cert database they will reject the connection even on the first time. If browsers allowed TOFU we would still be able to use self-issued certificates, without manually distributing certs to anyone that uses your service.
SSH is an example of TOFU.
> we would still be able to use self-issued certificates
You still can... it just displays a warning message on first use, as does ssh.
With PKI you're trusting a certificate chain up to a CA you already trust, by way of your OS or browser vendor.
A domain can layer on HSTS to that, which directs clients to additionally refuse to trust a new cert for a domain until the one you currently trust has expired.
That’s not what HSTS does. It asks the client to remember that you want to only use TLS for that domain and refuse to use unencrypted HTTP in the future.
"Now the end-to-end encryption will leak into the UX even more and you better like it"
I'll say it again: E2EE will never become mainstream unless someone somehow manages to implement it such that it's completely transparent to the user while keeping all the features that people have come to expect from IM apps, like server-stored conversation history or support for multiple devices. By "completely transparent" I mean that the user doesn't have to do any extra actions whatsoever to make it work.
If that's true, then E2EE will never become mainstream. Consider this scenario: "My phone got lost/stolen/broken, so I just got a new one. I haven't logged in to this app since I got my last phone, so I forget my credentials for it. I'll reset them through my email. What do you mean my conversation history is gone?"
That's not really far-fetched. If you can get your conversation history back in that scenario, then so can the server operator so it's not real E2EE, and if you can't, then by your statement it won't become mainstream.
> If that's true, then E2EE will never become mainstream
Yes? :)
Given the choice, the vast majority of people would pick convenience over the kind of security that requires this much effort.
I more or less agree. And I also agree with the other commenter who says this may mean e2ee will never become mainstream. I think a lot of e2ee enthusiasts don't realize that the overwhelmingly most important feature for a messaging system is "when I log in, I can see all my messages". If there is a chance of that not happening, you're going to lose a lot of users.
I think there's the potential for a slight middle ground, but it would involve giving up a lot of the e2ee bells and whistles that privacy enthusiasts enthuse about (like perfect forward secrecy). You could image for instance a system where you have a single e2ee password and your data is encrypted on the server with that password. When you log in, you supply two passwords: your login password and your e2ee password. Then you have access to everything.
This tends to irritate people on both sides, since you can still lose your messages if you forget your e2ee password, and your privacy guarantees are also weaker, since the e2ee password can be a single point of failure that allows someone to read your messages. But people already rely on this level of security in other contexts. For instance, some cloud backup solutions encrypt your backup with a single passphrase. People are okay with having one password to unlock their entire hard drive's worth of data but not with one password to unlock their chat history?
I think it's worth exploring the space of e2ee solutions to find something that finds the balance between the levels of privacy and convenience that most users want. The thing is that existing apps that tout e2ee often do so to appeal to hardcore privacy advocates or people like dissidents in authoritarian states who are at risk of death if their messages are discovered. This level of security simply isn't a concern for the average person, and so they're not willing to take on the inconveniences that go along with it.
> E2EE will never become mainstream
iMessage and Whatsapp are both mainstream.
Technically they are, but neither of them fits the strict definition of a E2EE messaging app, while also still hurting the UX.
Whatsapp is very insistent about backing up your messages to cloud services without encryption. To use it on desktop, you have to make everything go through your phone. And, afaik, you still can't transfer message backups between Android and iOS.
Even disregarding the extreme gatekeeping, iMessage relies on Apple managing your encryption keys so there are no confidentiality guarantees. Apple can, at any moment, give themselves a key to decrypt your messages.
Both Whatsapp and iMessage are proprietary, so it's also the case of "please trust us that we've implemented it the way we claim we did".
> iMessage relies on Apple managing your encryption keys so there are no confidentiality guarantees. Apple can, at any moment, give themselves a key to decrypt your messages.
It relies on Apple device managing your encryption keys, no? Which, yes, Apple can still access if it really wanted to simply by virtue of being able to push an iOS update that does that. But the same exact vulnerability applies to any app running on your iPhone.
iMessage has worse UX than signal for key verification, but does support it. https://support.apple.com/en-us/118246
>Both Whatsapp and iMessage are proprietary, so it's also the case of "please trust us that we've implemented it the way we claim we did".
This is simply not true, any serious analysis of Signal would be performed on the binaries and not the source code. Having access to the source code does not make it any easier to discover well-hidden backdoors, but it is possible to exploit e.g. compiler behaviour in a way to create a backdoor that is essentially impossible to detect by reviewing source code.
Access to source code might very well make it easier to discover non-intentional bugs, but does not solve the problem of trust.
I mean we’re there for Signal. The parts that suck still are regarding access/retention of old messages which is an area Matrix is ironically slightly better about. But Signal we don’t need to think about verification, at worst it says this asshole has a new identity and then I have to tell them I’ve reset my iPhone for the 4th time this week…
Normal users do find retention important even if privacy/security minded users find value in ephemerality.
Can you use Signal across multiple devices?
Officially it supports linking other devices like their desktop app as a secondary. I currently use this to link into signal-mautrix on my matrix homeserver. This way I can access signal from multiple phones and multiple computers using a matrix client instead.
But you still need one "primary" device and it has to be a phone, right? That's different from Matrix where you can have arbitrary devices that are all on an equal footing.
Yes. And, annoyingly, when you only use Signal occasionally, these desktop sessions expire. And you have to link again. And when you do, you end up with a gap in your conversation history because "security".
Yes, and there's also a limit of max 5 linked devices.
You can use Molly to put Signal on multiple devices or you can bridge it into Matrix or XMPP, but you'll always need to run on one "main" device.
What exactly does this entail? I'm willing to be charitable in assuming that their use of "verify" isn't the modern usage of "give us your ID!" but I'm not enmeshed enough in the ecosystem anymore to know.
Respectfully, not even close. Verification is when I sign in from a new device, I use an existing device or second passphrase (either-or) to ensure that yes, it is me on both devices. I never have to reveal my ID, name, phone number, or email address to anyone. Not to Element, the Matrix Foundation, or the person running my home server where all my [encrypted] messages live.
My understanding is that there's two different types of verification.
Self-verification means that any new secondary devices you log into your account with will need to be verified by an existing login by way of an automatic popup that asks if you trust the device. It used to just be a Yes/No button but I think now they've added QR codes and/or emoji matching.
The other kind is verification between two different people, like when starting a direct message conversation, you might get the same emoji matching window to verify each other.
Yeah, IMO "verify" was a poor choice of wording for what this is. It has nothing to do with remote attestation or any other form of Treacherous Computing, and it has nothing to do with your real-life identity. It's just "go on your old device and confirm that the new device is really yours."
If you don't mind reading an essay, here is mine from the same discussion: https://news.ycombinator.com/item?id=45989744
> 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.
Here's the thing. You can already! Whether you should or not.
seems like it's just that element (the official, and most popular client) will ignore messages from unverified devices, but since it's part of the spec, other clients that want to be spec-compliant will implement this too. I don't think most other clients follow the spec that closely though.
I'm in favor of the change, the only downside I can think of is users with esoteric clients or simple bots that don't support verification won't be able to post to encrypted rooms with element users.
I feel like I'm alone in having good luck with matrix. I've been self hosting for nearly a decade to a handful of users, and it was a bit rough troubleshooting the encryption problems back when element was still called riot, but it's been a number of years since any of us have had a single encryption issue, and we added a new user recently with no trouble. we're still on 'element classic' though, the new 'element x' is a bit of a mess and loses the background sync feature, you need to set up a unified push server which I'm not looking forward to.
For what it's worth, I've been using element x with unified push for a month or so now and I get notifications with message contents without any delay. Maybe they fixed the issue you're worrying about?
Self hosting the call/video feature became a lot more complicated though (and it's incompatible with the old system).
my issues with element x are with the client itself, mostly missing features and bad UX. the main reason I don't want unified push is, it's just yet another thing for me to install and maintain, plus all my users need the client app installed. the ntfy server app even defaults to having a full web interface, fortunately it's possible to disable but it's just so much stuff to replace what used to be built-in to the app, to supposedly solve a battery life problem that I've never experienced.
I'm still going to get around to it, because element classic will be deprecated eventually. one of my users is on iOS and has a well-known bug with images not loading, which will probably never get fixed because they're focusing on the new client. and unfortunately I do have users that expect voice calls to work, so it sucks to hear that'll be annoying too.
I've had mostly good luck with Matrix too. Been self-hosting since 2022 and while there have been frustrations it has been pretty stable for basic chat.
no, you are not alone, though I don't host
I always use my master key, verifying using other devices does not always work optimally in my experience. Maybe I switched to ElementX too soon...
So compromising identities might happen - this seems to be a leading reason to verify devices - but can device verification be compromised too?
Does anyone have any experience with Keet as an alternative?
https://keet.io/
Is Keet Open Source? Last time I looked into it (admittedly a few years ago) it was not.
Can't wait for a bug to un-verify me on both my devices and lock me out of my account.
I'm pretty sure you get recovery keys with it also.
I hope beeper will continue to work, as it's based on Matrix iirc.
There seems to be a lot of confusion regarding what verification is all about. I'm going to list out what it means, based on my reading of their documentation[1] and on what worked for me. It includes some essential preparations that you MUST TAKE if you have access to your account. This is to ensure that all your devices are verified, that they all have access to all encrypted messages and that you don't ever get fully locked out.
DISCLAIMER: I have no direct experience with Matrix or Element code base. I have no affiliation with them either. So this isn't official and a few errors can be expected. Please let me know if you notice any. I will keep this corrected for as long as I can. Otherwise I'll add the errata as child comments.
1. Matrix has TWO levels of authorized access.
2. The first level is where you enter your regular username and password, that's unique to your homeserver (like matrix.org). It looks like OIDC/OAuth2 to me. On being authenticated at this level, your client (Element, Fluffy, Cinny, etc) is able to access the messages meant for you. At this stage, you're able to read any unencrypted messages. Most community chatrooms are unencrypted by choice.
3. The encryption used for your encrypted messages is end-to-end. Their encryption keys are named 'room keys' in Element (there are several of them). They are not directly available to your homeserver (otherwise, it wouldn't be end-to-end). Similarly, there seems to be an 'Identity key' (presumably a cryptographic private key that makes you the owner of the account and is needed for some account operations). This key is also not directly available to the homeserver.
4. The client app just logged in and the server doesn't know your room keys or ID keys. They're known only to your other clients. So now you need to transfer them from those clients to the new client without divulging them to any servers in between. Once that's done, your new client will be able to decrypt all your encrypted messages and join those discussions.
This process of transferring your room keys and the ID key to your new client is the second authorization step known as 'Verification'. (I presume it's called verification because your new client can now prove its authenticity using your ID key.)
5. Verification can be done in three different ways. The first two are manual methods and are rarely used. We will discuss these two later. The other is using a 'verification request'. This is straightforward. Your new client requests the already verified clients attached to your account for your room and ID keys. Any verified client can respond. However, it needs to first verify that your new client is really yours, and not someone who used your leaked password or hacked your account. To do this, the clients currently offer you two methods - one using a QR code and the other using a sequence of icons.
If you select QR code, your verified client will show you a QR code that you need to scan with your new unverified client. Since it proves that both clients are in the possession of the same person, the verified client then proceeds to transfer the keys to the new client, finishing the verification. Now if you chose the Icon sequence instead, then the verified client creates a random sequence of icons that it sends to the new clients. Then both the clients display it to the user. If the user accepts on both device that the icon sequences are identical, it's the required proof that both clients are with same person. The rest of it is the same as before.
6. So far, so good. If you were able to complete till step 5, the new client is verified and now you can carry on with your business. Now we address the situation of what happens if you are not able to do any of these. Just assume that all your clients got logged out together for some reason (yes, it has happened before). Now none of your clients or the server has any of the room keys and the ID key needed to prove your ownership (crypto authn) or access your encrypted messages, even after you log back in. The only solution is to load the room keys and ID key from a backup. This is why it is IMPORTANT TO BACKUP your room and ID keys.
7. There are two ways to backup the room keys and the ID key. These two methods are also the two manual methods of verification that I mentioned above. The first method is to back up the keys on the homeserver itself. It's convenient because all your clients can access them at any time and keep the room keys updated as they change or new ones are added. This feature is called 'Key Storage' in Settings/Encryption tab of Element. It's enabled by default. ALWAYS keep it enabled.
You may be wondering how it can be end-to-end encryption if the private keys are stored on the homeserver itself. If you're, then you're correct. They are stored in encrypted form on the server key storage. The decryption keys for that is available only to the clients. So while the server holds the keys, it cannot access any of them.
8. Here is your first opportunity to do something about accidental losses. The decryption key for the key storage can be downloaded and preserved in a secure manner. Perhaps write it down on a paper or put it in the password manager. This key is called the 'Recovery key'. You can download or change it from Element's Settings/Encryption tab. ALWAYS BACKUP YOUR RECOVERY KEY.
You can use the recovery key instead of the QR code or the icon sequence to verify your new clients. There are two differences from the previous method. The first is that you can enter the recovery key directly into the new unverified client. The verified clients are not needed here. The second is that this is possible even if all your clients gets logged out. Again, this is why it's very important to BACKUP YOUR RECOVERY KEY!!
9. Besides setting up server key storage, you can take one additional step. This is the second manual method of verification. You can download and backup all the room keys and your ID key on your local system. This option is available as the 'Export keys' button on the Settings/Encryption tab. When you do so, you'll be asked for a password. This password is used to encrypt the file with all those keys, so that they don't sit unencrypted on your disk. This file can be backed up as such, but you can encrypt it again if you prefer.
You can use these keys also to verify your account. You'll need the above password to decrypt the keys file. However, this method still has one big CAVEAT. I suspect that the keys file need to be updated regularly, since there will be new keys when you join rooms. So if you use this method to validate, it's likely that your client won't be able to decrypt the rooms/messages for which it doesn't have the copy of their key. But this is still worth doing, because it contains your ID key which can be used to verify all your devices again as a last ditch measure (if your homeserver happens to quit or something).
10. Now let's just say that you're a careless ### who didn't do any of the above. You still have the option to nuke it! That is to Reset your cryptographic identity from Settings/Encryption. I presume that this just discards all your previous keys and creates a new private ID key. Since all the clients can now access this key, your account is verified again. But you will not be able to access any of your previous encrypted conversations. And the homeserver helps you along by discarding all your previous conversations, room subscriptions and settings. So now you're left with a cleanly empty account. But hey! You have your verified account back!
So, in summary:
1. Always verify all your clients
2. Setup server key storage (it is enabled by default, don't disable it) and backup the recovery key
3. Backup the room keys and ID keys on your local system. Use it for recovery/verification only in the worst case
4. Don't forget the password you used to encrypt the above file (just sayin)
NOTE: I intentionally left out some crypto details from the above (like session keys) to avoid making it any more complex. If you're unhappy with those omissions, please just leave a comment.
[1] https://element.io/en/help#encryption
[dead]
[dead]
[dead]
[dead]
Conspiracy theory time...
Matrix is the Firefox of chat apps. Castrated on purpose and kept around as a "see how much worse than WhatsApp things can really be!"
This is supposed to be what decentralization looks like?
It’s still decentralized. If you read the article this is about cryptographic verification, not anything about ID.
Haven't used matrix for a few years now, last time I used it everything was a slow, buggy mess.
>device verification
Kinda weird because it's a protocol, but then again matrix is extremely centralized.