Clean-up intro paragraphs for redactions.

This commit is contained in:
Patrick Cloke 2023-08-09 14:35:52 -04:00
parent 9ed38bcb66
commit e2310edfb0
4 changed files with 30 additions and 33 deletions

View file

@ -1,14 +1,3 @@
---
---
{{% added-in this=true %}} The top-level `origin`, `membership`, and `prev_state` properties
are no longer protected from redaction. The [`m.room.create`](/client-server-api#mroomcreate)
event now keeps the entire `content` property. The [`m.room.redaction`](/client-server-api#mroomredaction)
event keeps the `redacts` property under `content`. The
[`m.room.power_levels`](/client-server-api#mroompower_levels) event keeps the
`invite` property under `content`.
The full redaction algorithm follows.
Upon receipt of a redaction event, the server must strip off any keys
not in the following list:

View file

@ -1,25 +1,3 @@
---
---
{{% added-in this=true %}} [`m.room.member`](/client-server-api#mroommember) events
now keep `join_authorised_via_users_server` in addition to other keys in `content`
when being redacted.
{{% boxes/rationale %}}
Without the `join_authorised_via_users_server` property, redacted join events
can become invalid when verifying the auth chain of a given event, thus creating
a split-brain scenario where the user is able to speak from one server's
perspective but most others will continually reject their events.
This can theoretically be worked around with a rejoin to the room, being careful
not to use the faulty events as `prev_events`, though instead it is encouraged
to use v9 rooms over v8 rooms to outright avoid the situation.
[Issue #3373](https://github.com/matrix-org/matrix-doc/issues/3373) has further
information.
{{% /boxes/rationale %}}
The full redaction algorithm follows.
Upon receipt of a redaction event, the server must strip off any keys
not in the following list:

View file

@ -22,6 +22,15 @@ events is no longer redacted, *but* will only contain the `signed` key after red
### Redactions
{{% added-in this=true %}} The top-level `origin`, `membership`, and `prev_state` properties
are no longer protected from redaction. The [`m.room.create`](/client-server-api#mroomcreate)
event now keeps the entire `content` property. The [`m.room.redaction`](/client-server-api#mroomredaction)
event keeps the `redacts` property under `content`. The
[`m.room.power_levels`](/client-server-api#mroompower_levels) event keeps the
`invite` property under `content`.
The full redaction algorithm follows.
{{% rver-fragment name="v11-redactions" withVersioning="true" %}}
## Server implementation components

View file

@ -17,6 +17,27 @@ Clients which implement the redaction algorithm locally should refer to the
### Redactions
{{% added-in this=true %}} [`m.room.member`](/client-server-api#mroommember) events
now keep `join_authorised_via_users_server` in addition to other keys in `content`
when being redacted.
{{% boxes/rationale %}}
Without the `join_authorised_via_users_server` property, redacted join events
can become invalid when verifying the auth chain of a given event, thus creating
a split-brain scenario where the user is able to speak from one server's
perspective but most others will continually reject their events.
This can theoretically be worked around with a rejoin to the room, being careful
not to use the faulty events as `prev_events`, though instead it is encouraged
to use v9 rooms over v8 rooms to outright avoid the situation.
[Issue #3373](https://github.com/matrix-org/matrix-doc/issues/3373) has further
information.
{{% /boxes/rationale %}}
The full redaction algorithm follows.
{{% rver-fragment name="v9-redactions" withVersioning="true" %}}
## Server implementation components