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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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?
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.
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.
> 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.
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.
"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?
"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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
The numerical Signal PINs are basically just for when you bootstrap your Signal identity from a telephone number.
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.
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.
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 ^^
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.
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?
Probably just bad UX to let people skip the verification step.
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.
My entire family (including my elderly mother) would be very interested to learn how technical they are!
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.
The code examples I'm aware of for clients using the first-party library also leave verification and E2EE out, FWIW.
It has the keys, or it doesn’t, right?
[0] https://matrix.org/docs/matrix-concepts/end-to-end-encryptio...
https://keet.io/
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.
SSH is an example of TOFU.
You still can... it just displays a warning message on first use, as does ssh.
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.
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.
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.
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.