MSC3949: Power Level Tags #3949
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,113 @@ | ||
| ### MSC3949 Power Level Tags | ||
|
There was a problem hiding this comment. Who is allowed to set these? I assume only PL>50? There was a problem hiding this comment. Not the author but i mean unless this MSC gives a recomendation to change the PL template your client uses this would be arbitrary state PL ofc. |
||
|
|
||
| Currently permissions in a certain room are handle via `m.room.power_levels`. A power level is an | ||
| integer value, bigger the integer bigger the power. When we assign power level to a user we gave | ||
| them power represented as integer value. This integer value is abstract and does not tell what kind | ||
| of power it represent. Currently spec only suggest mapping abstract integer value to idea as: 0 - 49 | ||
| to User, 50 - 99 to Moderator - 100 to Admin. This suggestion limits the wide range of power level | ||
| integers to only three idea's. | ||
|
|
||
| This MSC propose tags for power levels. A tag represent a configurable information that can be | ||
| tagged to any power level integer. This configurable information will give an idea of what a power | ||
| level is when presented to user in graphical user interface. This will enhance the experience of | ||
| managing permission as now power level can be able to represent the wide range of idea's. As power | ||
| level can be assigned to users, we can also display room member by associating idea of power in room | ||
| timeline and member list. This association will enhance the experience as tag will represent | ||
| responsibility's of members at glance. | ||
|
|
||
| ## Proposal | ||
|
|
||
| ### What is Tag? | ||
|
|
||
| A Tag have three properties: `"name"`, `"color"` and `"icon"`. | ||
|
|
||
| ```json | ||
|
There was a problem hiding this comment. This example is missing the type and is not a valid matrix event There was a problem hiding this comment. Your state Event is fine though. There was a problem hiding this comment. I don't think this is intended to be a full event? It looks like this is just the definition for the There was a problem hiding this comment. Ah yeah it just seemed weird as the state event is in full |
||
| { | ||
| "name": "Admin", | ||
|
There was a problem hiding this comment. How about providing translated names? Right now clients like Element translate the names into the user locale, so making this a map would be interesting. For example {
"name": {
"en": "Guest",
"de": "Gast"
}
...
}The key would be an ISO locale code. If the requested locale is missing, we would need some kind of fallback to other locales, in the end falling back to There was a problem hiding this comment. It looks like this is going to be user input so translation does not make sense here. A community can label users with certain power level anything. There was a problem hiding this comment. Well multilingual communities should be supported since they might bring translations for all langauges they use. For example a community for the Swedish Speakers in finland might bring a Swedish, Finish and English translation for their roles. And in more corporate usecases this will also be able to be utilised properly. There was a problem hiding this comment. In our case it is a cooperate use case, where multi-language role names are important. Right now it is solved by forking clients and replacing the translations with custom ones. There was a problem hiding this comment. @FSG-Cat How do you propose managing these translations? Since this is user input, and only some users can edit state events then only those will be able to translate them. Plus this makes the UX of roles in a client very complex and on top of that since power levels are room-specific, translating those in each room will be an extra burden. IMO, if a community wants to add a multi-lingual role for say administrator with PL 100, they can create a Tag with name administrateur and PL99 and add those accordingly to users. There was a problem hiding this comment.
UX wise, you probably can default to a single language mode and allow multi-language flows for advanced users. Most people probably only require a single language. There was a problem hiding this comment.
@kfiven I fail to see how the UX would be too complicated because of this. But lets put that besides for now. The translations would be community managed because its a Bring your own Translations system. Also on the note that its room specific yes and no. Its room specific but you can template this and like tbh PL sync is going to be a thing at this rate. I have personally thought about writing the MSC for it. Also as for your using diffrent PL fix i say that is a wholy unacceptable compromise compared to the slightly more complicated UX or requirement to use specialised tooling like the Feline Matrix Assistant that i made or Matrix Wrench etc. Like its not a compromise that gets you this specific feature at all. You get forced to give admins a rank list as in who can demote who and also you also make it so their tag name is only accurate in a single language per admin meaning you cant know what their role is supposed to be in your language even if said community can translate into it unless said language is the language used for that admins tag. Also just to clarify on the nature of these translations. They are not translations where you try to cover all languages on earth. They are translations where you cover the languages used in your community. Therefore it does not matter that its limited scope as to who can write. There was a problem hiding this comment. I mean how will the client developers know which community wants which language in their PL translation, so clients have to suggest ISO codes of all languages. If we left it empty then it's up to the user to find out those, which again is bad UX for not-so-technical users. On top of those, this introduces a parallel translation option to the one client uses to translate its interface, which is again bad UX for translators. Lastly, I feel translating a state event is fundamentally wrong because with this logic a room name also could be another candidate for such translation, and room topic too. There was a problem hiding this comment. Could we partially solve this by defining default tags that we can then refer to by for example instead of using |
||
| "color": { | ||
| "on_light": "#023020", | ||
| "on_dark": "#90EE90" | ||
| }, | ||
| "icon": { | ||
| "url": "mxc:abc", | ||
| "info": { | ||
| "h": 152, | ||
| "mimetype": "image/webp", | ||
| "size": 30001, | ||
| "w": 152 | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| - `"name"` For what a tag represent. **Required**. | ||
| - `"color"` Color of tag. To create graphical emphasis and distinction between tags. (_Optional_) | ||
| - `"on_light"` Tag color for lighter background. | ||
| - `"on_dark"` Tag color for darker background. | ||
| - `"icon"` To display graphical representation of tags name. (_Optional_) | ||
|
|
||
| ### Attaching Tag to Power Level | ||
|
There was a problem hiding this comment. Does an event without associated PL grant the permission? How would it get mapped to those without the powerlevel? The current powerlevel event allows setting specific numbers to specific actions. This doesn't seem to have something like this. There was a problem hiding this comment. As addressed earlier. This is clearly a PL tags MSC and therefore makes no authorisation related changes. It only makes it so you can define that users at the PL of 1337 are Elite Haxors or whatever name you want to give to a given powerlevel. This proposal does implicit ranges. I personally would have if this wasnt made written a MSC that does Explicit ranges only. But as mentioned in another comment i dont want to compete with this MSC with my MSC that has diffrences due to the lack of improvements that are worth competing over when they are of potentially dubious value compared to this approach. |
||
|
|
||
| Tag can be attached to a power level by send a state event with key as `m.room.power_level_tag` and | ||
| state key as value of power level. | ||
|
|
||
| ```json | ||
| { | ||
| "type": "m.room.power_level_tag", | ||
| "state_key": "100", | ||
|
There was a problem hiding this comment. Having the PL as the state key seems weird to me. I would have expected the mxid. 🤔 As I would want to lookup the tag for the user so I would go by user id since I might not know the powerlevel. There was a problem hiding this comment. I think the idea is that this just gives names to the numerical power levels, rather than trying to introduce a new permissions system. So, say I have PL100 in a room via the normal power levels mechanism. Then the client can look up the appropriate |
||
| "content": { | ||
| "name": "Admin", | ||
| "color": { | ||
|
There was a problem hiding this comment. I think this may not work as there are clients with more than just those 2 options. So it may not always work. What is speaking against letting the displaying client decide the color? There was a problem hiding this comment. I think its more of a suggestion. Discord has Roles with Colours and on there a colour is fine on dark theme and bad on light but this fixes that problem kinda but matrix also has infinite UI variants so that problem is more complicated on matrix. There was a problem hiding this comment. Most of the client use white and black backgrounds so both these properties make sense to maintain good color contrast for most usecases. There was a problem hiding this comment. I agree its very common for clients to have darker themes and ligher themes. So offering a way to accomodate this i think is a good idea. There was a problem hiding this comment. My concern is just that dark and light is a spectrum not a constant. You can have dark and light and yet have different bg colors in clients. And with that you end up running into accessibility issues where the contrast might not be enough. (see accessibility spec for html/css World which needs a surprising large amount of contrast. So it is easy to mot have enough.) There was a problem hiding this comment. I personally think that we cant do too much to mittigate accessibility issues caused by user definable colours. I think that the obvious fix accessibility wise is an accessibility option that disables this customisation venue. There was a problem hiding this comment. Alternatively we can only use a |
||
| "on_light": "#023020", | ||
| "on_dark": "#90EE90" | ||
| }, | ||
| "icon": { | ||
| "url": "mxc://admin_icon", | ||
| "info": { | ||
| "h": 152, | ||
| "mimetype": "image/webp", | ||
| "size": 30001, | ||
| "w": 152 | ||
| } | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ### Deleting a Tag | ||
|
|
||
| A tag can be deleted by clearing all content from it's state event. | ||
|
|
||
| ### How it fit with existing system? | ||
|
|
||
| If a room does not have any `m.room.power_level_tag` events client can fallback to suggest 0-49 as | ||
| Default, 50-99 as Mod and 100 as Admin or alternatively create tag automatically as Default for 0, | ||
| Mod for 50 and 100 for Admin. | ||
|
|
||
| #### What if we have power level with undefined tag? | ||
|
|
||
| If a power level is not defined client can consider to display it with the lower defined power level | ||
| tag. If there is no lower defined tag, client can consider displaying tag defined with | ||
| `m.room.power_level_tag` state event + state key as `"state_key": ""`, if no such event find client | ||
| can display it power level itself or with the way of it's own choice. | ||
|
|
||
| ### What else it fix? | ||
|
|
||
| This will also fix problem defined in [MSC3915: Owner power | ||
| level](https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/owner-pl/proposals/3915-owner-power-level.md). | ||
|
|
||
| ## Alternatives | ||
|
|
||
| None? | ||
|
There was a problem hiding this comment. Roles instead of powerlevels would be imho a note worthy alternative even though there is no msc for it that I am aware of. There was a problem hiding this comment. This is as close as you get to roles without going for RBAC or hacking in full roles that dont matter auth wise. If you ask me. So its an alternative that should be mentioned but still. There was a problem hiding this comment. There is an RBAC MSC in #2812 that could be an alternative, but I think that implementing this MSC is a lot smaller than replacing the power levels with an RBAC system. There was a problem hiding this comment. Rather than using one state event per state key, you could put all the labels in a single event, with a map from PL to label. e.g. {
"type": "m.room.power_level_tags",
"state_key": "",
"content": {
"100": {
"name": "Admin",
// ...
}
}
}There was a problem hiding this comment. My only concern is event size overflow. Maybe we should restrict the name value to like 50 character? There was a problem hiding this comment. Possibly. I'm not suggesting that the alternative that I gave is better (or worse) than what you suggested, but it should probably be listed as an alternative, so that the pros and cons can be discussed. The reason I suggested that alternative is because it is more similar to how some other state events work (notably the power levels event itself), so it seems to be an obvious way to do things. Though of course, obvious doesn't mean better. |
||
|
|
||
| ## Security considerations | ||
|
|
||
| None? | ||
|
|
||
| ## Unstable prefix | ||
|
|
||
| TODO | ||
|
|
||
| ## Dependencies | ||
|
|
||
| None? | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this replace
m.room.power_levels? Or does it add another layer to it? If it adds a layer why not add it within that state Event?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is clearly a PL Labels MSC and therefore drop in backwards compatible with all room versions and all existing homeserver implementations and clients that follow the spec due to that it will be ignored safely by non implementing stakeholders.