Clarify how redacted_because actually works for events (#3411)
* Clarify how redacted_because actually works for events * changelog * mention federation * Fix wording Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
This commit is contained in:
parent
6e78cde3eb
commit
7e67aa2e23
2 changed files with 6 additions and 7 deletions
|
@ -0,0 +1 @@
|
|||
Clarify how `redacted_because` is meant to work.
|
|
@ -1593,17 +1593,15 @@ some events cannot be simply deleted, e.g. membership events, we instead
|
|||
not required by the protocol. This stripped down event is thereafter
|
||||
returned anytime a client or remote server requests it. Redacting an
|
||||
event cannot be undone, allowing server owners to delete the offending
|
||||
content from the databases. Events that have been redacted include a
|
||||
`redacted_because` key whose value is the event that caused it to be
|
||||
redacted, which may include a reason.
|
||||
content from the databases. Servers should include a copy of the
|
||||
`m.room.redaction` event under `unsigned` as `redacted_because`
|
||||
when serving the redacted event to clients.
|
||||
|
||||
The exact algorithm to apply against an event is defined in the [room
|
||||
version specification](../index.html#room-versions).
|
||||
|
||||
The server should add the event causing the redaction to the `unsigned`
|
||||
property of the redacted event, under the `redacted_because` key. When a
|
||||
client receives a redaction event it should change the redacted event in
|
||||
the same way a server does.
|
||||
When a client receives an `m.room.redaction` event, it should change
|
||||
the affected event in the same way a server does.
|
||||
|
||||
{{% boxes/note %}}
|
||||
Redacted events can still affect the state of the room. When redacted,
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue