matrix-spec/content/rooms/v9.md

title	type	weight
Room Version 9	docs	60

This room version builds on version 8 to add additional redaction rules that were unintentionally missed when incorporating v8.

Client considerations

See room version 8 for specific details regarding the addition of restricted rooms.

Clients which implement the redaction algorithm locally should refer to the redactions section below for a full overview.

Redactions

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

{{% rver-fragment name="v3-handling-redactions" %}}

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.

Server implementation components

{{% boxes/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. {{% /boxes/warning %}}

Room version 8 added a new restricted join rule to allow members of a room to join another room without invite. Room version 9 is based upon v8 with the following considerations.

Redactions

See above.

Unchanged from v8

The following sections have not been modified since v8, but are included for completeness.

Handling redactions

{{% rver-fragment name="v3-handling-redactions" %}}

Event IDs

{{% rver-fragment name="v4-event-ids" %}}

Event format

{{% rver-fragment name="v4-event-format" %}}

Authorization rules

{{% rver-fragment name="v8-auth-rules" %}}

State resolution

{{% rver-fragment name="v2-state-res" %}}

Canonical JSON

{{% rver-fragment name="v6-canonical-json" %}}

Signing key validity period

{{% rver-fragment name="v5-signing-requirements" %}}