[Arathorn]

Yup. One of the biggest learnings of E2EE in Matrix is that the complexity is 95% user experience. However, in Element X, we've been determined to get it right - although there is still some temporary UX in there while full-blown Invisible Crypto is still rolling out (as it requires a breaking change to stop encrypting/decrypting with unsigned devices - the equivalent to a browser refusing to talk TLS to self-signed certs).

If you haven't seen MSC4161 (https://github.com/matrix-org/matrix-spec-proposals/blob/and...) i highly recommend it as evidence of how we've made a serious effort to fix the terminology and copy - not just for Element X but across all Matrix clients.

[zorgmonkey]

Standardized terminology is an awesome step. I'd love to see some of standardized file format for setting up the right keys on different devices. In the past I'd had annoying issues getting all the messages to decrypt on multiple devices, especially if I wasn't using the same client every device. Honestly though I suspect I was doing something wrong.

[Arathorn]

there's already a standardised export format for message keys (although EX doesn't let you load/save it yet, mainly because online backup already solves most use cases): https://spec.matrix.org/v1.12/client-server-api/#key-export-.... If you enable backup on your clients then EX at least will merge the missing keys to/from the backup. Meanwhile, the original problem of missing keys were probably unfortunately just due to bugs - although as per https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/#4-inv... we've done a huge amount of work to improve this now, and they should be really unusual now (at least when due to bugs, rather than permissions or data loss or similar).

Separately, talking of standardised key formats: one of the team did a skunkworks hack last Friday to experiment with a standardized file-format for user public keys - a kind of basic key transparency ledger for Matrix, to help with bulk-verification within orgs.