.. Copyright 2020 The Matrix.org Foundation C.I.C.
..
.. Licensed under the Apache License, Version 2.0 (the "License");
.. you may not use this file except in compliance with the License.
.. You may obtain a copy of the License at
..
..     http://www.apache.org/licenses/LICENSE-2.0
..
.. Unless required by applicable law or agreed to in writing, software
.. distributed under the License is distributed on an "AS IS" BASIS,
.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
.. See the License for the specific language governing permissions and
.. limitations under the License.

Room Version 6
==============

This room version builds on `version 5 <v5.html>`_ while changing various
authorization rules performed on events.

.. contents:: Table of Contents
.. sectnum::


Client considerations
---------------------

The redaction algorithm has changed from `room version 1 <v1.html>`_ 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
--------------------------------

.. 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 <v5.html>`_.

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:

.. code:: diff

     ...

    -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 <v3.html#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.html#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.