43 lines
No EOL
2.4 KiB
Markdown
43 lines
No EOL
2.4 KiB
Markdown
### 房间升级
|
||
|
||
有时，由于各种原因，房间可能需要升级为不同的房间版本。本模块定义了一种在需要时将房间升级到不同房间版本的方法。
|
||
|
||
#### 事件
|
||
|
||
{{% 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` 中的较大者。
|
||
|
||
当用户加入新房间时，服务器应自动转移或复制用户的一些个性化设置，如通知、标签等。 |