每一片树叶都是不同的，但它们又有相同之处。
记忆的表示实际上并不完全与感知结果相同。
      
      ___心理学家

1 写在前面

很多协议和思想都发端于数学和逻辑概念，比如解析表达式 与数学运算表达式逻辑，其背后的逻辑是相同的。

现在一些较新的协议也是如此，比如matrix，chatgpt，它可以说与线性代数的矩阵运算如出一辙，我们在此做一些基本了解，并试着解读其背后的原理。

图灵实验室有矩阵协议，法国有深度学习 图灵奖，美国有巨型企业，我们在跟随和努努力使用它们。

2 基本介绍

矩阵标准是剑桥大学图灵实验室发布的一个开放标准，用于通过 IP进行可互操作、分散的实时通信。
其社区大约成立于2017年，它有以下特征:

1 它是可互操作的，这意味着它旨在与其他通信系统进行互操作，并且作为一个开放标准意味着很容易看出如何与它进行互操作.
2 是去中心化的，这意味着没有中心点- 任何人都可以托管自己的服务器并控制自己的数据.
3 它被设计为实时运行，这意味着它非常适合构建需要立即交换数据的系统，例如即时消息通信.

3 现有协议的服务实现与其安全性

已经实现的服务包括 py synapse和go版本的 dendrite，感兴趣的可以自行搜索。这里介绍一些可能的安全问题。 已经成熟的应用提供商包括 discord 在开源社区有广泛的应用，现在的开源社区与商业服务越来紧密的联系，表明单独个人支撑开源产品已经不太可能，成功的开源产品其背后必然有商业支撑否则很难长久。

3.0 服务的安全性：端到端加密的流程

每个用户连接到一个服务器，这是他们的自有服务或家庭服务（其中的概念）。用户能够参与在任何 矩阵服务器上创建的聊天室（房间），因为每个服务器都与其他服务器连通。

这意味着您可以与任何服务器上的任何人交谈。这也意味着您可以托管自己的服务器，让您可以控制所有数据。

自托管还使您能够自定义服务器以满足您的需求，包括使您能够桥接到其他聊天网络（例如 IRC、XMPP、Discord、Telegram 等）或托管机器人。

在房间中发送的每条消息都会同步到参与该房间的所有其他服务器。如果一台服务器掉线，房间里的其他人都可以继续交谈。一旦该服务器重新联机，它将发送它在停机时错过的所有消息。

3.0.1 关于端到端加密流程

端到端加密默认使用 Ed25519指纹密钥对。

Ed25519 是一种用于对消息进行签名的公钥加密系统。在矩阵 中，每个设备都有一个 Ed25519 密钥对，用于识别该设备。密钥对的私有部分不离开设备，但公共部分会发布到矩阵网络。

• 首先：当设备首次启动时，此加密过程只会发生一次。

它必须创建 Ed25519 指纹密钥对和 Curve25519 身份密钥对。这是通过调用 olm_create_accountlibolm 来完成的。通过调用 检索（base64 编码的）密钥 olm_account_identity_keys。应保存该帐户以备将来使用。

• 然后它应该将这些密钥发布到家庭服务器，这是通过使用接口 /keys/upload 端点的device_keys属性来 完成的。

为了按照签名 JSONdevice_keys中的描述对有效负载进行签名，客户端应该调用.olm_account_sig

客户端应该跟踪家庭服务器为它存储了多少一次性密钥，如果有必要，生成并上传更多密钥。

这可以通过检查响应的device_one_time_keys_count 属性来实现。

/sync/libolm 支持的最大活动键数由  olm_account_max_number_of_one_time_keys 返回。

客户端应该尽量在主服务器上保持这个数量的一半左右。

过程中：要刷新或生成新的一次性密钥：

调用olm_account_generate_one_time_keys以生成新密钥。

调用olm_account_one_time_keys以检索未发布的密钥。这将返回一个具有单个属性的 JSON 格式的对象 curve25519。

它本身是一个将键 ID 映射到 base64 编码的 Curve25519 键的对象。例如：

  {
    "curve25519": {
      "AAAAAA": "wo76WcYtb0Vk/pBOdmduiGJ0wIEjW4IBMbbQn7aSnTo",
      "AAAAAB": "LRvjo46L1X2vx69sS9QNFD29HWulxrmW11Up5AfAjgU"
    }
  }

每个密钥都应以与之前的身份密钥有效负载相同的方式进行签名，并使用/keys/upload 端点的one_time_keys属性进行 上传。

调用olm_account_mark_keys_as_published以告知 olm 库不要从以后的调用中返回相同的键 olm_account_one_time_keys

配置房间以使用加密

要在房间中启用加密，
客户端应发送 typem.room.encryption和 content 的状态事件
{ "algorithm": "m.megolm.v1.aes-sha2" }。

通知密钥事件： 在聊天室内 隐式地 通过 m.room.encryption 状态事件，通知密钥事件。

• 最后：密钥共享

当由于丢失密钥而无法解密事件时，客户端可能希望从可能拥有它们的其他客户端请求它们。

类似地，如果客户端可以断言允许请求的设备查看使用该密钥加密的消息，则客户端可能希望使用关联的密钥来回复密钥请求。

3.0.2 交叉验证: 解决 端到端加密可能的安全问题

破坏 矩阵中加密的最有可能的方法之一是获得对目标帐户的访问权并添加代理设备以获取他们的对话。

为了解决这个问题，而提出 交叉验证功能。

用户在登录时验证自己的设备，确认他们是合法所有者。因此验证他们的每个人都自动信任新登录。

这使我们能够自动警告用户他们账号上的意外登录。

同时提供一种 两因素身份验证的形式以完成登录。 假设用户需要以某种方式为新登录提供担保。

