MSC4161: Crypto terminology for non-technical users

[andybalaam]

Rendered

Conflict of Interest declaration: I am employed by Element. This MSC was written as part of my work on the Element Cryptography team.

[KitsuneRal]

Let me start with the positive note - I believe that, at this stage in Matrix evolution, this initiative is very worth while. I think that we need to unify and clean up the language used throughout Matrix, and that is not specific to the cryptography part. That being said, I think we have to answer a fundamental question before we go for this.

This is one of the first, if not the first, MSC that entirely focuses on recommendations to user interfaces and user experience rather than APIs and call flows. If we are to enter the UI/UX guidelines territory, I would prefer that we first agree whether the SCT remit and capability extends there, and how far. A few comments below have what I think needs further discussion. TL;DR (but please respond under specific comments):

1. Mainly to SCT: can we make sure this MSC does not end up a single shot and establish a way to further contribute in the same direction?
2. Mainly to SCT: if (1) is positive then we may have to do something about our expertise on the subject. I don't think we have enough of it onboard.
3. To the MSC authors: external references?
4. To the MSC authors and for an eventual spec PR: can we separate the glossary from the phrasebook and treat them differently? The glossary has much higher inertia among users while the phrasebook can be altered and extended faster without consequences for the ecosystem.

[KitsuneRal]

I don't see this MSC as a comprehensive document really covering the ground - and that's fine. I don't believe we should even focus on cryptography, it's just one of more technically advanced areas where we ended up exposing too much of protocol internals to the users. I'm totally happy to start with this but I don't want this MSC to be the start and the end. It would be great to see more effort, from the entire community, on improving UX in Matrix for different user categories. It would be disappointing if this MSC becomes a lonely shot in the direction of UI/UX guidelines.

I don't have a clear path but I know it should be more than an appendix, linked to from the CS API spec. We'll probably have to do some advocacy to raise awareness; we'll also need to think about i18n and l10n to extend good wording to other languages than English (we have prior experience on that!); probably there are more areas. I recognise that everybody signals ENOTIME at this point of reading but I don't see the point in going further with this MSC if we don't treat it as a part of something bigger.

[KitsuneRal]

I'm not sure we at SCT have experience and expertise on the subject. Being one of those covering the clients domain area, I may have to go for some research and self-education before I can responsibly make decisions on this. And/or we might have to call someone in who has appropriate background. Fortunately, Matrix is used by some UI-conscious communities (GNOME, in particular) so we might not need to search too far away.

This is especially critical given how much bike-shedding this subject may cause - particularly around the words and phrases shown in the UI.

[KitsuneRal]

Speaking of this MSC: I would appreciate having more external references. So far the MSC looks like a result of the original research breaking new ground, with minimal prior art. There's probably just a couple of places where other platforms are mentioned, and there are no references to decentralised platforms like E-mail or Web (GMail is not decentralised). It would be great to make sure at least some research has been done if we are to officially endorse specific terms.

For example: next to others, I'm not a fan of "devices", I really believe it's a misnomer we borrowed from centralised mobile-first platforms. I can still grudgingly accept it if we couldn't find a better alternative. But the only discussed alternative was "session", which I agree is (even) weaker. I was surprised that "clients" (taken from e-mail), or "applications/apps" (desktop and mobile environments) are not even namechecked.

Or consider "identity" - I don't know if it's good or bad because I don't see the research behind the choice. I only know it's difficult to translate it to Russian and a few other Slavic languages and, separately, that it confused me when I stumbled on "the identity has changed" wording in WhatsApp. Maybe there's something better, maybe there isn't - it's not clear from the MSC.

[KitsuneRal]

We can adjust phrases but the fundamental vocabulary is not something we can "iterate" easily on; once end users (especially non-technical) get used to it, they won't appreciate changes if/when we discover that something doesn't really work. I would suggest that we actually spec the glossary, leaving specific phrases to a lighter "implementation guide" kind of a document. The implication here is that the glossary is something we actively promote as the standard way to express things in Matrix (and tbh I would really consider it being universal, without "technical/non-technical" separation), while the phrases would be a sort of reference for client authors that we can change quicker, probably without MSCs.

