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.

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.

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?

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...

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.

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.

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/

Riot.im/Element.io really knows how to shoot themselves in the foot.

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!!

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.

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.

It has the keys, or it doesn’t, right?

The code examples I'm aware of for clients using the first-party library also leave verification and E2EE out, FWIW.

Because it sounds like "we'll put them in a database so we can sell it" to me...

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.

[1] https://simplex.chat/

[2] https://github.com/simplex-chat/simplex-chat/pull/6205

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.

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.

Here's the thing. You can already! Whether you should or not.

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'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.

https://keet.io/

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

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!"

>device verification

Kinda weird because it's a protocol, but then again matrix is extremely centralized.