13 KiB
title | type | weight |
---|---|---|
Room Version 11 | docs | 100 |
This room version builds on version 10 while clarifying redaction rules.
Client considerations
Redactions
{{< added-in this=true >}} The top-level origin
, membership
, and prev_state
properties
are no longer protected from redaction. The m.room.create
event now keeps the entire content
property. The m.room.redaction
event keeps the redacts
property under content
. The
m.room.power_levels
event keeps the
invite
property under content
.
The full redaction algorithm follows.
{{% rver-fragment name="v11-redactions" withVersioning="true" %}}
Event format
Clients should no longer depend on the creator
property in the content
of
m.room.create
events. In all room versions,
clients can rely on sender
instead to determine a room creator.
The format of m.room.redaction
events has been modified. Client should look for the redacts
key under content
instead of a top-level event property.
The third_party_invite
key of m.room.member
events is no longer redacted, but will only contain the signed
key after redaction.
Server implementation components
{{% boxes/warning %}} The information contained in this section is strictly for server implementors. Applications which use the Client-Server API are generally unaffected by the intricacies contained here. The section above regarding client considerations is the resource that Client-Server API use cases should reference. {{% /boxes/warning %}}
This room version updates the redaction algorithm and modifies how servers should
create m.room.create
and m.room.redaction
events.
Room version 11 is based upon room version 10 with the following considerations.
Redactions
Event format
The core event format is the same as room version 10. However, this room version changes some properties of some event types.
{{% rver-fragment name="v11-event-format" %}}
Remove the creator
property of m.room.create
events
The content
of a m.room.create
event no longer has a creator
property,
which previously was always equivalent to the sender
of the event.
Moving the redacts
property of m.room.redaction
events to a content
property
The redacts
property of m.room.redaction
events is moved from a top-level
event property to a property under the event content
.
For backwards-compatibility with older clients, servers should add a redacts
property
to the top level of m.room.redaction
events in when serving such events over the
Client-Server API.
For improved compatibility with newer clients, servers should add a redacts
property
to the content
of m.room.redaction
events in older room versions when serving
such events over the Client-Server API.
Authorization rules
Events must be signed by the server denoted by the sender
property.
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 %}}
{{% boxes/note %}}
m.room.redaction
events are subject to auth rules in the same way as any other event.
In practice, that means they will normally be allowed by the auth rules, unless the
m.room.power_levels
event sets a power level requirement for m.room.redaction
events via the events
or events_default
properties. In particular, the redact
level is not considered by the auth rules.
The ability to send a redaction event does not mean that the redaction itself should be performed. Receiving servers must perform additional checks, as described in the Handling redactions section. {{% /boxes/note %}}
The rules are as follows:
- {{< changed-in this="true" >}}
If type is
m.room.create
:- If it has any
prev_events
, reject. - If the domain of the
room_id
does not match the domain of thesender
, reject. - If
content.room_version
is present and is not a recognised version, reject. - Otherwise, allow.
- If it has any
- Considering the event's
auth_events
:- If there are duplicate entries for a given
type
andstate_key
pair, reject. - If there are entries whose
type
andstate_key
don't match those specified by the auth events selection algorithm described in the server specification, reject. - If there are entries which were themselves rejected under the checks performed on receipt of a PDU, reject.
- If there is no
m.room.create
event among the entries, reject.
- If there are duplicate entries for a given
- If the
content
of them.room.create
event in the room state has the propertym.federate
set tofalse
, and thesender
domain of the event does not match thesender
domain of the create event, reject. - If type is
m.room.member
:- If there is no
state_key
property, or nomembership
property incontent
, reject. - If
content
has ajoin_authorised_via_users_server
key:- If the event is not validly signed by the homeserver of the user ID denoted by the key, reject.
- If
membership
isjoin
:- {{< changed-in this="true" >}}
If the only previous event is an
m.room.create
and thestate_key
is the sender, allow. - If the
sender
does not matchstate_key
, reject. - If the
sender
is banned, reject. - If the
join_rule
isinvite
orknock
then allow if membership state isinvite
orjoin
. - If the
join_rule
isrestricted
orknock_restricted
:- If membership state is
join
orinvite
, allow. - If the
join_authorised_via_users_server
key incontent
is not a user with sufficient permission to invite other users, reject. - Otherwise, allow.
- If membership state is
- If the
join_rule
ispublic
, allow. - Otherwise, reject.
- {{< changed-in this="true" >}}
If the only previous event is an
- If
membership
isinvite
:- If
content
has athird_party_invite
property:- If target user is banned, reject.
- If
content.third_party_invite
does not have asigned
property, reject. - If
signed
does not havemxid
andtoken
properties, reject. - If
mxid
does not matchstate_key
, reject. - If there is no
m.room.third_party_invite
event in the current room state withstate_key
matchingtoken
, reject. - If
sender
does not matchsender
of them.room.third_party_invite
, reject. - If any signature in
signed
matches any public key in them.room.third_party_invite
event, allow. The public keys are incontent
ofm.room.third_party_invite
as:- A single public key in the
public_key
property. - A list of public keys in the
public_keys
property.
- 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
join
orban
, reject. - If the
sender
's power level is greater than or equal to the invite level, allow. - Otherwise, reject.
- If
- If
membership
isleave
:- If the
sender
matchesstate_key
, allow if and only if that user's current membership state isinvite
,join
, orknock
. - 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
membership
isban
:- 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
- If
membership
isknock
:- If the
join_rule
is anything other thanknock
orknock_restricted
, reject. - If
sender
does not matchstate_key
, reject. - If the
sender
's current membership is notban
,invite
, orjoin
, 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_key
that starts with an@
and does not match thesender
, reject. - If type is
m.room.power_levels
:- If any of the properties
users_default
,events_default
,state_default
,ban
,redact
,kick
, orinvite
incontent
are present and not an integer, reject. - If either of the properties
events
ornotifications
incontent
are present and not an object with values that are integers, reject. - If the
users
property incontent
is not an object with keys that are valid user IDs with values that are integers, reject. - If there is no previous
m.room.power_levels
event in the room, allow. - For the properties
users_default
,events_default
,state_default
,ban
,redact
,kick
,invite
check if they were added, changed or removed. For each found alteration:- If the current value is higher than the
sender
's current power level, reject. - If the new value is higher than the
sender
's current power level, reject.
- If the current value is higher than the
- For each entry being changed in, or removed from, the
events
ornotifications
properties:- 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
events
ornotifications
properties:- 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
users
property, 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
users
property:- 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 any of the properties
- 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 %}}
Unchanged from v10
The following sections have not been modified since v10, but are included for completeness.
Handling redactions
{{% rver-fragment name="v3-handling-redactions" %}}
Event IDs
{{% rver-fragment name="v4-event-ids" %}}
State resolution
{{% rver-fragment name="v2-state-res" %}}
Canonical JSON
{{% rver-fragment name="v6-canonical-json" %}}
Signing key validity period
{{% rver-fragment name="v5-signing-requirements" %}}