mirror of
https://github.com/matrix-org/matrix-spec
synced 2025-12-20 16:38:37 +01:00
74c51b05a4
MSC: https://github.com/matrix-org/matrix-doc/pull/2209 The changes are slightly difficult to word without dumping the text in and playing a game of spot the difference, so we now use our pre-existing pygments support to render a representation of the difference. The difference is shown in markdown-like format instead of RST for ease of understanding. It's also not rendered HTML for largely complexity reasons.
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).
|