This room version builds on version 5 while changing various authorization rules performed on events.
Table of Contents
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.
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.
Room version 6 makes the following alterations to algorithms described in room version 5.
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.
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).
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.