Skip to content
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

MSC3015: Room state personal overrides #3015

Open
wants to merge 61 commits into
base: old_master
Choose a base branch
from

Conversation

MurzNN
Copy link
Contributor

@MurzNN MurzNN commented Feb 19, 2021

MurzNN and others added 2 commits February 23, 2021 08:59
Co-authored-by: Kevin Cox <kevincox@kevincox.ca>
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 MurzNN changed the title MSC3015: Room personal name MSC3015: Room state personal overrides Apr 3, 2021
@MurzNN
Copy link
Contributor Author

MurzNN commented Apr 3, 2021

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 turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
Copy link
Member

@KitsuneRal KitsuneRal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

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`**
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

The 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 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 (`{}`).
Copy link
Member

Choose a reason for hiding this comment

The 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?

Copy link
Contributor Author

@MurzNN MurzNN Jul 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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`
Copy link
Member

Choose a reason for hiding this comment

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

@c7hm4r
Copy link

c7hm4r commented Jan 29, 2022

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
Copy link

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
Copy link

Fmstrat commented Dec 26, 2022

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
Copy link

alphapapa commented Mar 1, 2023

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
Copy link

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
Copy link

lord-ne commented Feb 9, 2024

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
Copy link

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet