房间版本 10

该房间版本基于版本 9，强制要求权限等级（power level）值为整数，并引入了新的 knock_restricted 加入规则，使潜在成员更容易加入此类房间。

客户端注意事项

此房间版本增加了新的 knock_restricted 加入规则，允许房间的潜在成员通过敲门（在房间版本 7中引入）或“加入限制”（在房间版本 8中引入并在房间版本 9中细化）两种方式加入房间。

客户端应针对具备该规则的房间做出相应渲染。例如：

该房间为：
[ ] 公开
[x] 私有

加入规则（公开时禁用）：
[x] 允许 `#space:example.org` 的成员加入
[x] 允许敲门

本地实现事件修订（redaction）算法的客户端，应参考下文的修订章节以获得完整概览。

服务器实现要素

房间版本 7 增加了“敲门”，房间版本 8 增加了“加入限制”（并被 房间版本 9 进一步细化）——两者都为潜在成员提供了加入方式，但过去无法将两种机制结合使用。该房间版本引入了一种新的 knock_restricted 加入规则，混合了两种行为，允许用户只要满足 restricted 或 knock 加入规则之一即可加入房间。

此外，该房间版本还要求权限等级事件中的数值必须为整数类型，而不能是其它房间版本为兼容性允许的字符串表示形式。

房间版本 10 基于房间版本 9，具体变化如下所述。

事件格式

该房间版本未对事件格式进行修改。详见下文当前事件格式的详细信息。

已弃用事件内容模式

虽然本房间版本未专门改变事件格式，但某些已弃用行为被严格禁止支持。

m.room.power_levels 事件的值必须为整数

在其它房间版本中，例如 v9，权限等级可以为兼容性目的用字符串表示。

本房间版本移除了此项兼容——权限等级在本版本中不得用字符串表示。结构不正确的权限等级将按照下述授权规则被拒绝。

授权规则

事件必须由 sender 属性所标记的服务器签名。

影响授权的状态事件类型有：

• m.room.create
• m.room.member
• m.room.join_rules
• m.room.power_levels
• m.room.third_party_invite

规则如下：

1. 若类型为 m.room.create：
   1. 若存在任何 prev_events，则拒绝。
   2. 若 room_id 的域名与 sender 的域名不符，则拒绝。
   3. 若 content.room_version 存在且不是已识别的版本，则拒绝。
   4. 若 content 没有 creator 属性，则拒绝。
   5. 否则，允许。
2. 针对事件的 auth_events：
   1. 若对某一 type 和 state_key 对有重复条目，则拒绝。
   2. 若存在其 type 和 state_key 不符合授权事件选择算法的条目，则拒绝。
   3. 若存在在接收 PDU 时的检查中已被拒绝的条目，则拒绝。
   4. 若未包含一个 m.room.create 事件，则拒绝。
3. 若房间状态中的 m.room.create 事件的 content.m.federate 属性被设为 false，且该事件的 sender 域名与创建事件的 sender 域名不符，则拒绝。
4. 若类型为 m.room.member：
   1. 若没有 state_key 属性，或 content 中没有 membership 属性，则拒绝。
   2. 若 content 有 join_authorised_via_users_server 键：
      1. 若事件未由该键指向的用户的 homeserver 有效签名，则拒绝。
   3. 若 membership 为 join：
      1. 如果唯一的先前事件为 m.room.create 且 state_key 为创建者，则允许。
      2. 若 sender 不等于 state_key，则拒绝。
      3. 若 sender 被封禁，则拒绝。
      4. 若 join_rule 为 invite 或 knock，且成员状态为 invite 或 join，则允许。
      5. [Changed in this version] 若 join_rule 为 restricted 或 knock_restricted：
         1. 若成员状态为 join 或 invite，则允许。
         2. 若 content 中的 join_authorised_via_users_server 不是有足够权限邀请其它用户的用户，则拒绝。
         3. 否则，允许。
      6. 若 join_rule 为 public，则允许。
      7. 否则，拒绝。
   4. 若 membership 为 invite：
      1. 若 content 中有 third_party_invite 属性：
         1. 若目标用户已被封禁，则拒绝。
         2. 若 content.third_party_invite 没有 signed 属性，则拒绝。
         3. 若 signed 没有 mxid 和 token 属性，则拒绝。
         4. 若 mxid 不等于 state_key，则拒绝。
         5. 若当前房间状态下没有 state_key 等于 token 的 m.room.third_party_invite 事件，则拒绝。
         6. 若 sender 不等于 m.room.third_party_invite 的 sender，则拒绝。
         7. 若 signed 中的任何签名与 m.room.third_party_invite 事件中的任何公钥匹配，则允许。公钥包含于 m.room.third_party_invite 的 content 中：
            1. 属性 public_key 的单个公钥。
            2. 属性 public_keys 的公钥列表。
         8. 否则，拒绝。
      2. 若 sender 当前成员状态不是 join，则拒绝。
      3. 若目标用户当前状态为 join 或 ban，则拒绝。
      4. 若 sender 权限等级大于等于邀请等级，允许。
      5. 否则，拒绝。
   5. 若 membership 为 leave：
      1. 若 sender 匹配 state_key，则仅当用户当前状态为 invite、join 或 knock 时允许。
      2. 若 sender 的当前成员状态不是 join，则拒绝。
      3. 若目标用户当前成员状态为 ban 且 sender 权限等级低于封禁等级，则拒绝。
      4. 若 sender 权限等级大于等于踢人等级且目标用户权限等级小于 sender，则允许。
      5. 否则，拒绝。
   6. 若 membership 为 ban：
      1. 若 sender 当前成员状态不是 join，则拒绝。
      2. 若 sender 权限等级大于等于封禁等级且目标用户权限等级小于 sender，则允许。
      3. 否则，拒绝。
   7. 若 membership 为 knock：
      1. [Changed in this version] 若 join_rule 非 knock 或 knock_restricted，则拒绝。
      2. 若 sender 不等于 state_key，则拒绝。
      3. 若 sender 当前成员状态不是 ban、invite 或 join，则允许。
      4. 否则，拒绝。
   8. 否则，成员状态未知，拒绝。
