You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
236 lines
9.6 KiB
Markdown
236 lines
9.6 KiB
Markdown
---
|
|
title: Room Version 6
|
|
type: docs
|
|
weight: 60
|
|
---
|
|
|
|
This room version builds on [version 5](/rooms/v5) while changing various
|
|
authorization rules performed on events.
|
|
|
|
## Client considerations
|
|
|
|
There are no client considerations introduced in this room version. Clients
|
|
which implement the redaction algorithm locally should refer to the
|
|
[redactions](#redactions) section below for a full overview of the algorithm.
|
|
|
|
### Redactions
|
|
|
|
{{% added-in this=true %}} All significant meaning for `m.room.aliases`
|
|
has been removed from the redaction algorithm. The remaining rules are
|
|
the same as past room versions.
|
|
|
|
{{% rver-fragment name="v6-redactions" %}}
|
|
|
|
## 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 %}}
|
|
|
|
Room version 6 makes the following alterations to algorithms described
|
|
in [room version 5](/rooms/v5).
|
|
|
|
### Redactions
|
|
|
|
[See above](#redactions).
|
|
|
|
### Authorization rules
|
|
|
|
`m.room.redaction` events are not explicitly part of the auth rules.
|
|
They are still subject to the minimum power level rules, but should always
|
|
fall into "10. Otherwise, allow". Instead of being authorized at the time
|
|
of receipt, they are authorized at a later stage: see the
|
|
[Handling Redactions](#handling-redactions) section below for more information.
|
|
|
|
{{< added-in this=true >}} Rule 4, which related specifically to events
|
|
of type `m.room.aliases`, is removed. `m.room.aliases` events must still pass
|
|
authorization checks relating to state events.
|
|
|
|
{{< added-in this=true >}} Additionally, the authorization rules for events of
|
|
type `m.room.power_levels` now include a `notifications` property under
|
|
`content`. This updates rules 10.4 and 10.5 (now 9.4 and 9.5), which checked
|
|
the `events` property.
|
|
|
|
Events must be signed by the server denoted by the `sender` property.
|
|
|
|
The types of state events that affect authorization are:
|
|
|
|
- [`m.room.create`](/client-server-api#mroomcreate)
|
|
- [`m.room.member`](/client-server-api#mroommember)
|
|
- [`m.room.join_rules`](/client-server-api#mroomjoin_rules)
|
|
- [`m.room.power_levels`](/client-server-api#mroompower_levels)
|
|
- [`m.room.third_party_invite`](/client-server-api#mroomthird_party_invite)
|
|
|
|
{{% 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:
|
|
|
|
1. If type is `m.room.create`:
|
|
1. If it has any `prev_events`, reject.
|
|
2. If the domain of the `room_id` does not match the domain of the
|
|
`sender`, reject.
|
|
3. If `content.room_version` is present and is not a recognised
|
|
version, reject.
|
|
4. If `content` has no `creator` property, reject.
|
|
5. Otherwise, allow.
|
|
2. Reject if event has `auth_events` that:
|
|
1. have duplicate entries for a given `type` and `state_key` pair
|
|
2. have entries whose `type` and `state_key` don't match those
|
|
specified by the [auth events
|
|
selection](/server-server-api#auth-events-selection)
|
|
algorithm described in the server specification.
|
|
3. If event does not have a `m.room.create` in its `auth_events`,
|
|
reject.
|
|
4. If type is `m.room.member`:
|
|
1. If there is no `state_key` property, or no `membership` property in
|
|
`content`, reject.
|
|
2. If `membership` is `join`:
|
|
1. If the only previous event is an `m.room.create` and the
|
|
`state_key` is the creator, allow.
|
|
2. If the `sender` does not match `state_key`, reject.
|
|
3. If the `sender` is banned, reject.
|
|
4. If the `join_rule` is `invite` then allow if membership
|
|
state is `invite` or `join`.
|
|
5. If the `join_rule` is `public`, allow.
|
|
6. Otherwise, reject.
|
|
3. If `membership` is `invite`:
|
|
1. If `content` has a `third_party_invite` property:
|
|
1. If *target user* is banned, reject.
|
|
2. If `content.third_party_invite` does not have a `signed`
|
|
property, reject.
|
|
3. If `signed` does not have `mxid` and `token` properties,
|
|
reject.
|
|
4. If `mxid` does not match `state_key`, reject.
|
|
5. If there is no `m.room.third_party_invite` event in the
|
|
current room state with `state_key` matching `token`,
|
|
reject.
|
|
6. If `sender` does not match `sender` of the
|
|
`m.room.third_party_invite`, reject.
|
|
7. If any signature in `signed` matches any public key in
|
|
the `m.room.third_party_invite` event, allow. The public
|
|
keys are in `content` of `m.room.third_party_invite` as:
|
|
1. A single public key in the `public_key` property.
|
|
2. A list of public keys in the `public_keys` property.
|
|
8. Otherwise, reject.
|
|
2. If the `sender`'s current membership state is not `join`,
|
|
reject.
|
|
3. If *target user*'s current membership state is `join` or
|
|
`ban`, reject.
|
|
4. If the `sender`'s power level is greater than or equal to
|
|
the *invite level*, allow.
|
|
5. Otherwise, reject.
|
|
4. If `membership` is `leave`:
|
|
1. If the `sender` matches `state_key`, allow if and only if
|
|
that user's current membership state is `invite` or `join`.
|
|
2. If the `sender`'s current membership state is not `join`,
|
|
reject.
|
|
3. If the *target user*'s current membership state is `ban`,
|
|
and the `sender`'s power level is less than the *ban level*,
|
|
reject.
|
|
4. 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 the `sender`'s power level, allow.
|
|
5. Otherwise, reject.
|
|
5. If `membership` is `ban`:
|
|
1. If the `sender`'s current membership state is not `join`,
|
|
reject.
|
|
2. 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 the `sender`'s power level, allow.
|
|
3. Otherwise, reject.
|
|
6. Otherwise, the membership is unknown. Reject.
|
|
5. If the `sender`'s current membership state is not `join`, reject.
|
|
6. If type is `m.room.third_party_invite`:
|
|
1. Allow if and only if `sender`'s current power level is greater
|
|
than or equal to the *invite level*.
|
|
7. If the event type's *required power level* is greater than the
|
|
`sender`'s power level, reject.
|
|
8. If the event has a `state_key` that starts with an `@` and does not
|
|
match the `sender`, reject.
|
|
9. If type is `m.room.power_levels`:
|
|
1. If the `users` property in `content` is not an object with keys that
|
|
are valid user IDs with values that are integers (or a string
|
|
that is an integer), reject.
|
|
2. If there is no previous `m.room.power_levels` event in the room,
|
|
allow.
|
|
3. 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:
|
|
1. If the current value is higher than the `sender`'s current
|
|
power level, reject.
|
|
2. If the new value is higher than the `sender`'s current power
|
|
level, reject.
|
|
4. {{< changed-in this="true" >}}
|
|
For each entry being changed in, or removed from, the `events` or
|
|
`notifications` properties:
|
|
1. If the current value is greater than the `sender`'s current
|
|
power level, reject.
|
|
5. {{< changed-in this="true" >}}
|
|
For each entry being added to, or changed in, the `events` or
|
|
`notifications` properties:
|
|
1. If the new value is greater than the `sender`'s current power
|
|
level, reject.
|
|
6. For each entry being changed in, or removed from, the `users` property,
|
|
other than the `sender`'s own entry:
|
|
1. If the current value is greater than or equal to the `sender`'s
|
|
current power level, reject.
|
|
7. For each entry being added to, or changed in, the `users` property:
|
|
1. If the new value is greater than the `sender`'s current power
|
|
level, reject.
|
|
8. Otherwise, allow.
|
|
10. 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 %}}
|
|
|
|
### Canonical JSON
|
|
|
|
{{% rver-fragment name="v6-canonical-json" %}}
|
|
|
|
## Unchanged from v5
|
|
|
|
The following sections have not been modified since v5, but are included for
|
|
completeness.
|
|
|
|
### Handling redactions
|
|
|
|
{{% rver-fragment name="v3-handling-redactions" %}}
|
|
|
|
### Event IDs
|
|
|
|
{{% rver-fragment name="v4-event-ids" %}}
|
|
|
|
### Event format
|
|
|
|
{{% rver-fragment name="v4-event-format" %}}
|
|
|
|
#### Deprecated event content schemas
|
|
|
|
{{% rver-fragment name="v1-deprecated-formatting-off-spec" %}}
|
|
|
|
{{% rver-fragment name="v1-stringy-power-levels" %}}
|
|
|
|
### State resolution
|
|
|
|
{{% rver-fragment name="v2-state-res" %}}
|
|
|
|
### Signing key validity period
|
|
|
|
{{% rver-fragment name="v5-signing-requirements" %}}
|