--- title: Room Version 8 type: docs weight: 80 --- This room version builds on [version 7](/rooms/v7) to introduce a new join rule that allows members to join the room based on membership in another room. {{% boxes/warning %}} This room version is known to have issues relating to redactions of member join events. [Room version 9](/rooms/v9) should be preferred over v8 when creating rooms. {{% /boxes/warning %}} ## Client considerations Clients are encouraged to expose the option for the join rule in their user interface for supported room versions. The new join rule, `restricted`, is described in the [Client-Server API](/client-server-api/#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.join_rules` events now keep `allow` in addition to other keys in `content` when being redacted. {{% boxes/warning %}} [Room version 9](/rooms/v9) adds additional cases of protected properties for behaviour related to restricted rooms (the functionality introduced in v8). v9 is preferred over v8 when creating new rooms. {{% /boxes/warning %}} 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 key `membership`. - `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 adds a new join rule to allow members of a room to join another room without invite. Otherwise, the room version inherits all properties of [Room version 7](/rooms/v7). ### Authorization rules {{< added-in this=true >}} For checks performed upon `m.room.member` events, new points for handling `content.join_authorised_via_users_server` are added (Rule 4.2 and 4.3.5). {{< rver-fragment name="v8-auth-rules" withVersioning=true >}} ### Redactions [See above](#redactions). ## Unchanged from v7 The following sections have not been modified since v7, 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" %}} #### Deprecated event content schemas {{% rver-fragment name="v1-deprecated-formatting-off-spec" %}} {{% rver-fragment name="v1-stringy-power-levels" %}} ### 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" %}}