房间版本 6

本房间版本基于 版本 5 进行构建，同时对事件执行的多项授权规则进行了变更。

客户端注意事项

本房间版本未引入任何新的客户端注意事项。实现本地化撤回算法的客户端，应参考下方 撤回 章节了解完整算法。

撤回

[New in this version] m.room.aliases 的所有重要意义已从撤回算法中移除。其余规则与以往房间版本保持一致。

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

• 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 键。
• m.room.create 事件类型允许保留 creator 键。
• m.room.join_rules 事件类型允许保留 join_rule 键。
• m.room.power_levels 事件类型允许保留以下键： ban、events、events_default、kick、redact、state_default、users、 users_default。
• m.room.history_visibility 事件类型允许保留 history_visibility 键。

服务器实现组件

房间版本 6 对 房间版本 5 中描述的算法进行了如下更改。

撤回

见上。

事件格式

[New in this version] 通过强制执行 规范化 JSON，本房间版本降低了 depth 限制。

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

{
  "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
  }
}

授权规则

[New in this version] 与 m.room.aliases 类型事件相关的规则 4 被移除。m.room.aliases 事件仍需通过与状态事件相关的授权检查。

[New in this version] 此外，m.room.power_levels 类型事件的授权规则现在在 content 下包含了 notifications 属性。这对规则 10.4 和 10.5（现为 9.4 和 9.5）进行了更新，以同时检查 events 属性。

事件必须由 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. 若 membership 为 join：
      1. 若仅有的前序事件为 m.room.create 且 state_key 等于 creator，则允许。
      2. 若 sender 不等于 state_key，则拒绝。
      3. 若 sender 已被封禁，则拒绝。
      4. 若 join_rule 为 invite，则当 membership 状态为 invite 或 join 时允许。
      5. 若 join_rule 为 public，允许。
      6. 否则，拒绝。
   3. 若 membership 为 invite：
      1. 若 content 包含 third_party_invite 属性：
         1. 若目标用户被封禁，则拒绝。
         2. 若 content.third_party_invite 不含 signed 属性，则拒绝。
         3. 若 signed 不含 mxid 和 token 属性，则拒绝。
         4. 若 mxid 不等于 state_key，则拒绝。
         5. 若当前房间状态中对应 token 的 state_key 无 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 当前的 membership 状态不是 join，则拒绝。
      3. 若目标用户当前的 membership 状态是 join 或 ban，则拒绝。
      4. 若 sender 权限等级大于或等于邀请权限，则允许。
      5. 否则，拒绝。
   4. 若 membership 为 leave：
      1. 若 sender 与 state_key 相同，仅当该用户当前 membership 状态为 invite 或 join 时允许。
      2. 若 sender 当前的 membership 状态不是 join，则拒绝。
      3. 若目标用户当前 membership 状态为 ban，且 sender 权限等级低于封禁权限，则拒绝。
      4. 若 sender 权限等级大于或等于踢人权限，且目标用户权限等级低于 sender，允许。
      5. 否则，拒绝。
   5. 若 membership 为 ban：
      1. 若 sender 当前的 membership 状态不是 join，则拒绝。
      2. 若 sender 权限等级大于或等于封禁权限，且目标用户权限等级低于 sender，允许。
      3. 否则，拒绝。
   6. 否则，成员状态未知。拒绝。
5. 若 sender 当前的 membership 状态不是 join，则拒绝。
6. 若事件类型为 m.room.third_party_invite：
   1. 仅当 sender 当前权限等级大于或等于邀请权限时允许。
7. 若事件类型所需的权限等级高于 sender 当前权限等级，则拒绝。
8. 若事件的 state_key 以 @ 开头且与 sender 不一致，则拒绝。
9. 若事件类型为 m.room.power_levels：
   1. 若 content 中的 users 属性不是以有效用户 ID 为键且值为整数（或整数字符串）的对象，则拒绝。
   2. 若房间中不存在先前的 m.room.power_levels 事件，则允许。
   3. 对于 users_default、events_default、state_default、ban、redact、kick、invite 属性，检查是否有新增、变更或移除。对每项变更：
      1. 若当前值高于 sender 当前权限等级，则拒绝。
      2. 若新值高于 sender 当前权限等级，则拒绝。
   4. [Changed in this version] 针对 events 或 notifications 属性中被变更或移除的每一项：
      1. 若当前值大于 sender 当前权限等级，则拒绝。
   5. [Changed in this version] 针对 events 或 notifications 属性中新增加或变更的每一项：
      1. 若新值大于 sender 当前权限等级，则拒绝。
   6. 针对 users 属性中被变更或移除的每一项，除 sender 自身以外：
      1. 若当前值大于等于 sender 当前权限等级，则拒绝。
   7. 针对 users 属性中新增加或变更的每一项：
      1. 若新值大于 sender 当前权限等级，则拒绝。
   8. 否则，允许。
10. 否则，允许。

规范化 JSON

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

与 v5 保持一致

以下章节自 v5 起未被修改，仅为保持完整性而收录。

处理撤回

在房间版本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。

已废弃的事件内容模式

发送到此版本房间中的事件，其格式可能与其常规模式不同。此类情况将在此处进行说明。

m.room.power_levels 事件支持以字符串形式传递数值

为了与早期实现保持向后兼容， m.room.power_levels 事件中的每个整数值属性 都可以被编码为字符串而非整数。这包括 events、notifications 和 users 属性中的嵌套值。例如，以下是在此房间版本中有效的 m.room.power_levels 事件：

{
  "content": {
    "ban": "50",
    "events": {
      "m.room.power_levels": "100"
    },
    "events_default": "0",
    "state_default": "50",
    "users": {
      "@example:localhost": "100"
    },
    "users_default": "0"
  },
  "origin_server_ts": 1432735824653,
  "room_id": "!jEsUZKDJdhlrceRyVU:example.org",
  "sender": "@example:example.org",
  "state_key": "",
  "type": "m.room.power_levels"
}

当该值表示整数时，必须符合以下格式：

• 仅包含一个十进制整数，不允许浮点数或小数点，可以带任意数量的前导零（如 "100"、"000100"）；
• 可选地在整数前面加一个 - 或 + 字符（如 "+100"、"-100"）；
• 可选地在前后添加任意数量的空白字符（如 " 100 "、" 00100 "、" +100 "、" -100 "）。

状态解析

事件 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）故意不参与迭代鉴权检查，因为检查过程中不会对鉴权事件重新授权（但非鉴权事件则会被检查）。

签名密钥有效期

在验证事件签名时，服务器必须强制要求密钥请求中的 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 天中的较小值。这是为了避免攻击者发布一个在较长时间内有效而无法被主服务器所有者撤销的密钥的情况。