You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
92 lines
3.1 KiB
ReStructuredText
92 lines
3.1 KiB
ReStructuredText
.. 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).
|