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.
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.
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.
"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?
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 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 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'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 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 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.
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?
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 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...
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.
> 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).
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.
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.
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.
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.
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.
"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.
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 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!!
62 comments
[ 4.5 ms ] story [ 62.6 ms ] threadIf 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.
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 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 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.
All this will do is make me lose EVERY profile.
It has the keys, or it doesn’t, right?
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.
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 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 :/
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?
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.
Edit: I looked up and apparently Mattermost would be out of the question for their feature downgrades in the community version as of late...
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.
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.
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).
In either case, that's a no for me dawg.
The code examples I'm aware of for clients using the first-party library also leave verification and E2EE out, FWIW.
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.
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.
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.
https://keet.io/
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.
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.
>device verification
Kinda weird because it's a protocol, but then again matrix is extremely centralized.
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!!