加密密钥备份到服务器，验证自己的行为（通过验证现有设备或输入恢复密码/密钥）将神奇地使您的加密历史记录在您的新登录时可用。

只需进行一次验证即可永远信任其他用户以及他们当前和未来的所有设备（除非他们撤销） - 查看一次成功验证后出现的所有绿色复选框

3.0.3 端端加密其密钥有三种

密钥分类

A master key
    主密钥

a self-signing key
	自签名密钥

a user-signing key
	用户签名密钥

重设这三个key 将导致 需要再次验证 此处的登录。

对应的盾牌

黑色
	所有设备 都已验证过的
灰色
           某些未验证
红色
	账号在 一个新设备中登录了，还没有验证

3.1 通讯时的 连接保持方式

矩阵协议在基线 impl 中所做的长轮询只是一个长期存在的 HTTP 请求，它会阻塞直到服务器有东西要发送。Radio-wise 这在概念上与 XMPP TCP 连接相同。

唯一的区别是（在基线 impl 中）您在收到每个响应后启动一个新的 HTTP 请求——它会咀嚼一些与 XMPP 相关的额外数据。不过，接收者已经从接收之前的数据中启动，因此它不应该对连接消耗产生重大影响。

此外，矩阵对长期存在的请求（通常为 30-60 秒）设置了超时，以帮助在请求或连接中断的情况下恢复 - 从理论上讲，这可能会增加连接的成本和消耗，但实际上几乎是全部长链接用例都符合接收事件比超时更频繁，因此超时实际上对成本没有太大例外的影响。

也就是说，使用替代的方案可以有更大改进空间；比如使用开销较小的传输；使用更有效的编码等。

3.1.1 TCP连接管理

一旦TCP连接中的两个设备都完成了连接设置并进入ESTABLISHED状态。则TCP软件处于正常运行模式。

使用消息格式化和数据传输 部分中描述的机制将数据打包成段并进行传输。滑动窗口方案将用于控制分段大小并根据需要提供流量控制，拥塞处理和重传。

一旦处于这样的模式，两个设备都可以无限期保持在那里。

一些TCP连接确实可以长期存在，事实上，一些用户一次保持某些连接，如Telnet会话数小时或几天
有两个情况导致连接移除ESTABLISHED状态

    连接终止：任一设备决定终止连接，这涉及特定过程
    连接中断：发生某种问题导致连接中断。

3.1.2 发送数据

使用传输控制协议的两个设备如何建立TCP连接，以及如何管理和终止连接。

虽然这是TCP工作方式的关键部分，但它们实际上是实现协议最终目的的一个手段：发数据、TCP采用滑动窗口机制，特殊的段格式和多种功能，能够通过连接打包和发送数据，从而使程序进行通信。

TCP消息格式化和数据在设备之间传输的实际机制。

首先看一下重要的TCP格式，它描述了每个TCP消息中的字段以及它们是如何使用的， 提供了用于计算TCP（以及UDP消息）校验和的方法的描述，以及使用特殊“伪标头”的原因。

我讨论了最大段大小MSS参数及其意义。然后我将确切讨论如何使用滑动窗口机制去传输和确认数据。最后，我描述了两个特殊的数据传输功能：立即数据传输的“推送”和优先数据传输的“紧急”功能。

3.1.3 基础和一般操作

处理数据，介绍流，段和序列概念，然后描述TCP滑动窗口，用于确认，可靠性和数据流控制。讨论TCP如何使用端口，以及如何识别连接。使用TCP的最重要应用程序以及它们用于服务器应用程序的端口。

TCP 复制的使用，数据处理：流，段，序列号:

在OSI参考模型的上层发现的大多数协议操作中的“给定”之一是它们以消息的使用作为导向。这些消息类似信封中的书面信件，其中包含特定信息。

它们从较高向下传递到较低层，在那里它们被封装在较低层标头，然后进一步向下传递，直到它们实际在物理层发送出去。
    
应用程序向其传递通常相当短的数据块，该块被打包成一个UDP消息，然后发送到IP

IP将消息打包成IP数据块，并最终将其传递给第二层协议，如以太网，

这第二层被放入一个帧并发送到第一层进行传输。

而矩阵使用的方式就是如此，基于IP转发的TCP流，根据不同的主服务器提供的不同特征值。

3.1.4 矩阵中的流分发和复制

启动主服务后，配置不变，只需要开启如下 流复制端口

        listeners:

       # The TCP replication port
      - port: 29000                 # 流复制 tcp通道
           bind_address: '127.0.0.1'
           type: replication

       # The HTTP replication port
        - port: 29001             # 用于 与 各 worker工作进程 本地通信交流 同步数据
              bind_address: '127.0.0.1'
              type: http
              resources:
                   - names: [replication]

设置 worker 进程 业务配置  ， 需要 把复制流 对接 到哪一个主进程

          server_name: mainService         # 与主进程的 一致
          report_stats: False                # 与主进程的 一致
          worker_replication_host: 127.0.0.1          # 复制的数据 与 哪个主机 通信交流，与主进程的所在的ip 一致
          worker_replication_port: 29000             # 主进程 tcp 复制端口，如果使用 redis 转发，忽略此项
          worker_replication_http_port: 219001        # 转发到 主进程 http 复制端口   
          # 工作者 监听端口         
          worker_listeners:
              - type: http
                port: 29100
                bind_addresses: ['::1', '127.0.0.1']
                resources:
                   - names:
                      - client

4 结语：

相关资源在 github 感兴趣的可以跟随本文前言提供的资料搜索。
下一节，我们将试着分析矩阵的交叉验证过程。 提取其逻辑。