5. 若 sender 当前成员状态不是 join，则拒绝。
6. 若类型为 m.room.third_party_invite：
   1. 仅当 sender 权限等级大于等于邀请等级时允许。
7. 若该事件类型所需权限等级大于 sender 权限等级，则拒绝。
8. 若事件的 state_key 以 @ 开头且与 sender 不一致，则拒绝。
9. 若类型为 m.room.power_levels：
   1. [New in this version] 若 content 中 users_default、events_default、state_default、ban、redact、kick 或 invite 属性存在且类型不是整数，则拒绝。
   2. [New in this version] 若 content 中 events 或 notifications 属性存在，且不是值为整数的对象，则拒绝。
   3. 若 content 中的 users 属性不是 key 为有效用户ID、值为整数的对象，则拒绝。
   4. 若房间中没有先前的 m.room.power_levels 事件，则允许。
   5. 对 users_default、events_default、state_default、ban、redact、kick、invite 属性，检查它们是否被添加、更改或移除。对于每一个变化项：
      1. 若当前值大于 sender 的当前权限等级，则拒绝。
      2. 若新值大于 sender 当前权限等级，则拒绝。
   6. 对于变更或移除的 events 或 notifications 属性的每个条目：
      1. 若当前值大于 sender 当前权限等级，则拒绝。
   7. 对于新增或变更的 events 或 notifications 属性的每个条目：
      1. 若新值大于 sender 当前权限等级，则拒绝。
   8. 对于除 sender 自身外，变更或移除的 users 属性每个条目：
      1. 若当前值大于等于 sender 当前权限等级，则拒绝。
   9. 对于新增或变更的 users 属性每个条目：
      1. 若新值大于 sender 当前权限等级，则拒绝。
   10. 否则，允许。
10. 否则，允许。

与 v9 保持一致内容

以下章节自 v9 起未改动，为资料完整起见在此列出。

修订（Redactions）

收到编辑事件时，服务器必须移除所有不在以下列表中的键：

• event_id
• type
• room_id
• sender
• state_key
• content
• hashes
• signatures
• depth
• prev_events
• prev_state
• auth_events
• origin
• origin_server_ts
• membership

对于内容（content）对象，也必须移除其所有键，除非该事件类型属于以下之一：

• m.room.member 允许的键为 membership、join_authorised_via_users_server。
• m.room.create 允许的键为 creator。
• m.room.join_rules 允许的键为 join_rule、allow。
• m.room.power_levels 允许的键为 ban、events、events_default、kick、redact、state_default、users、users_default。
• m.room.history_visibility 允许的键为 history_visibility。

处理修订

在房间版本1和2中，清除操作（redactions）明确属于授权规则第11条。自房间版本3起，这些条件不再适用，如本版本的授权规则所示。

尽管清除操作始终被事件的授权规则接受，但只有在清除事件和被清除的事件都已被接收并且能够被验证后，才能将其发送给客户端。如果这两个事件都有效并已被服务器看到，那么在满足以下任一条件时，服务器会应用清除操作：

1. 清除事件的 sender 的权限等级大于或等于清除权限等级（redact level）。
2. 清除事件的 sender 的域名与原事件的 sender 的域名一致。

