Skip to content

Commit 5c36dbc

Browse files
Zocker1999NETZocker1999NET
committed
Add MSC3864: User-given nicknames & descriptions for rooms & users
1 parent f139eee commit 5c36dbc

File tree

1 file changed

+245
-0
lines changed

1 file changed

+245
-0
lines changed

‎proposals/MSC3864-room-nicknames.md‎

Lines changed: 245 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,245 @@
1+
# MSC3864: User-given nicknames & descriptions for rooms & users
2+
3+
User-given Nicknames or names loaded from an addressbook are great,
4+
they allow you to personalize your experience in using an IM
5+
while others do not need to change anything.
6+
Like when you write with privacy-concerned users,
7+
they might use a nickname for their account on their own,
8+
but you may want to have them listed by their real name
9+
or any other funny nickname you've given them.
10+
Or people are using their display name to present statements like "(away until X)"
11+
and you want to set an end to that (for yourself).
12+
13+
The same for groups, sometimes, the *global* room name works fine,
14+
but it would be funnier or easier for you to use another one.
15+
Maybe because you've grouped similar rooms together into a (personal) space,
16+
so parts of the name become irrelevant.
17+
Like in a space called "My Long Cooperation Name",
18+
where every room is called like "My Long Cooperation Name - IT Team Chat",
19+
maybe shorter names like "IT Team" or "MLCN - IT Team" are better suited to you.
20+
Or maybe because the admin is just too lazy or stubborn to improve the room name.
21+
22+
Also, sometimes you just may want to append a description to a room or user,
23+
so you know why you joined the room or are knowning the user.
24+
Descriptions like "old class mate from XYZ School" can certainly improve your UX,
25+
especially when users or rooms change their names due to personal reasons ("new name is cooler, duh")
26+
and you stop recognizing who they are and need to ask them for their real life name
27+
or read through the chat history (happened multiple times to me personally).
28+
29+
30+
## Definitions
31+
32+
Further on, for the sake of simplicity and clarity:
33+
- **global name** is the display name
34+
- a user set for itself, visible globally to all other Matrix users.
35+
- a room was given, visible globally to all other users who can see the room.
36+
- **user-given name** refers to the name defined here a user shall be able to set,
37+
only visible for itself, for other users or rooms,
38+
replacing the global name.
39+
- **global description** is the display description
40+
a room was given, visible globally to all other users who can see the room.
41+
- **user-given description** refers to the description defined here a user shall be able to set,
42+
only visible for itself, for rooms,
43+
extending the global description.
44+
45+
46+
## Proposal
47+
48+
49+
### Reasoning
50+
51+
Allowing users to set user-given names and descriptions for rooms and other users is useful
52+
because it let users increase their usability and accessibility to the Matrix infrastructure on their own and as required.
53+
These names shall stay private to the user itself and may not be seen to others,
54+
so users are able to choose what they see fit best
55+
without thinking about privacy issues or the feelings of the room or users renamed.
56+
57+
Adding this feature to the spec has the advantage that presumable most clients will implement support for displaying and hopefully also setting names and descriptions.
58+
It also allows a more unified experience accross all clients and devices
59+
because user-given names and descriptions are synced using the home server of the user.
60+
For the same reason, this proposal includes a description of the expected user experience.
61+
62+
This proposal takes advantage of the already implemented
63+
[room tagging feature](https://spec.matrix.org/unstable/client-server-api/#room-tagging)
64+
so the API and the server implementations hopefully do not need to be changed drastically
65+
(see [implementation issues](#implementation) below).
66+
Room tags are only visible to the user who set them and are synced accross all devices of the user,
67+
which makes them a perfect fit for storing user-given names and user-given description.
68+
69+
70+
### Implementation
71+
72+
For user-given names, a new tag called `m.user_given_name` may be added.
73+
Its `content` key shall contain the user-given name.
74+
75+
For user-given descriptions, a new tag called `m.user_given_description` may be added.
76+
Its `content` key shall contain the user-given description.
77+
78+
Clients shall append the tags `m.user_given_name` and `m.user_given_description`
79+
with their `content` key containing the user-given name / description
80+
to the selected room.
81+
82+
When setting user-given names and descriptions to other users,
83+
clients shall append the tags to the room both users use to exchange direct messages.
84+
If a user may leave the last DM room, the user-given names and descriptions may be lost as well.
85+
This behavior may or may not be expected, depending on the user's preference.
86+
Clients may inform the user about this circumstance so they can make an informed choice.
87+
88+
If the client will be informed about room tags of a room with an user-given name and description,
89+
the answer may look like this:
90+
91+
```json
92+
{
93+
"tags": {
94+
"m.favourite": {
95+
"order": 0.1
96+
},
97+
"m.user_given_name": {
98+
"content": "Sweatheart"
99+
},
100+
"m.user_given_description": {
101+
"content": "my crush since middle school"
102+
}
103+
}
104+
}
105+
```
106+
107+
(See [Implementation Issues](#implementation-issues) for potential issues this one might have.)
108+
109+
110+
### User Experience
111+
112+
Clients shall replace most occurencies of the global name of a room with user-given name, if set.
113+
Clients may still display the global name in some occurencies
114+
according to the section [User Experience Issues](#user-experience-issues) below.
115+
When the user wants to change the global name of a room,
116+
or the user gets informed about a change of the global name of a room,
117+
the global name may also not be replaced with the user-given name.
118+
However in such events, the user-given name may be displayed as well.
119+
120+
Clients shall append the user-given description to most occurencies of the global description of a room.
121+
Clients shall display both in a way so the user can separate them and interpret them correctly.
122+
123+
Clients shall also replace most occurencies of another user's global name with its user-given name.
124+
Aside from the DM room both users are using to exchange DMs,
125+
this may include occurencies like in events or in member lists of other rooms.
126+
When the user gets informed about a change of the global name of an user,
127+
the global name may also not be replaced with the user-given name.
128+
However in such events, the user-given name may be displayed as well, if not already.
129+
130+
For both rooms and other users, the client must not replace the Matrix ID of rooms / users.
131+
132+
133+
## Potential Issues
134+
135+
136+
### Implementation Issues
137+
138+
Some issues I discovered while writing or applying this MSC.
139+
These are listed here as points open to discuss further.
140+
141+
#### Implicit Support for content key
142+
143+
This MSC requires servers to implicitly support to store the new `content` key
144+
along the already existing `order` key for room tags.
145+
Probably a further MSC is required to define that tags may either:
146+
- can contain any additional metadata in form of more JSON keys (like `content`) OR
147+
- can contain an additional string with the key `content`.
148+
I left this out of this MSC because I am not sure if that change requires an additional MSC
149+
and so I want to first discuss this further in reference to this MSC.
150+
151+
#### Non-unique DM room
152+
153+
If users have multiple, similar looking rooms to exchange direct messages,
154+
clients may not be able to determine which room to append the defined tags to and read from.
155+
156+
This may be mitigated by either using all DM rooms equivally
157+
(appending the user-given name to all DM-like rooms),
158+
which itself could lead to consistency issues
159+
if clients have different assumptions about such DM rooms.
160+
Also, there may be no way to determine which user-given name the client shall display,
161+
if multiple DM-like rooms have such a tag but with a different content.
162+
163+
Clients may prefer to only display the user-given names and descriptions
164+
from the room which was created first.
165+
This may make multiple clients behave more consistent,
166+
so users have it easier to workaround problems arising from multiple DM rooms to their satisfaction.
167+
168+
169+
### Privacy Issues
170+
171+
Because account data in general is sent unencrypted to the home server (for now),
172+
the administrators of the HS or hackers who gained access to the HS may be able to retrieve these names and descriptions.
173+
This may lead into privacy issues the user may not be aware of.
174+
This could be prevented to encrypt account data before storing it on the server,
175+
however this is a task for another MSC to solve, preferably for all account data.
176+
177+
178+
### User Experience Issues
179+
180+
Using user-given names and forgetting that the user has configured them
181+
could lead into the bad UX that users think their client stopped working correctly,
182+
as a new name of the room or user is not displayed correctly.
183+
This may be mitigated by clients by informing users about that the name is custom, either by:
184+
- displaying user-given names in a custom font, style (e.g. **bold** or *italics*) or color
185+
- displaying the global name aside in brackets ("USER_GIVEN_NAME (GLOBAL_NAME)", e.g. "Sweatheart (Erika Musterfrau)")
186+
- this may only happen when reading messages of the room
187+
- displaying the global name when hovering with the cursor over the user-given name
188+
189+
Clients may choose how they want to display and annotate user-given name and global name
190+
by implementing none or any or some or all points from above as they see fit.
191+
However, the user-given name shall be displayed as the primary name
192+
(e.g. displaying as "**GLOBAL_NAME** (USER_GIVEN_NAME)"
193+
or displaying the user-given name with less contrast than the global name
194+
shall be prohibited, see [Alternatives](#alternatives) for reasoning).
195+
196+
The same problem should not occur in the same way to the user-given descriptions
197+
as they shall expand the global description instead of replacing it.
198+
However, clients should still display them either separated and labeled
199+
or at least in way so users can separate them from one and another easily.
200+
201+
202+
## Alternatives
203+
204+
User-given names and descriptions for rooms may be stored into the general account data.
205+
However, it places them away from similar properties like being a favorite
206+
and instead near other configurations like client-dependent configuration options.
207+
208+
User-given names and descriptions set for others users only may be stored into the general account data.
209+
This would circumvent the problem with [non-unique DM rooms](#non-unique-dm-room) particular for this MSC.
210+
However, clients may still need to solve this problem for other implementations,
211+
so no complexity would be saved in the end.
212+
And alongside the same reasoning from above,
213+
the user-given names and description may be lost when another user changes its Matrix ID
214+
and it also lets the implementation for rooms and users differ more.
215+
216+
Conceptually, the user-given name could also be displayed as a secondary attribute alongside the global name
217+
("GLOBAL_NAME (USER_GIVEN_NAME)", e.g. "Erika Musterfrau (Sweatheart)").
218+
This could prevent some [UX issues](#user-experience-issues),
219+
however this prevents users to customize their experience in certain ways
220+
(e.g. when they don't want to read the global name).
221+
With this implementation, a user is still able to display (parts of) the global name
222+
as they like by adding it to the user-given name theirselves.
223+
It only would not be updated automatically.
224+
225+
226+
## Security considerations
227+
228+
This proposal should not touch any security-sensitive components
229+
ans so should not create any security-releated issues.
230+
231+
232+
## Unstable prefix
233+
234+
Until this MSC lands, clients shall use tag names with the `m.` prefix with `work.banananet.msc3864.`
235+
(e.g. use `work.banananet.msc3864.user_given_name` instead of `m.user_given_name`).
236+
237+
After this MSC lands, they shall begin use the official tag names
238+
and also migrate from an unstable tag to an official tag,
239+
prefereable automtatically and in the background when finding such a tag.
240+
However, for a reasonable time, the unstable tags shall still be set along the official ones.
241+
If the clients detect, that the unstable tag's and official tag's contents differ,
242+
they may prefer the content of the official ones.
243+
244+
After the reasonable migration time, clients may remove the unstable tags,
245+
prefereable automtatically and in the background when finding such a tag.

0 commit comments

Comments
 (0)