MSC3015: Room state personal overrides #3015
Conversation
Co-authored-by: Erkin Alp Güney <[email protected]>
Co-authored-by: Kevin Cox <[email protected]>
After much thought I decide to rework this MSC to allow override not only room name, but avatar, topic and maybe other room state values too.
MurzNN
changed the title
|
After much thought I decided to rework this MSC to allow override not only room name, but avatar, topic and maybe other room state values too, also reworked the storage format to match the state event content. |
turt2live
added
the
needs-implementation
| 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.
Naming keys that way effectively imposes a new top-level namespace, which we don't have as yet. Any particular reasons against m.room.name.override (and so on)? You already use this form in the unstable prefix section, by the way.
(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.
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.
The primary problem with adding a top-level namespace here is that we use reverse-DNS notation, and can't guarantee that override won't end up being a legit DNS TLD. More formally, it would probably be the second occasion when we use a non-m., non-revDNS top-level namespace, and I'd rather follow the existing overarching convention. If you're not quite happy with override as a postfix, m.override.room.* (and org.matrix.msc3015.override.room.* for the unstable form - mind that m. can be replaced with the unstable prefix in this case) should probably be fine too.
(For the record, the first non-m. top-level namespace was u., for room tags; I don't advise employing it here since u. tags are defined at the discretion of end users, not the spec.)
| 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.
What if someone wants to override the room name with an empty string?
There was a problem hiding this comment.
For this task value for override.m.room.name must be:
{
"name": ""
}like regular room state item, when room admin removes the name of room.
There was a problem hiding this comment.
Yeah, I guess it's worth putting that in the MSC text, for clarity.
There was a problem hiding this comment.
What would happen if user override it as empty string?
| 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.
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.
|
I think it would be better (IMHO essential) to have a custom This similarly applies to |
|
Hey @MurzNN, because I did not know this MSC exists, I began writing MSC3864 and MSC3865, which kind of overlap with this MSC. I separated overriding room attributes and user attributes, so overriding user attributes can happen on a global scope and a room scope (got the idea from a discussion). However, as I see it, yours seems more reviewed and so more ready to implement. So I'm unsure if both approaches shall be decided upon or if we could merge both. If you (or others as well) have time to discuss this, I created a public room for that: #mscs-3015-3864-3865:matrix.org |
|
This seems to have stalled, is there a reason? I'm really surprised with the popularity of the Discord bridge that people don't have more use for this since you end up with 10 rooms all named |
From what I can tell, the next step is to edit the proposal to not use a top-level Until this is merged, I'm considering implementing it in my client using the unstable prefix mentioned: |
|
FWIW, I've implemented this in Ement.el: alphapapa/ement.el@7c12e04 It seems to work nicely. Finally I can give rooms names that are meaningful to me. I hope this proposal will be merged so all clients can use it. |
|
Is @MurzNN interested in continuing to push the PR forwards? Alternatively, is anyone else interested in picking it up? (Or forking it? I don't know the proper procedure here). This proposal has been open for a while (seems like it's even targeting a stale branch), so would it need a lot more changes to be viable? Or has it been superseded by a newer proposal? |
|
There were discussion chat created by @Zocker1999NET #mscs-3015-3864-3865:matrix.org we can jump in. I would really like it to be moved through. |
|
|
||
| # 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.
We can store inside our metadata object copy of original value.
And later client app can compare it with current value for room (or user if that 1on1 room) and if it changed -- render exclamation mark.
Rendered
Related issues:
Signed-off-by: Alexey Korepov [email protected]