如果服务器将应用清除操作，则该清除事件也会被发送给客户端。否则，服务器只会等待有效的配对事件到来，届时可以重新检查上述条件。

事件ID

事件 ID 是事件的参考哈希，其采用一种变体的无填充 Base64 编码，将第 62 和第 63 个字符分别替换为 - 和 _，而不是使用 + 和 /。这与 RFC4648 URL 安全型 base64 的定义一致。

事件 ID 仍以前缀 $ 开头，最终可能类似于 $Rqnc-F-dvnEYJTyHq_iKxU2bZ1CI92-kuZq3a5lr5Zg。

事件格式

本版本中房间内的事件具有以下结构：

{
  "auth_events": [
    "$urlsafe_base64_encoded_eventid",
    "$a-different-event-id"
  ],
  "content": {
    "key": "value"
  },
  "depth": 12,
  "hashes": {
    "sha256": "thishashcoversallfieldsincasethisisredacted"
  },
  "origin_server_ts": 1404838188000,
  "prev_events": [
    "$urlsafe_base64_encoded_eventid",
    "$a-different-event-id"
  ],
  "redacts": "$some-old_event",
  "room_id": "!UcYsUzyxTGDxLBEvLy:example.org",
  "sender": "@alice:example.com",
  "signatures": {
    "example.com": {
      "ed25519:key_version": "these86bytesofbase64signaturecoveressentialfieldsincludinghashessocancheckredactedpdus"
    }
  },
  "type": "m.room.message",
  "unsigned": {
    "age": 4612
  }
}

状态解析

事件 E 之后的房间状态 S′(E) 由事件 E 之前的房间状态 S(E) 定义，并且依赖于 E 是状态事件还是消息事件：

• 如果 E 是一条消息事件，则 S′(E) = S(E)。
• 如果 E 是一条状态事件，则 S′(E) 与 S(E) 相同，除了其与 E 的 event_type 和 state_key 对应的项被 E 的 event_id 替换。

事件 E 之前的房间状态 S(E) 是 prev_event 集合 {E₁, E₂, …} 之后的状态集合 {S′(E₁), S′(E₂), …} 的 合并与决议结果。如何对一组状态进行合并与决议，见下述算法。

定义

版本 2 房间的状态合并算法使用如下定义，并以房间状态集 {S₁, S₂, …} 为输入：

权限事件（Power events）。
权限事件 指具有类型 m.room.power_levels 或 m.room.join_rules 的状态事件，或者类型为 m.room.member 且 membership 字段为 leave 或 ban，且 sender 与 state_key 不一致的状态事件。其核心思想为：权限事件是那些可能移除某人在房间内某项操作权限的事件。

无冲突状态映射与冲突状态集。
状态映射 S_i 的 key 为形如 (event_type, state_key) 的字符串二元组 K，对应的 value V 为一个状态事件。所有 S_i 的 (K, V) 键值对可划分为两个集合：如果给定 key K 在所有 S_i 出现，且值 V 在每个状态映射都一致，则此 (K, V) 属于 无冲突状态映射；否则，V 属于 冲突状态集。

注意，无冲突状态映射每个 key K 只会有一个事件，而冲突状态集可能因同 key 包含多个事件。

鉴权链（Auth chain）。
事件 E 的 鉴权链，是包含 E 的所有鉴权事件（auth events）、所有这些事件的鉴权事件，递归回溯直到房间创建为止的集合。换句话说，就是通过事件的 auth_events 链接遍历可达的所有事件。

鉴权差集（Auth difference）。
鉴权差集 的计算方式如下：首先对每个状态 S_i，计算其完全鉴权链，即该状态中每个事件的鉴权链的并集。然后找出那些未在所有鉴权链中都出现的事件。若 C_i 表示 S_i 的完全鉴权链，则鉴权差集为 ∪ C_i − ∩ C_i。

完整冲突集（Full conflicted set）。
完整冲突集 是冲突状态集与鉴权差集的并集。

逆拓扑权限排序（Reverse topological power ordering）。
一组事件的 逆拓扑权限排序，是按鉴权事件形成的有向无环图（DAG）进行拓扑排序，得到字典序最小的排序，并从最早事件到最晚事件排列。比较两个拓扑排序确定哪一个字典序更小时，事件的比较关系如下：对事件 x 和 y，若

1. x 的发送者的权限级别 高于 y 的发送者（以各自的 auth_event 查得）；或
2. 发送者权限级别相同，但 x 的 origin_server_ts 小于 y；或
3. 权限级别与 origin_server_ts 都相同，但 x 的 event_id 小于 y 的 event_id，

