Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-12 09:03:43 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
matrix-spec/content/rooms/fragments/v9-redactions.md
Travis Ralston f14e18131b
Specify room version 10: knock_restricted and int power levels (#1099) 
* Clarification on historical power level handling

* Revert "Clarification on historical power level handling"

This reverts commit f443b3d5a9.

* Clean up

* Let us try this again not using VS Code

* Markdown is full of mysteries

* Move stringy power levels to room versions

* Describe range

* Fix minor issues with previous room version stuff

* Copy/paste v9 into v10

* Describe deprecated formatting

* Paste unmodified auth rules from v8 into v10

* Move 9.1 to 9.3, add 9.1 and 9.2 for integer enforcement

* Add knock_restricted to v10 auth

* Misc cleanup and clarification for fragments

* Describe `knock_restricted` client changes

* Changelogs

* spelling

* Apply suggestions from code review

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Apply code review suggestions manually

* Fix v9 redactions

* Fix auth rules clarity issues

* Apply suggestions from code review

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Remove false integer requirements

Co-authored-by: Neil Alexander <neilalexander@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
2022-06-08 15:22:47 -06:00

1.7 KiB
Raw Blame History

toc_hide
true

{{% added-in this=true %}} m.room.member 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 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:

  • event_id
  • type
  • room_id
  • sender
  • state_key
  • content
  • hashes
  • signatures
  • depth
  • prev_events
  • prev_state
  • auth_events
  • origin
  • origin_server_ts
  • membership

The content object must also be stripped of all keys, unless it is one of one of the following event types:

  • m.room.member allows keys membership, join_authorised_via_users_server.
  • m.room.create allows key creator.
  • m.room.join_rules allows keys join_rule, allow.
  • m.room.power_levels allows keys ban, events, events_default, kick, redact, state_default, users, users_default.
  • m.room.history_visibility allows key history_visibility.