Verifying your Matrix devices is becoming mandatory
25 comments
·November 20, 2025iqihs
kachapopopow
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.
unbolted3032
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.
jerrythegerbil
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.
tripdout
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.
totetsu
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.
navigate8310
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?
kevincox
Yes, the purpose is the same but the UX is a bit different.
ThePinion
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.
mroche
You can also use a generated security key to verify as a type of second-factor.
olivia-banks
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.
null
Bayaz
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.
lousken
"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?
bfkwlfkjf
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.
syntheticnature
It is not; I know we don't read articles here, but...
ranger_danger
Isn't this how TLS itself already works? "trust on first use"?
pavon
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.
treyd
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.
hedora
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?
kevincox
Matrix has E2EE support and many clients are pushing it as the default. But it also supports rooms that are only encrypted in transit.
olivia-banks
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.
ranger_danger
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.
toastal
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 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?