-
Notifications
You must be signed in to change notification settings - Fork 413
MSC3015: Room state personal overrides #3015
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: old_master
Are you sure you want to change the base?
Changes from all commits
e0e7133
96fef8b
8065221
0de8e47
45c91fd
a226142
616dcba
6b5ccbe
e343893
d448559
c33ef1a
ad7f2fa
dd423aa
76e0522
9a7f694
910be82
abc7edf
108ffa7
2be176c
eea1ba0
87bfff2
ba19693
6147bd6
6da8d3a
fa6f59b
2e8536e
0eb7773
00ade35
5df15b6
a470fba
39c08c4
12c0a3f
21f14c2
cfb8f55
ffad669
6ff1393
f0e6037
25a6d58
381103a
979eb47
016d3f8
41733af
359b003
985f30e
50cfe4f
74a25c6
1bd1132
e9d925b
cc88c7e
f859140
415a7f4
8c1fbce
34acaed
54795fc
649b5b4
42e5c7f
3cc130e
a56f5aa
9c94f4c
5ba4368
74fa075
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,120 @@ | ||
| # MSC3015: Room state personal overrides | ||
|
|
||
| Very often users want to personally rename rooms to see it in list like they wants, especially for DM rooms. But room | ||
| name is shared thing, so if they rename it for yourself, all other members will see this rename too. | ||
|
|
||
| Examples of problem: | ||
|
|
||
| 1. Very often other people want to rename DM rooms with me and can do this, because we both are admins. So they set the | ||
| alternative name of that DM room (eg `Korepov Alexey` instead of `Alexey Murz Korepov`) - this works well on their | ||
| side. But, as result on my side, I see that room in my rooms list with my name, instead of remote user name. | ||
|
|
||
| 2. The user has two DM rooms with different Matrix users, but both have name "Alice" without avatar. As result they see | ||
| two identical rooms in the list with same name and it is unclear which room is which. | ||
| If attempting to solve this problem via renaming rooms, the problem described in 1 occurs. | ||
|
|
||
| 3. This problem often happens for rooms from bridged networks, when we talk with same person via different networks, and | ||
| want to mark each room personally. This can be solved via adding suffixes with remote network name to room name on | ||
| Bridge side, but people want to change other parts of room name too. For example, one person can have different names | ||
| in each network (eg "Alexey Korepov" on VK, "Korepov Alexey" on Skype, "Alex" on WhatsApp, "Murz" on Telegram), and I | ||
| want to see all rooms with him as similar names, and also maybe attach personal avatar to that rooms. | ||
|
|
||
| 4. Some networks (eg IRC, Slack) also have no per-room avatars, so they are bridged with empty or identical avatars, that | ||
| makes harder to diffirentiate them in avatar-only list of rooms, so users want to override the avatars personally too. | ||
|
|
||
| Most of other modern messengers (Telegram, Skype, Viber, WhatsApp) already have this feature, but only for DM rooms via | ||
| reusing smartphone's addressbook to store personal names of contacts. And moving from that messengers to Matrix confuses | ||
| the people, because they can't rename personal chats in his own list like before. | ||
|
|
||
| # Proposal | ||
|
|
||
| For solve this problem I propose to use [room's account | ||
| data](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-user-userid-rooms-roomid-account-data-type) | ||
| item with same key as overriden state event type, but with `override.` prefix, to store personal overrides of needed | ||
| state any room for each user individually, and overriden content, here is example for room name and avatar overrides: | ||
|
|
||
| **`override.m.room.name`** | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Naming keys that way effectively imposes a new top-level namespace, which we don't have as yet. Any particular reasons against (I tend to agree that a marker that this is a user-specific override, not a part of the server-tracked room state, is important). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. By making an new top-level namespace, I tried to separate overrides from other groups of namespaces, to not mix different things in one namespace. But if top level namespace is bad idea, I can rework this to use suffix instead of prefix... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The primary problem with adding a top-level namespace here is that we use reverse-DNS notation, and can't guarantee that (For the record, the first non- |
||
| ```json | ||
| { | ||
| "name": "The room name" | ||
| } | ||
| ``` | ||
| **`override.m.room.avatar`** | ||
| ```json | ||
| { | ||
| "info": { | ||
| "h": 398, | ||
| "mimetype": "image/jpeg", | ||
| "size": 31037, | ||
| "w": 394 | ||
| }, | ||
| "url": "mxc://example.org/JWEIFJgwEIhweiWJE" | ||
| } | ||
| ``` | ||
|
|
||
| By default those items are absent. They are added only when user make the personal override, and cleared if user | ||
| remove the personal name for room (or make it empty). Regarding to spec, the account data's key can't be deleted, | ||
| so if user wants to remove the personal override (aka "Reset to default"), the value of the key should become | ||
| empty (`{}`). | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if someone wants to override the room name with an empty string? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For this task value for {
"name": ""
}like regular room state item, when room admin removes the name of room. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I guess it's worth putting that in the MSC text, for clarity. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What would happen if user override it as empty string? |
||
|
|
||
| Those overrides can be used for all types of rooms: DMs (to rename personal contacts or set custom photo to avatar, | ||
| add notes to topic), public rooms (to set desired personal name, eg in user's native language), public Spaces, etc. | ||
|
|
||
| For not allow to override bad things, I think we must define an allowlist of state types, that can be overriden: | ||
| - `m.room.name` | ||
| - `m.room.avatar` | ||
| - `m.room.topic` | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Room topic is generally a message from the room admins, so I don't think it's really something that people should be overriding. (Similar for message pinning.) I can see the value in being able to add your own notes on a room and bookmark certain messages in a room, but I think those should be separate information, in addition to the topic and pinned messages, rather than overriding those. |
||
| - and maybe also `m.room.pinned_events` for implement personal pinning? | ||
|
|
||
| Also we can allow even `m.room.member` for personally override room members names and avatars too. But for this task | ||
| may be better to wait for user profiles implementation from [MSC1769: Extensible profiles as rooms](https://github.com/matrix-org/matrix-doc/pull/1769), | ||
| to override profile info values via same technic like in regular rooms, this will allow even complements the remote | ||
| profiles: add personal phone number for your contact, that missed in public profile and know only by you, leave personal | ||
| notes about that contact, etc. | ||
|
|
||
| # Client support | ||
|
|
||
| ## Displaying: | ||
|
|
||
| When client displays the room information (eg in room list), for all allowlisted state keys it should lookup the | ||
| corresponding room's account data key with `override.` prefix, if it exists and not empty - replace the content | ||
| of that state event to overriden before rendering. Clients may show both values (global and personal) and explain | ||
| that this room have an overriden personal value, that is seen only for current user. | ||
|
|
||
| ## Adding, removing, renaming: | ||
|
|
||
| Clients should provide a way to privately override allowed room state values and clearly explain the difference | ||
| between global and personally overriden values. | ||
|
|
||
| In room list this can be implemented via "Rename room personally" or "Set personal name for room" menu item in | ||
| right-click menu, and similar way for avatar. | ||
|
|
||
| In room settings page personal name can be implemented via button "Set personal name for this room", which will be | ||
| available even if user have no permission to change the room name, and same for avatar. If personal value is filled, | ||
| it should be shown near the global room value, with ability to remove it. | ||
|
|
||
| # Server support | ||
|
|
||
| This MSC does not need any changes on server side. | ||
|
|
||
| # Potential issues | ||
|
|
||
| 1. User can set a personal value that is identical to the current global room value. This may cause confusion as the | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can store inside our metadata object copy of original value. |
||
| client will not see future global value changes. Clients should consider providing the user a suggestion to remove | ||
| personal override for follow future renames of room. And for other renames - explain that personal override will not | ||
| follow the future changing of global value. | ||
|
|
||
| # Alternatives | ||
|
|
||
| 1. Instead of setting personal name for rooms via | ||
| [room's account_data](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-user-userid-rooms-roomid-account-data-type) | ||
| we can set personal names directly for Matrix users (mxid), like other messengers (Telegram, WhatsApp, etc) doing. | ||
| This will give similar behavior for DM rooms, but will make impossible to set personal names of rooms with several | ||
| users (or DM rooms with bots), and intersects with per-room display names feature. And this way will be better to | ||
| implement together with "[Contacts](https://github.com/vector-im/roadmap/issues/10)" feature, which is planned in | ||
| Element and in issue [Contact List & Renaming Contacts](https://github.com/matrix-org/matrix-doc/issues/2936). | ||
|
|
||
| # Unstable prefix | ||
|
|
||
| Clients should use `org.matrix.msc3015.[m.state.type].override` for room account data key instead of proposed, while this | ||
| MSC has not been included in a spec release. | ||
Uh oh!
There was an error while loading. Please reload this page.