You're looking at an unstable version of this specification. Unstable specifications may change at any time without notice.
Room Version 6
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
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.