### 房间升级

有时，由于各种原因，房间可能需要升级为不同的房间版本。本模块定义了一种在需要时将房间升级到不同房间版本的方法。

#### 事件

{{% event event="m.room.tombstone" %}}

#### 客户端行为

能够识别 `m.room.tombstone` 事件及 `m.room.create` 事件中的 `predecessor` 字段的客户端，应向用户传达房间已升级的信息。一种实现方式是将旧房间从用户的房间列表中隐藏，并显示横幅，在新旧房间间提供相互链接——确保在引用旧房间时永久链接仍能正常工作。另一种做法是虚拟合并房间，使旧房间的时间线能够无缝延续到新房间的时间线，用户无需在房间间切换即可继续体验。

{{% http-api spec="client-server" api="room_upgrades" %}}

#### 服务器行为

当客户端请求将已知房间升级为已知版本时，服务器应：

1. 检查用户有权限在房间中发送 `m.room.tombstone` 事件。

2. {{% changed-in v="1.4" %}} 创建一个替代房间，并在新房间中发送包含 `predecessor` 字段、相应 `room_version` 以及从前置房间复制的 `type` 字段的 `m.room.create` 事件。如果前一个房间未设置 `type`，则新房间的创建事件同样不指定 `type`。

3. 将可转移的状态事件复制到新房间。具体转移哪些内容留给实现方决定，不过推荐转移的状态事件包括：

    - `m.room.server_acl`
    - `m.room.encryption`
    - `m.room.name`
    - `m.room.avatar`
    - `m.room.topic`
    - `m.room.guest_access`
    - `m.room.history_visibility`
    - `m.room.join_rules`
    - `m.room.power_levels`

    会员事件不应用于转移到新房间，这是因为服务器在技术上无法冒充来自其他主服务器的用户。此外，服务器也不应转移对发送者有敏感要求的状态事件，例如 Matrix 命名空间之外的事件，客户端可能要求这些事件的发送者满足特定条件。

4. 将所有本地别名迁移到新房间。

5. 向旧房间发送 `m.room.tombstone` 事件，以指示该房间不再建议继续使用。

6. 如有可能，还应修改旧房间的权限级别（power levels），以阻止发送事件和邀请新用户。例如，将 `events_default` 和 `invite` 设置为 `50` 与 `users_default + 1` 中的较大者。

当用户加入新房间时，服务器应自动转移或复制用户的一些个性化设置，如通知、标签等。