房间版本 1

此房间版本是房间的第一个版本，包含了其他房间版本的构建基础。

客户端注意事项

本地实现删除算法的客户端应参考下方的删除部分。

删除

在接收到删除事件后，服务器必须移除除以下列表外的所有键：

• 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.aliases 允许键 aliases。
• m.room.history_visibility 允许 键 history_visibility。

服务器实现组成部分

此处定义的算法仅适用于版本 1 的房间。其他房间版本可能会采用其他算法，因此服务器在执行相关算法前应先确认所处理的是哪一版本的房间。

删除

见上文。

事件 ID

一个事件只能有一个事件ID。在此房间版本中，事件ID的格式为：

$opaque_id:domain

其中，domain 是创建该房间的主服务器的服务器名称，而 opaque_id 是在本地唯一的字符串。

domain 仅用于命名空间，以避免不同主服务器之间标识符发生冲突的风险。并不意味着相关房间或事件一定还在对应的主服务器上可用。

事件格式

版本 1 房间中的事件结构如下：

{
  "auth_events": [
    [
      "$af232176:example.org",
      {
        "sha256": "abase64encodedsha256hashshouldbe43byteslong"
      }
    ]
  ],
  "content": {
    "key": "value"
  },
  "depth": 12,
  "event_id": "$a4ecee13e2accdadf56c1025:example.com",
  "hashes": {
    "sha256": "thishashcoversallfieldsincasethisisredacted"
  },
  "origin_server_ts": 1404838188000,
  "prev_events": [
    [
      "$af232176:example.org",
      {
        "sha256": "abase64encodedsha256hashshouldbe43byteslong"
      }
    ]
  ],
  "room_id": "!UcYsUzyxTGDxLBEvLy:example.org",
  "sender": "@alice:example.com",
  "signatures": {
    "example.com": {
      "ed25519:key_version": "these86bytesofbase64signaturecoveressentialfieldsincludinghashessocancheckredactedpdus"
    }
  },
  "type": "m.room.message",
  "unsigned": {
    "age": 4612
  }
}

已弃用的事件内容 schema

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

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 "）。

授权规则

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

• 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.aliases：
   1. 若事件无 state_key，则拒绝。
   2. 若发送者域名与 state_key 不符，则拒绝。
   3. 否则，允许。
5. 若类型为 m.room.member：
   1. 若没有 state_key 属性，或 content 中无 membership 属性，则拒绝。
   2. 若 membership 为 join：
      1. 若唯一的前序事件为 m.room.create 且 state_key 为创建者，则允许。
      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. 若当前房间状态中无 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. 否则，拒绝。
   4. 若 membership 为 leave：
      1. 若 sender 与 state_key 匹配，则仅当其当前成员状态为 invite 或 join 时允许。
      2. 若 sender 当前成员状态不是 join，则拒绝。
      3. 若 目标用户 当前成员状态为 ban 且 sender 权限等级低于 封禁等级，则拒绝。
      4. 若 sender 权限等级大于等于 踢人等级，且 目标用户 权限等级小于 sender 权限等级，则允许。
      5. 否则，拒绝。
   5. 若 membership 为 ban：
      1. 若 sender 当前成员状态不是 join，则拒绝。
      2. 若 sender 权限等级大于等于 封禁等级，且 目标用户 权限等级低于 sender 权限等级，则允许。
      3. 否则，拒绝。
   6. 其他情况下，未知成员状态。拒绝。
6. 若 sender 当前成员状态不是 join，则拒绝。
7. 若类型为 m.room.third_party_invite：
   1. 仅当 sender 当前权限等级大于等于 邀请等级 时允许。
8. 若事件类型的 所需权限等级 大于 sender 权限等级，则拒绝。
9. 若事件的 state_key 以 @ 开头且与 sender 不符，则拒绝。
10. 若类型为 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. 针对 events 属性中被更改或移除的每一项：
       1. 若当前值大于 sender 当前权限等级，则拒绝。
    5. 针对 events 属性中被添加或更改的每一项：
       1. 若新值大于 sender 当前权限等级，则拒绝。
    6. 针对 users 属性（除 sender 本人）的被更改或移除的每一项：
       1. 若当前值大于等于 sender 当前权限等级，则拒绝。
    7. 针对 users 属性被添加或更改的每一项：
       1. 若新值大于 sender 当前权限等级，则拒绝。
    8. 否则，允许。
11. 若类型为 m.room.redaction：
    1. 若 sender 权限等级大于等于 撤回等级，则允许。
    2. 若被撤回事件的 event_id 域名与 m.room.redaction 的 event_id 域名一致，则允许。
    3. 否则，拒绝。
12. 否则，允许。

状态解析

事件 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)，等于 E 的所有 prev_events {E′, E″, …} 之后生成的状态集 {S′(E′), S′(E″), …} 的解析结果。

多状态的解析规则如下。最终解析出的状态通过多轮遍历构建；我们以 R 表示当前已解析的中间结果。

• 首先，将 R 设为所有需要解析的状态的并集，排除任何冲突事件。
• 第一步先解决 m.room.power_levels 相关事件的冲突。如果没有冲突，则跳过此步骤；否则：
  • 把要解析的状态中的所有 m.room.power_levels 事件收集成一个列表。
  • 按照 depth 升序、sha1(event_id) 降序排序。
  • 将列表中的第一个事件加入 R。
  • 对于列表后续每个事件，检查该事件是否被授权在状态 R 的房间中触发。如果允许，则用该事件更新 R，继续处理下一个事件；如不允许，则终止，跳过到下一步解决 m.room.join_rules 事件。
• 针对 m.room.join_rules 事件的冲突，重复上述过程。
• 针对 m.room.member 事件的冲突，也同样重复上述过程。
• 其余事件对授权规则没有影响，因此对于其它所有冲突，只需选择通过 R 中的身份验证、且拥有最大 depth 和最小 sha1(event_id) 的事件，将其加入 R。

冲突指的是两个状态针对同一 (event_type, state_key) 拥有不同 event_id。因此受影响的事件被称为冲突事件。

标准 JSON

出于附录中所述的原因，服务器不得强制严格遵循所规定的 JSON 格式。