则 x < y。

逆拓扑权限排序可用 Kahn 算法进行拓扑排序，每步从候选顶点中按上述比较关系选择最小顶点。

主链排序（Mainline ordering）。
令 P = P₀ 为某个 m.room.power_levels 事件。从 i = 0 开始，反复获取 P_i+1，即 P_i 的 auth_events 中类型为 m.room.power_levels 的事件。每次自增 i，直到 P_i 的 auth_events 中没有 m.room.power_levels 事件为止。P₀ 的 主链 为 [P₀ , P₁, … , P_n]。

若另有事件 e = e₀（可以是另一个 m.room.power_levels 事件），可以构造类似事件链 [e₁, …, e_m]，其中 e_j+1 为 e_j 的 auth_events 中的 m.room.power_levels 事件，e_m 没有再指向任何 m.room.power_levels 事件。（注意 e₀ 本身不包含在该列表中，也有可能该列表为空，因为 e 可能没有引用过 m.room.power_levels 事件。）

对这两条列表进行如下比较：

• 查找最小的 j ≥ 1，使得 e_j 属于 P 的主链；
• 若存在这样的 j，则 e_j = P_i，且 i 唯一、i ≥ 0；否则令 i = ∞，其中 ∞ 为一个大于任何整数的特殊标记值；
• 无论哪种情况，e 的 主链位置 就是 i。

以 P 计算得主链位置后，基于 P 的主链排序，就是将一组事件按以下比较关系（从小到大）排序：对事件 x 和 y，若

1. x 的主链位置 大于 y（即 x 的鉴权链基于主链上的较早事件）；或
2. 主链位置相同，但 x 的 origin_server_ts 小于 y；或
3. 主链位置、origin_server_ts 都相同，但 x 的 event_id 小于 y，

则 x < y。

迭代鉴权检查（Iterative auth checks）。
迭代鉴权检查算法 的输入是初始房间状态和已排序的状态事件列表。它通过遍历事件列表，将符合授权规则的状态事件依次应用到房间状态上。若某状态事件未通过授权规则，则忽略该事件。如果验证授权规则时缺少某个必须的 (event_type, state_key) key，则用事件 auth_events 中相应的状态事件（若未被拒绝）替代。

算法

一组状态的 合并与决议 按如下步骤执行：

1. 选取出现在 完整冲突集 内的所有权限事件组成集合 X。对于每一个权限事件 P，将 P 的鉴权链中同时属于完整冲突集的事件也加入 X。对 X 按 逆拓扑权限排序 排序为列表。
2. 从 无冲突状态映射 作为起点，对上一步得到的事件列表应用迭代鉴权检查算法，得出部分已决议状态。
3. 将第 1 步未涉及的所有剩余事件按第 2 步已决议状态中的权限等级，用主链排序确定顺序。
4. 对上述部分已决议状态及新排序的事件列表，再次应用迭代鉴权检查算法。
5. 用无冲突状态映射中的相同 key 事件（若存在）替换当前结果中对应事件，得出最终合并决议状态。

被拒绝的事件

由于基于事件当前状态（而非鉴权链）验证授权而被拒绝的事件，除非另有特别说明，在算法中仍按常规方式处理。

注意，那些由于无法通过其鉴权链授权而被拒绝的事件不应出现在此流程中，因为他们不会出现在状态集合之内（本算法只使用状态集中的事件，或状态集中事件的鉴权链中的事件）。

被拒绝的鉴权事件（auth events）故意不参与迭代鉴权检查，因为检查过程中不会对鉴权事件重新授权（但非鉴权事件则会被检查）。

规范 JSON

服务器必须严格执行 附录 中规定的 JSON 格式。这意味着在大多数端点会返回 400 M_BAD_JSON 错误，或者在联邦通信中丢弃事件。例如，Federation API 的 /send 端点会丢弃该事件，而 Client Server API 的 /send/{eventType} 端点则会返回 M_BAD_JSON 错误。

签名密钥有效期

在验证事件签名时，服务器必须强制要求密钥请求中的 valid_until_ts 属性至少与所验证事件的 origin_server_ts 相同或更大。缺少签名密钥副本的服务器必须尝试通过 GET /_matrix/key/v2/server 或 POST /_matrix/key/v2/query API 获取密钥。当使用 /query 端点时，服务器必须设置 minimum_valid_until_ts 属性，以提示公证服务器在适当情况下尝试刷新密钥。

在确定密钥是否有效时，服务器必须采用 valid_until_ts 和当前时间起未来 7 天中的较小值。这是为了避免攻击者发布一个在较长时间内有效而无法被主服务器所有者撤销的密钥的情况。