2.8 KiB
| title | type | weight |
|---|---|---|
| Room Version 6 | docs | 60 |
This room version builds on version 5 while changing various authorization rules performed on events.
Client considerations
The redaction algorithm has changed from room version 1 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.
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 (the last inherited room version to specify the authorization rules).
Canonical JSON
Servers MUST strictly enforce the JSON format specified in the
appendices. 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.