|
|
|
|
---
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
The redaction algorithm has changed from [room version 1](/rooms/v1) to
|
|
|
|
|
remove all rules against events of type `m.room.aliases`. Room versions
|
|
|
|
|
2, 3, 4, and 5 all use v1's redaction algorithm. The algorithm is
|
|
|
|
|
otherwise unchanged.
|
|
|
|
|
|
|
|
|
|
## 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
|
|
|
|
|
|
|
|
|
|
As mentioned in the client considerations portion of this specification,
|
|
|
|
|
all special meaning has been removed for events of type
|
|
|
|
|
`m.room.aliases`. The algorithm is otherwise unchanged.
|
|
|
|
|
|
|
|
|
|
### Authorization rules for events
|
|
|
|
|
|
|
|
|
|
Like redactions, all rules relating specifically to events of type
|
|
|
|
|
`m.room.aliases` are removed. They must still pass authorization checks
|
|
|
|
|
relating to state events.
|
|
|
|
|
|
|
|
|
|
Additionally, the authorization rules for events of type
|
|
|
|
|
`m.room.power_levels` now include the content key `notifications`. This
|
|
|
|
|
new rule takes the place of the rule which checks the `events` and
|
|
|
|
|
`users` keys.
|
|
|
|
|
|
|
|
|
|
For completeness, the changes to the auth rules can be represented as
|
|
|
|
|
follows:
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
-If type is `m.room.aliases`:
|
|
|
|
|
-
|
|
|
|
|
- a. If event has no `state_key`, reject.
|
|
|
|
|
- b. If sender's domain doesn't matches `state_key`, reject.
|
|
|
|
|
- c. Otherwise, allow.
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
If type is `m.room.power_levels`:
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
- * For each entry being added, changed or removed in both the `events` and `users` keys:
|
|
|
|
|
+ * For each entry being added, changed or removed in the `events`, `users`, and `notifications` keys:
|
|
|
|
|
|
|
|
|
|
i. If the current value is higher than the `sender`'s current power level, reject.
|
|
|
|
|
|
|
|
|
|
ii. If the new value is higher than the `sender`'s current power level, reject.
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
The remaining rules are the same as in [room version
|
|
|
|
|
3](/rooms/v3#authorization-rules-for-events) (the last inherited room
|
|
|
|
|
version to specify the authorization rules).
|
|
|
|
|
|
|
|
|
|
### Canonical JSON
|
|
|
|
|
|
|
|
|
|
Servers MUST strictly enforce the JSON format specified in the
|
|
|
|
|
[appendices](/appendices#canonical-json). This translates to a
|
|
|
|
|
400 `M_BAD_JSON` error on most endpoints, or discarding of events over
|
|
|
|
|
federation. For example, the Federation API's `/send` endpoint would
|
|
|
|
|
discard the event whereas the Client Server API's `/send/{eventType}`
|
|
|
|
|
endpoint would return a `M_BAD_JSON` error.
|
