Skip to main content

Matrix 去中心化通信协议的主服务器

项目描述

Synapse 是由 Matrix.org 基金会编写和维护的开源Matrix主服务器。我们从 2014 年开始快速开发,2019 年达到 v1.0.0。Synapse 和 Matrix 协议本身的开发今天仍在继续。

简而言之,Matrix 是一种开放的互联网通信标准,支持联合、加密和 VoIP。Matrix.org对 Matrix 项目的目标有更多的说法,正式的规范描述了技术细节。

<nav class="contents" id="contents" role="doc-toc">

内容

</nav>

安装和配置

Synapse 文档描述了如何安装 Synapse。我们建议使用 来自 Matrix.org 的Docker 镜像或Debian 软件包。

Synapse 有多种配置选项 ,可用于在安装后自定义其行为。这里有关于如何为联合配置 Synapse 的其他详细信息。

在 Synapse 中使用反向代理

建议在 Synapse 前面放置一个反向代理,如 nginxApacheCaddyHAProxyrelayd。这样做的一个好处是,它意味着您可以将默认的 https 端口 (443) 暴露给 Matrix 客户端,而无需以 root 权限运行 Synapse。有关配置的信息,请参阅反向代理文档

升级现有 Synapse

升级 Synapse 的说明在升级说明中。请查看这些说明,因为某些版本的 Synapse 升级可能需要额外的步骤。

平台依赖

Synapse 使用许多平台依赖项,例如 Python 和 PostgreSQL,并旨在遵循受支持的上游版本。有关更多详细信息,请参阅 弃用政策

安全说明

Matrix 在某些 API 中提供用户提供的原始数据——特别是内容存储库端点

虽然我们做出了合理的努力来缓解 XSS 攻击(例如,通过使用CSP),但不应将 Matrix 主服务器托管在托管其他 Web 应用程序的域上。这尤其适用于与 Matrix Web 客户端和其他敏感应用程序(如 webmail)共享域。有关更多信息,请参阅 https://developer.github.com/changes/2014-04-25-user-content-security

理想情况下,主服务器不应简单地位于不同的子域上,而应位于完全不同的注册域上(也称为顶级站点或 eTLD+1)。这是因为只要两个应用程序共享同一个注册域,一些攻击仍然是可能的。

举个例子来说明这一点,如果您的 Element Web 或其他敏感的 Web 应用程序托管在A.example1.com上,那么您最好将 Synapse 托管在 example2.com上。托管在 B.example1.com上提供了一定程度的保护,因此在某些情况下这也是可以接受的。但是,您不应Synapse 托管在A.example1.com上。

请注意,以上所有内容仅指 Synapse 的 public_baseurl设置中使用的域。特别是,它与托管在该服务器上的 MXID 中提到的域无关。

遵循此建议可确保即使在 Synapse 中发现 XSS,对其他应用程序的影响也将降至最低。

测试新安装

试用新 Synapse 安装的最简单方法是从 Web 客户端连接到它。

除非您在本地计算机上运行 Synapse 的测试实例,否则通常需要启用 TLS 支持才能从客户端成功连接:请参阅 TLS 证书

一个简单的入门方法是分别在 https://app.element.io/#/loginhttps://app.element.io/#/register上通过 Element 登录或注册。您将需要更改您从matrix.org登录的服务器 ,而是指定https://<server_name>:8448的主服务器 URL(如果您使用反向代理,则 仅指定https://<server_name> )。如果您更喜欢使用其他客户端,请参阅我们的 客户端细分

如果一切顺利,您至少应该能够登录、创建房间并开始发送消息。

从客户端注册新用户

默认情况下,禁用通过 Matrix 客户端注册新用户。要启用它:

  1. 注册配置部分中,在homeserver.yaml中 设置enable_registration: true

  2. 然后要么

    1. 设置验证码,或

    2. homeserver.yaml中设置enable_registration_without_verification: true

我们强烈建议使用 CAPTCHA,尤其是当您的家庭服务器暴露在公共互联网上时。没有它,任何人都可以在您的家庭服务器上自由注册帐户。攻击者可以利用这一点来创建针对 Matrix 联盟其余部分的垃圾邮件机器人。

您的新用户名将部分来自server_name,部分来自您在创建帐户时指定的 localpart。您的姓名将采用以下形式:

@localpart:my.domain.name

(发音为“at localpart on my dot domain dot name”)。

与登录时一样,您需要指定“自定义服务器”。在“用户名”框中指定所需的本地部分。

故障排除和支持

管理员常见问题解答 包括处理一些常见问题的提示。有关更多详细信息,请参阅 Synapse 更广泛的文档

如需安装或管理 Synapse 的其他支持,请在社区支持室#synapse:matrix.org(如有必要,从 matrix.org 帐户)询问。我们不会将 GitHub 问题用于支持请求,仅用于错误报告和功能请求。

身份服务器

身份服务器负责将电子邮件地址和其他第 3 方 ID (3PID) 映射到 Matrix 用户 ID,并在创建该映射之前验证 3PID 的所有权。

它们不是存储帐户或凭据的位置 - 它们位于家庭服务器上。身份服务器仅用于将第 3 方 ID 映射到矩阵 ID。

此过程对安全性非常敏感,因为如果太容易注册 Matrix 帐户或收集 3PID 数据,则存在明显的垃圾邮件风险。从长远来看,我们希望创建一个去中心化的系统来管理它(matrix-doc #712),但与此同时,在 Matrix 生态系统中管理可信身份的角色被外包给了一组已知的可信生态系统合作伙伴,运行诸如Sydent之类的“Matrix Identity Servers”的人,其作用纯粹是验证和跟踪 3PID 登录并发布最终用户公钥。

您可以托管自己的 Sydent 副本,但这会阻止您通过 Matrix 生态系统中的其他用户的电子邮件地址联系他们,并阻止他们找到您。因此,我们建议您暂时使用https://matrix.orghttps://vector.im上的集中式身份服务器之一。

重申一下:只有当您选择将电子邮件地址与您的帐户相关联,或通过其他用户的电子邮件地址向其他用户发送邀请时,才会使用身份服务器。

发展

我们欢迎社区对 Synapse 的贡献!最好的起点是我们 的贡献者指南。这是我们较大文档的一部分,其中包括

Synapse 开发人员和 Synapse 管理员的信息。开发人员可能对以下内容特别感兴趣:

除此之外,加入我们在 Matrix 上的开发者社区: #synapse-dev:matrix.org,以真人为特色!