You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The /createRoom API provides clients with two options to set the m.room.power_levels event.
power_level_content_override is merged into the default power-level event and inserted as the first event after m.room.create and the room creator's m.room.member event.
Events in initial_state are inserted towards the end of room creation but before m.room.name, m.room.topic and any invites.
Regardless of whether the order from the spec or from Synapse is used, it's not possible for a room creator to fully demote themselves at the end of room creation through /createRoom. With the spec'ed behavior, further state events are sent after initial_state which prevents taking away power levels for these events via initial_state. With Synapse's behavior, power levels can only be applied at the beginning of room creation which disables most if not all practical demotion options. While it's possible to demote yourself by sending another request after room creation, this makes the initial_state parameter less useful than it could be.
Suggestion
The discrepancy between Synapse and the spec should be resolved.
initial_state (or something similar) should be applied in step 8 rather than 6
This is a mix of clarification and suggestion but since the two issues correlate I thought it'd be better to create a single issue.
Link to problem area:
https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3createroom
Issue
The
/createRoom
API provides clients with two options to set them.room.power_levels
event.power_level_content_override
is merged into the default power-level event and inserted as the first event afterm.room.create
and the room creator'sm.room.member
event.Events in
initial_state
are inserted towards the end of room creation but beforem.room.name
,m.room.topic
and any invites.There are two issues here:
initial_state
in the place wherepower_level_content_override
should be applied, ignoring the former. According to Synapse does not respect event order of spec /createRoom synapse#11731 (comment) 1 this is deemed the preferred behavior./createRoom
. With the spec'ed behavior, further state events are sent afterinitial_state
which prevents taking away power levels for these events viainitial_state
. With Synapse's behavior, power levels can only be applied at the beginning of room creation which disables most if not all practical demotion options. While it's possible to demote yourself by sending another request after room creation, this makes theinitial_state
parameter less useful than it could be.Suggestion
initial_state
(or something similar) should be applied in step 8 rather than 6Footnotes
Note that this issue continues at https://github.com/element-hq/synapse/issues/11731 ↩
The text was updated successfully, but these errors were encountered: