* Placeholder * i++ * Room version 12 Template out a v12 room version Make v12 default, per MSC4304 Update PDU checks and auth event selection per MSC4291 Describe new room_id format per MSC4291 Move v6 depth definition to a component for easier referencing Move room_id to a component to prep for v12, per MSC4291 Create and use a new room_id component for v12+ per MSC4291 Reflect auth events selection change onto all room versions per MSC4291 The MSC asks the `description` of `auth_events` to be adjusted, however this feels like a better representation of the change. Add `room_id` format rules and renumber per MSC4291 Reflect change to rule 1.2 per MSC4291 Insert same room_id check to v1-12 auth rules per MSC4307 and MSC4291 Deprecate `predecessor.event_id` per MSC4291 Insert auth rule to validate `additional_creators` per MSC4289 Insert rule for `users` validation of creators and renumber per MSC4289 Define "room creator(s)" per MSC4289 Spec `additional_creators` on create events per MSC4289 Spec `additional_creators` on `/upgrade` per MSC4289 The MSC doesn't mention how to handle unsupported room versions, but the Synapse implementation used for FCP ignores the field in such room versions. This feels like a good approach, and will need clarifying in the MSC too (if accepted at the spec level). Add notes to `/upgrade` behaviour per MSC4289 and MSC4291 Describe how additional creators work during room creation per MSC4289 Fix default user power level descriptions per MSC4289 Describe tombstone power level changes per MSC4289 Warn clients about event format changes in v12 per MSC4289 and MSC4291 Flag additional room creators support for client reference per MSC4289 Remove TODO now that it's fully addressed Copy state res into v12 as-is for modification Apply Modification 1 to SR2.1 per MSC4297 Apply Modification 2 to SR2.1 per MSC4297 Add summary box to the top of SR2.1 for ease of developer reference Modification 2 was split into items 2 and 3 for further ease of understanding. Add all the changelogs `x` is used until a real PR number can be assigned. Some changelogs are duplicated to the Client-Server API to increase visibility of the changes to v12. Review: Minor phrasing adjustments in changelogs Review: Clarify that v12 isn't quite the default yet in the changelog Review: Clarify to clients that creators are immutable Review: Improve 'how to parse a domain' advice for legacy apps Review: Add a bit more detail as to why a room ID might be required Apply suggestions from code review Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Clarify that clients can override the tombstone default Mention creatorship UI label by finishing the Permissions section We probably should have removed the WIP note in v1.0, but alas. Add changelog for tombstone changes Use assigned spec PR number in changelogs (cherry picked from commit ec81eea7e4532fd398b8013071d6981c97117d9e)
7.8 KiB
The types of state events that affect authorization are:
{{% boxes/note %}}
Power levels are inferred from defaults when not explicitly supplied.
For example, mentions of the sender's power level can also refer to
the default power level for users in the room.
{{% /boxes/note %}}
The rules are as follows:
- If type is
m.room.create:- If it has any
prev_events, reject. - If the domain of the
room_iddoes not match the domain of thesender, reject. - If
content.room_versionis present and is not a recognised version, reject. - If
contenthas nocreatorproperty, reject. - Otherwise, allow.
- If it has any
- Considering the event's
auth_events:-
If there are duplicate entries for a given
typeandstate_keypair, reject. -
If there are entries whose
typeandstate_keydon't match those specified by the auth events selection algorithm described in the server specification, reject.Note: This room version requires an
m.room.createevent to be selected. -
If there are entries which were themselves rejected under the checks performed on receipt of a PDU, reject.
-
If there is no
m.room.createevent among the entries, reject. -
If any event in
auth_eventshas aroom_idwhich does not match that of the event being authorised, reject.
-
- If the
contentof them.room.createevent in the room state has the propertym.federateset tofalse, and thesenderdomain of the event does not match thesenderdomain of the create event, reject. - If type is
m.room.aliases:- If event has no
state_key, reject. - If sender's domain doesn't match
state_key, reject. - Otherwise, allow.
- If event has no
- If type is
m.room.member:- If there is no
state_keyproperty, or nomembershipproperty incontent, reject. - If
membershipisjoin:- If the only previous event is an
m.room.createand thestate_keyis the creator, allow. - If the
senderdoes not matchstate_key, reject. - If the
senderis banned, reject. - If the
join_ruleisinvitethen allow if membership state isinviteorjoin. - If the
join_ruleispublic, allow. - Otherwise, reject.
- If the only previous event is an
- If
membershipisinvite:- If
contenthas athird_party_inviteproperty:- If target user is banned, reject.
- If
content.third_party_invitedoes not have asignedproperty, reject. - If
signeddoes not havemxidandtokenproperties, reject. - If
mxiddoes not matchstate_key, reject. - If there is no
m.room.third_party_inviteevent in the current room state withstate_keymatchingtoken, reject. - If
senderdoes not matchsenderof them.room.third_party_invite, reject. - If any signature in
signedmatches any public key in them.room.third_party_inviteevent, allow. The public keys are incontentofm.room.third_party_inviteas:- A single public key in the
public_keyproperty. - A list of public keys in the
public_keysproperty.
- A single public key in the
- Otherwise, reject.
- If the
sender's current membership state is notjoin, reject. - If target user's current membership state is
joinorban, reject. - If the
sender's power level is greater than or equal to the invite level, allow. - Otherwise, reject.
- If
- If
membershipisleave:- If the
sendermatchesstate_key, allow if and only if that user's current membership state isinviteorjoin. - If the
sender's current membership state is notjoin, reject. - If the target user's current membership state is
ban, and thesender's power level is less than the ban level, reject. - If the
sender's power level is greater than or equal to the kick level, and the target user's power level is less than thesender's power level, allow. - Otherwise, reject.
- If the
- If
membershipisban:- If the
sender's current membership state is notjoin, reject. - If the
sender's power level is greater than or equal to the ban level, and the target user's power level is less than thesender's power level, allow. - Otherwise, reject.
- If the
- Otherwise, the membership is unknown. Reject.
- If there is no
- If the
sender's current membership state is notjoin, reject. - If type is
m.room.third_party_invite:- Allow if and only if
sender's current power level is greater than or equal to the invite level.
- Allow if and only if
- If the event type's required power level is greater than the
sender's power level, reject. - If the event has a
state_keythat starts with an@and does not match thesender, reject. - If type is
m.room.power_levels:- If the
usersproperty incontentis not an object with keys that are valid user IDs with values that are integers (or a string that is an integer), reject. - If there is no previous
m.room.power_levelsevent in the room, allow. - For the properties
users_default,events_default,state_default,ban,redact,kick,invitecheck if they were added, changed or removed. For each found alteration:- If the current value is greater than the
sender's current power level, reject. - If the new value is greater than the
sender's current power level, reject.
- If the current value is greater than the
- For each entry being changed in, or removed from, the
eventsproperty:- If the current value is greater than the
sender's current power level, reject.
- If the current value is greater than the
- For each entry being added to, or changed in, the
eventsproperty:- If the new value is greater than the
sender's current power level, reject.
- If the new value is greater than the
- For each entry being changed in, or removed from, the
usersproperty, other than thesender's own entry:- If the current value is greater than or equal to the
sender's current power level, reject.
- If the current value is greater than or equal to the
- For each entry being added to, or changed in, the
usersproperty:- If the new value is greater than the
sender's current power level, reject.
- If the new value is greater than the
- Otherwise, allow.
- If the
- If type is
m.room.redaction:- If the
sender's power level is greater than or equal to the redact level, allow. - If the domain of the
event_idof the event being redacted is the same as the domain of theevent_idof them.room.redaction, allow. - Otherwise, reject.
- If the
- Otherwise, allow.
{{% boxes/note %}} Some consequences of these rules:
- Unless you are a member of the room, the only permitted operations (apart from the initial create/join) are: joining a public room; accepting or rejecting an invitation to a room.
- To unban somebody, you must have power level greater than or equal to both the kick and ban levels, and greater than the target user's power level. {{% /boxes/note %}}