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.

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