MSC3015: Room state personal overrides

[MurzNN]

Rendered

Related issues:

• Personal ('pet name') room name for chats
• Ability to override the displayname for users & rooms that get served to you (SPEC-427)

Signed-off-by: Alexey Korepov MurzNN@gmail.com

[MurzNN]

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.

[KitsuneRal]

I think this is heading in the right direction - but can we please not introduce a new top-level namespace just for the sake of local overriding?

[KitsuneRal]

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

[MurzNN]

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

[KitsuneRal]

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

[KitsuneRal]

What if someone wants to override the room name with an empty string?

[MurzNN]

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.

[KitsuneRal]

Yeah, I guess it's worth putting that in the MSC text, for clarity.

[Mart-Bogdan]

What would happen if user override it as empty string?

[uhoreg]

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.

[c7hm4r]

I think it would be better (IMHO essential) to have a custom m.room.name only encrypted on the server. It might contain highly sensitive data.

This similarly applies to m.room.avatar.

[Zocker1999NET]

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

[Fmstrat]

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 #general.

[alphapapa]

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 #general.

From what I can tell, the next step is to edit the proposal to not use a top-level override. namespace for the data, as mentioned by @KitsuneRal at #3015 (review).

Until this is merged, I'm considering implementing it in my client using the unstable prefix mentioned: org.matrix.msc3015.[m.state.type].override.

[alphapapa]

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.

[lord-ne]

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?

[Mart-Bogdan]

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.

[Mart-Bogdan]

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.