[andybalaam]

Lots to think about here but I wanted to say straight away: thank you - you raise lots of very important points and I think I agree with almost everything you've said.

[Porkepix]

Stepping in, after reading Verification and Encryption related terms has been renamed as per https://github.com/matrix-org/matrix-spec-proposals/pull/4161. in latest Cinny patchnote (https://github.com/cinnyapp/cinny/releases/tag/v4.3.0).
While other vocabulary changes are fine by me, I'm quite surprised by the session -> device one; indeed user can have many sessions tied or not to a single or several devices. While it's generally not something one would do, you can even imagine moving a session from one device to another. Although, I also admit multiple sessions on a device is not something that'd be common among general users.

I agree with the intent here to try to make things simpler for general users: concepts can sometimes be hard to grasp for the less tech-savvy people, I found myself struggling to explain some of them like the concept of servers, clients and other similar things (when, curiously, we can take this for granted for emails, it never confused most of the people there, although standalone clients are not much used anymore and most users are now using webmails tying provider and client together…).

20 years of centralized "platforming" are to blame for this, but I don't think adopting the same vocabulary and wording will help as it'll only maintain confusion, the way we can also find for example with some kind of "trademarking" for some protocols (Mastodon used instead of Fediverse most of the time or Matrix itself with Element to some lesser extent, for example), and this is some education to have toward users rather than disguise Matrix clients as yet another centralized platform, which is why I'd rather have a best fitted wording underlining the different clients/sessions (which could even show more directly what the client and device are).

More generally I agree with KitsuneRal's points above where they probably expressed it better than myself! (Btw, I'm not sure phat the Phrasebook mentioned here is, compared to a glossary?)

PS: Sorry if my grammar and wording isn't the best fitted, non-native English speaker here.

PS2: It's probably obvious but as some people above requested for some expertise on the topic, I'm obviously no expert on the UX/UI matter, just giving my own humble opinion on the matter.

PS3: I'm not used to interacting around the MSCs, but I'd expect clients should wait for one to be merged and 100% validated before applying the changes it apply, right? Or is it also having some W3C-like validation where X clients should implement a change to validate it definitely?

[ajbura]

I'm quite surprised by the session -> device one

It actually make more sense as "session" as terminology should not be exposed to general user. Session as UI term is more driven from developers use of "session tokens".

Generally explaining UI/UX reasoning is hard but let me break it down with screenshot.

whenever user login new client:

• it should be considered as a login entry (not session) (marked in blue) in UI.
• At this point we can't say the login entry is done by you.
• To verify it we should perform some check that the device that is used, is owned by you?
• Prompt the user to verify the device identity.

Overall login entries (session) are subset of devices, but verification involves proving ownership of devices to grant secure access.

[Porkepix]

I agree with the explanation (sessions being a subset of devices), but then did I have a not thorough enough reading and wrongly considered every session would now be named a device, regardless of the context?
Thanks for the breakdown on screenshot!

[ajbura]

No, you are not wrong. Out of overall cohesive UI, individual login entry should not need to be called as device(or anything) as it has data associated with it, which makes it self-explanatory.
But when do we call them as device? obviously when we are referencing individual entry in ui. like:

• "A new unverified device (login) appears: xyz (macbook)" here we should purposely call it a device because of security measures which involves Device verification (not session verification). Until we verify, it is a new device login in overall secure system.
• "Changing device display name" It is better to call it device as the display name contains info that help us associate login with specific device.
• "Deleting choosen devices" better to call device as login entries are selected by reading device display names.

[KitsuneRal]

I believe it makes total sense to see harmonised but different vocabularies in the API specifications and UI guidelines. In case of UI I would suggest providing some acceptable alternatives to primary key words, as well as known-bad options (this MSC already has those in a few places). Having these helps translators a lot to find the best equivalent in other languages.

[KitsuneRal]

I'm not sure that the proposed language is actually aimed solely at non-technical users. I'm sure it will bring better Matrix experience to technical users who haven't seen the protocol specifications, just as well.