matrix-spec/content/rooms/v9.md

---
title: Room Version 9
type: docs
weight: 60
---

This room version builds on [version 8](/rooms/v8) to add additional redaction
rules that were unintentionally missed when incorporating v8.

## Client considerations

See [room version 8](/rooms/v8) for specific details regarding the addition of
restricted rooms.

Clients which implement the redaction algorithm locally should refer to the
[redactions](#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](https://github.com/matrix-org/matrix-doc/issues/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](#redactions).

## 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" %}}