matrix-spec-proposals/content/rooms/v6.md

---
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.