MSC3214: Allow overriding m.room.power_levels using initial_state#3214
MSC3214: Allow overriding m.room.power_levels using initial_state#3214tulir wants to merge 1 commit into
m.room.power_levels using initial_state#3214Conversation
Signed-off-by: Tulir Asokan <tulir@maunium.net>
uhoreg
added
kind:maintenance
| `power_level_content_override` can technically be used to undo everything in | ||
| the default power levels, but it's more convenient and intuitive if | ||
| `initial_state` can be used to simply replace the first power level event. |
There was a problem hiding this comment.
I'm having troubles seeing why this isn't acceptable for an approach: changing the semantics of initial_state for one event type feels overly wrong, and power_level_content_override is perfectly able to accept a complete content.
Is the primary concern code cleanliness?
| levels. The spec defines a `power_level_content_override` field that is applied | ||
| on top of the default power levels for this purpose. However, that field can't | ||
| easily replace the entire default content, as it gets merged with the default | ||
| levels. |
There was a problem hiding this comment.
Do you think power_level_content_override should be deprecated?
There was a problem hiding this comment.
I think that this MSC complicates the situation of initial_state vs override a bit, as override overrides certain bits of the to-be-created state event, while initial_state would replace the entire powerlevels event.
This would create different results on different room versions, if the default powerlevels would ever be changed.
| Synapse already allows replacing the entire power level event content by | ||
| placing a power level event in `initial_state`. However, interpreting the spec | ||
| literally means inserting the default power level event first, then inserting | ||
| the one from `initial_state`, which might not be possible due to auth rules | ||
| anymore. |
There was a problem hiding this comment.
For reference, the algorithm seems to have been specced in 2016 by #362. Synapse's implementation was changed in 2017 by matrix-org/synapse#2291, but that did not get transferred to the spec.
| Server implementations will have to separately check for `m.room.power_levels` | ||
| events in the `initial_state` list, which is slightly more effort than the | ||
| current flow. | ||
|
|
There was a problem hiding this comment.
This breaks some approaches of sending PLs. While those currently also don't work on synapse, they should and imo it is a bug.
I.e. imagine you want to demote yourself after creating the room. Currently you should be able to send an override, where you are PL100, add events to initial_state, that require PL100 to send and then as the last event in initial_state you send a PL event that demotes you. While that is a niche usecase, it occasionally comes up and it is currently impossible to do without doing 2 separate requests. Otoh, the only thing this MSC achieves is make the power level overrides unnecessary, but it doesn't enable any usecases that couldn't be done by just putting the PL content into the override instead.
See also: matrix-org/synapse#11731 (comment)
| events in the `initial_state` list, which is slightly more effort than the | ||
| current flow. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Instead of applying only m.room.power_levels from initial_state in step 3, could you apply power_level_content_override in step 6 if and only if initial_state contains no power levels event? This way the contents of initial_state would not be processed in different steps.
8 participants
Rendered
Synapse implementation
Dendrite implementation
mautrix-signal implementation