2.1规格变更建议

要建议更改Matrix规范，请参阅“ 矩阵规格变更建议”中的说明。

3.1用户

每个客户端都与一个用户帐户相关联，该帐户在Matrix中使用唯一的“用户ID”进行标识。此ID被命名为分配帐户的主服务器，其格式为：

@localpart：域

有关用户ID结构的完整详细信息，请参阅附录“Identifier Grammar”。

3.2设备

Matrix规范对术语“设备”具有特定含义。作为用户，我可能有多种设备：桌面客户端，一些网络浏览器，Android设备，iPhone等。它们广泛涉及物理世界中的真实设备，但您可能在物理设备上有多个浏览器，或移动设备上的几个Matrix客户端应用程序，每个应用程序都是自己的设备。

设备主要用于管理用于端到端加密的密钥（每个设备都有自己的解密密钥副本），但它们也可以帮助用户管理访问 - 例如，通过撤销对特定设备的访问。

当用户首次使用客户端时，它会将自己注册为新设备。设备的使用寿命可能取决于客户端的类型。Web客户端可能会在注销时丢弃其所有状态，并在每次登录时创建新设备，以确保加密密钥不会泄漏给新用户。在移动客户端中，如果用户是相同的，则在登录会话到期时重新使用该设备可能是可接受的。

设备由device_id标识，device_id在给定用户的范围内是唯一的。

用户可以将人类可读的显示名称分配给设备，以帮助他们管理他们的设备。

3.3事件

通过Matrix交换的所有数据都表示为“事件”。通常，每个客户端动作（例如，发送消息）恰好与一个事件相关。每个事件都有一个类型，用于区分不同类型的数据。 在Java的包命名约定之后，类型值必须是唯一的全局命名空间，例如 com.example.myapp.event。特殊的顶级命名空间m。保留用于Matrix规范中定义的事件 - 例如，m.room.message 是即时消息的事件类型。事件通常在“房间”的背景下发送。

3.4事件图

在房间的上下文中交换的事件存储在称为“事件图”的有向无环图（DAG）中。该图的部分排序给出了房间内事件的时间顺序。图中的每个事件都有一个零个或多个“父”事件的列表，这些事件指的是从创建事件的主服务器的角度来看没有按时间顺序排列的任何先前事件。

通常情况下，事件具有单个父项：房间中发送时的最新消息。但是，家庭服务者在发送消息时可能合法地相互竞争，导致单个事件具有多个后继者。因此，添加到图表中的下一个事件将具有多个父项。每个事件图都有一个没有父项的根事件。

为了订购和简化图表中事件之间的时间顺序比较，主服务器在每个事件上维护深度元数据字段。事件的 深度是一个正整数，严格地大于其任何父母的深度。根事件的深度应为1.因此，如果一个事件在另一个事件之前，那么它必须具有严格更小的深度。

3.5房间结构

房间是用户可以发送和接收事件的概念性场所。事件被发送到房间，并且该房间中具有足够访问权限的所有参与者将接收该事件。客房通过“客房ID”在内部进行唯一标识，其形式如下：

！opaque_id：域

每间客房仅有一间客房。虽然房间ID确实包含域名，但它仅用于全局命名空间房间ID。房间不在指定的域中。

有关房间ID结构的完整详细信息，请参阅附录中的“标识符语法”。

以下概念图显示了发送到房间的 m.room.message事件！qporfwt：matrix.org：

 {@alice：matrix.org} {@bob：domain.com}
         | ^
         | |
[HTTP POST] [HTTP GET]
房间ID：！qporfwt：matrix.org房间ID：！qporfwt：matrix.org
事件类型：m.room.message事件类型：m.room.message
内容：{JSON object}内容：{JSON object}
         | |
         V |
 + ------------------ + + ------------------ +
 | homeserver | | homeserver |
 | matrix.org | | domain.com |
 + ------------------ + + ------------------ +
         | ^
         | [HTTP PUT] |
         | 房间ID：！qporfwt：matrix.org |
         | 事件类型：m.room.message |
         | 内容：{JSON对象} |
         `------->指向前面的消息------`
                   来自matrix.org的PKI签名
                   事务层元数据
                   PKI授权标头

               ...................................
              | 共享数据|
              | 州：|
              | 房间ID：！qporfwt：matrix.org |
              | 服务器：matrix.org，domain.com |
              | 成员：|
              |  -  @alice：matrix.org |
              |  -  @bob：domain.com |
              | 消息：|
              |  -  @alice：matrix.org |
              | 内容：{JSON对象} |
              | ................................... |

联合维护多个主服务器之间的每个房间的共享数据结构。数据分为消息事件和状态事件。

消息事件：

这些描述了房间中的瞬时“一次性”活动，例如即时消息，VoIP呼叫建立，文件传输等。它们通常描述通信活动。

国家活动：

这些描述了对与房间相关的给定持久性信息（“状态”）的更新，例如房间的名称，主题，成员资格，参与服务器等。状态被建模为每个房间的键/值对的查找表，每个键都是state_key和事件类型的元组。每个状态事件都会更新给定键的值。

通过考虑图中给定事件之前和包括所有事件来计算给定点处的房间状态。在事件描述相同状态的情况下，应用合并冲突算法。状态解析算法是传递性的，不依赖于服务器状态，因为它必须始终选择相同的事件，而不管服务器或接收事件的顺序。事件由始发服务器签名（签名包括父关系，类型，深度和有效负载哈希）并通过联合推送到房间中的参与服务器，当前使用全网状拓扑。服务器还可以从参与房间的其他服务器请求通过联合回填事件。

#room_alias：域

     HTTP GET
#matrix：domain.com！aaabaa：matrix.org
        | ^
        | |
 _______ V ____________________ | ____
| domain.com |
| 映射：|
| #matrix >>！aaabaa：matrix.org |
| #golf >>！wfeiofh：sport.com |
| #bike >>！4rguxf：matrix.org |
| ________________________________ |

3.6身份

Matrix中的用户通过其Matrix用户ID进行标识。但是，也可以使用现有的第三方ID名称空间来识别Matrix用户。Matrix“Identity”描述了用户ID和链接到其帐户的第三方名称空间中的任何其他现有ID 。Matrix用户可以将第三方ID（3PID）（如电子邮件地址，社交网络帐户和电话号码）链接到其用户ID。链接3PID会创建从3PID到用户ID的映射。然后，Matrix用户可以使用此映射来发现其联系人的用户ID。为了确保从3PID到用户ID的映射是真实的，使用受信任的“身份服务器”（IS）的全局联合集群来验证3PID并持久化并复制映射。

为了使客户端应用程序成为Matrix生态系统的一部分，不需要使用IS。但是，如果没有一个客户端将无法使用3PID查找用户ID。

3.7配置文件

用户可以发布与其帐户相关联的任意键/值数据 - 例如人类可读的显示名称，个人资料照片URL，联系信息（电子邮件地址，电话号码，网站URL等）。

3.8私人用户数据

用户还可以在其帐户中存储任意私钥/值数据 - 例如客户端首选项或缺少任何其他专用API的服务器配置设置。API与管理Profile数据对称。