Ansible 和 Matrix
构建桥梁 - Ansible 社区在聊天方面下一步需要走向何方
这篇文章很长，因为我有很多内容要涵盖。但我将从大局入手，如果您想了解详细信息，可以继续阅读。请注意，在此阶段，这代表着 *我的* 观点 - 正如我将在最后重复的那样，我的目标是让社区批准这一点，但首先我必须说服您 :)
世界在变化，我们也随之变化。我们的交流方式一直在发展，并且周期性地我们需要赶上潮流，如果我们想吸引新人加入我们的社区。如今，这意味着提供一个让新老贡献者感到受欢迎、安全和有价值的地方，拥有丰富的界面和较低的进入门槛。我想帮助构建它，因为我担心如果我们不这样做，我们将逐渐消失，而 Ansible 应该得到更好的待遇。
我将阐述如何利用 IRC 的坚实基础，成为一个以 Matrix 为先（但并非唯一，**IRC 将保留**）的社区，以及我希望从 Red Hat 方面如何推进事情。我知道这对某些人来说可能是一个热门话题，所以（a）请保持讨论文明，并且（b）我 *希望* 听到这些担忧，以便我们能够正确地处理此事。也就是说，“正确”必须是针对 *整个* 社区的。
未来愿景 - 我希望在未来 6 个月内实现的目标
我将在稍后详细介绍 Matrix 和 IRC 的具体内容，但让我先从GNOME 的 Thibault Martin 的这段引言开始
IRC 曾经是顶级系统一段时间，并且仍然非常可靠。这里和那里都存在一些问题，但鉴于整个协议的基础性，它相当稳固。曾经是其优势的协议的简朴性，在现代世界已成为其劣势。**人们的期望发生了变化**。我们的大部分贡献者社区在制作我们都喜欢的优秀软件时，就已经“为电脑工作”了。是时候让即时通讯让路了，并在我们彼此交谈时，让电脑为我们工作。无需 NickServ 拼写，无需 ChanServ 咒语，无需租用或在服务器上托管跳板。**是时候让我们只需输入我们的凭据，浏览频道，并与我们喜欢一起工作的人享受对话了。**
**我 *曾经* 是 IRC 的长期用户，*十年前* 它是正确的选择；现在不是了**，因此我同意 Thibault 的观点。为了让我们的社区发展壮大，我们必须吸引新的贡献者，他们会想要与我们交流。虽然 IRC 曾经是首选，但现在不再是了。然而，仅仅询问 *我们自己* 喜欢什么是不够的，那将是幸存者偏差。通过询问那些已经对 IRC 感到满意的人是否应该保留它，我们将忽略那些由于难以使用 IRC 而没有加入的人。我们想要考虑这些人 - 我们当然不知道他们是谁，所以我们必须凭直觉判断如何使他们的生活更轻松。这就是为什么我在过去一个月里一直在与 GNOME、KDE、Mozilla、Fedora 和 OpenDev 等社区讨论他们的计划和经验。
我知道你们中的许多人喜欢 IRC，而其他人则特别警惕 Matrix。我很快就会解决这个问题。但为了完善这一部分，我将告诉你 *我* 对社区在适度的时间内（3-6 个月）需要处于何种状态的看法。
- Matrix 成为新用户的默认选择
- 我们（社区）积极推广它，也就是说
- 我们鼓励使用其丰富性（表情符号反应、发布图片等）
- 我们将其添加到我们的文档中，作为与我们互动的方式
- 我们明确声明我们是一个以 Matrix 为先的社区
- 我们（Red Hat）通过付费托管 Element、成为优秀的 FOSS 公民并支持我们的供应链来做出贡献
- 这意味着 Matrix 房间可以获得类似
#welcome:ansible.com的地址 - 我们可能会向贡献者发放 Matrix 帐户（稍后详细介绍）
- 这意味着 Matrix 房间可以获得类似
- 我们（社区）积极推广它，也就是说
- IRC 得到维护
-
**IRC 不会消失！** 对其工作流程感到满意的用户不应被抛弃
- 对在 Matrix 中使其设置生效感兴趣的用户应该得到帮助
- 应在可能的情况下解决问题。我们可以使用许多调整选项来改善 IRC 端的体验，但我们需要记住，目标 *是* 使我们的聊天现代化，并且随之而来的是一些变化。
- 我们的目标是通过在合适的情况下发放 Ansible Matrix 帐户，逐步引导用户迁移到 Matrix
-
**IRC 不会消失！** 对其工作流程感到满意的用户不应被抛弃
- 我们致力于更多地利用 Matrix
- 使用/编写 Matrix 机器人而不是 IRC 机器人（例如，已经有一个 GitHub 机器人和一个 RSS 机器人）
- 在 Matrix 上而不是 GMeet/Bluejeans 上举办会议（我有一个概念验证）
- 更丰富的在线会议工具（可链接聊天、嵌入式 Etherpads 等）
- （我们还可以尝试很多其他事情，但为了简洁起见，我将在此处停止）
我感到兴奋。从我在 Satellite/TheForeman 担任社区负责人期间的工作中，我知道像能够对同事的评论给出“竖起大拇指”或“爱心”表情符号这样的小功能可能看起来微不足道，但它对构建社交粘合剂意义重大，而这种粘合剂在在线互动中往往缺失。这仅仅是一个例子，说明更丰富的互动（结合 Thibault 所说的更低的进入门槛）将为我们作为社区带来回报。
未来贡献者峰会将 *直接在* 社区房间中供所有人观看直播并参与的想法让我非常高兴 - 将其隔离在 GMeet 中意味着我们参与度会低得多。KDE 现在正在为 Akademy 做这件事（使用 BigBlueButton），当然，整个 FOSDEM 2021 都在 Matrix/Jitsi 上进行，所以这是可能的。
机器人和小部件的可能性同样巨大 - Matrix 具有用于编写机器人的 REST API（以及 SDK），而 Element 可以在 UI 中嵌入 HTML 小部件（例如，KDE 正在开发一个用于进行演讲的问答调查应用程序）。如果我们使房间完全公开（而不仅仅是向任何人开放加入），那么您可以获得聊天记录中任何一行的 URL，这意味着忘记启动 Zodbot 就不那么关键了（尽管它仍然具有我们喜欢的功能，当然）。我们还可以做更多的事情，尤其是在与其他社区合作方面。特别是，我想尝试一下现有的 GitHub Matrix 机器人，但还有 Etherpads、日历、房间会议、RSS、Travis 机器人，我们还可以随时编写自己的机器人。
证明 Matrix 是最佳选择
在我们详细讨论 Matrix 之前，我认为回顾一下我看到的 IRC 问题很有帮助。我想再次强调，IRC *不会* 消失。它对许多人来说都有效，我对此并不否认。但我将再次提到幸存者偏差 - 我不再相信它对 *今天* 加入我们的新贡献者有效。
IRC 的问题是什么？
如果您向 Mozilla 提问，"一切都是答案"，但我并不完全同意。其中一些问题适用于我们，一些问题不适用。特别是，Mike Hoye 谈到了未经身份验证的网络和垃圾邮件/恶意聊天的问题 - 我们可以使用 Libera 上需要注册的频道模式。但是，他的其余观点仍然成立：- 可用的界面没有跟上现代期望 - 垃圾邮件/骚扰是该平台的普遍现象（不在我们的频道中，但如果我们的用户在其他频道中，他们将暴露于此） - IRC 经常被机构和公司网络阻止（通常是由于一般的 IRC 垃圾邮件，即使它不影响我们） - Freenode 事件表明组织所有权也存在问题。由于他人的事件，我们在 Freenode 上失去了所有东西。
但是，这是否加起来等于“IRC 很糟糕”取决于您的用例
我已经使用 IRC 了，为什么我应该停止？
正如我所说，我认为对于现有的 IRC 用户来说，它很好。如果您感到满意，则无需停止。您已经设置了垃圾邮件防护措施，您已经完成了 Nickserv 咒语，并且您的组织显然允许 IRC 流量。继续！但是请花点时间，再次阅读一下该列表中的内容。对于不熟悉 IRC 世界的人来说，这样做有多容易？
我是新手，我应该使用 IRC 吗？
不。它不符合人们对现代聊天系统的期望 - 与人们今天遇到的注册系统相比，Nickserv 显得... 不直观（委婉地说），访问很困难（并且经常在网络级别被阻止），没有丰富的界面，并且没有持久性（没有跳板，而跳板可能比 Nickserv 更难设置）。对于那些没有深入参与项目的人来说，这是一个**不必要的大**障碍，进入一个**无论如何都无法满足新用户期望**的平台。对于那些没有深深地融入项目中的人来说，这是一个 *巨大的* 要求。我发现，IRC 的整体增长速度落后于其他平台并不奇怪，我们也不例外。
我是一个组织，我应该在 IRC 上设置吗？
如果我今天要启动一个新项目，我不会使用 IRC。对于一个组织来说，有三件事需要考虑。首先，访问和招募——正如我们之前讨论过的，开源项目需要志愿者，而当我们设置了很大的障碍时，项目就会逐渐衰落。其次，保障成员安全——我们有行为准则，但考虑到 IRC 的工作方式，很难实施，而且我们无法像在其他地方那样要求人们同意行为准则。第三，所有权——最近的 Freenode 事件表明，我们无法控制自己的聊天域名，而这在论坛或电子邮件中是可以做到的。相反，我们只能眼睁睁地看着我们的社区因他人的行为而分裂。
我认为我们还没有到宣布 IRC 为“遗留”系统的地步（就像 GNOME 正在考虑的那样），但我认为现在是时候开始向更现代化、更能吸引社区新成员的平台过渡了。这个平台就是 Matrix——正如我在章节标题中所说，我们需要证明这一点……
Matrix 能为我们带来什么？
首先，我们需要定义什么是 Matrix，因为我经常看到这一点被混淆。Matrix 是一种用于实时通信的协议（无论是文本、音频、视频还是文件共享）。它不是客户端，就像 Thunderbird 不是 SMTP，Hexchat 不是 IRC 一样。诸如“Matrix 臃肿且缓慢”或“我喜欢我的 IRSSI 界面”之类的担忧需要放到一边，因为这是客户端层面的讨论——当然，这是一个有效的讨论，但不在本文讨论范围之内。有兴趣的人可能想看看客户端页面，有很多选择，从完整的 Web UI 到 WeeChat 的插件。
面向旧 IRC 用户的 Matrix
我在这里假设这些用户想要尝试 Matrix 账户——那些希望留在 IRC 上的用户可以继续使用。如果是这样的话，实际上变化很小。Matrix 可以作为 IRC 使用，你只是忽略了图像共享等更丰富的功能（Element 中甚至有一个 IRC 显示样式）。由于桥接功能，你可以直接跳入某些 IRC 网络（例如 Libera 和 OFTC）上的 IRC 频道。你将免费获得持久性（无需运行跳板），并且可以像往常一样继续使用（这是我过去 4 年的工作流程）。
面向新用户的 Matrix
我已经谈到了新用户的期望，因此你会期望 Matrix 与 Slack 等类似。你期望的所有功能（反应、通知、回复等）都存在。入门流程也很简单——由于 Element 存在于 Web 应用中，新用户可以在浏览器中加载并试用它。如果他们希望深入使用，可以获取独立的桌面和/或移动客户端以方便访问。因此，许多入门障碍都被去除了——没有神秘的 Nickserv 流程（注册是基于电子邮件或 SSO 的，就像你期望的现代服务一样），流量不会经常被阻止，并且默认情况下存在持久性。
无论哪种情况，都值得阅读这篇关于 Matrix 与电子邮件的比较文章，因为电子邮件中的许多概念都适用。
面向组织的 Matrix
好的，这是重点——Matrix 对整个 Ansible 社区意味着什么？我将在这方面花更多时间，因为我们都熟悉聊天，但也许这些组织方面的问题会更加细致。
访问和招募
正如我们所说，Matrix 支持用户期望从现代聊天中获得的功能集。Ansible 想要扩大其贡献者社区并不奇怪，但它更深远。随着即将推出的“空间”功能，Matrix 允许我们将房间组织成一个逻辑层次结构，并使用单个 URL 链接到整个空间。这很容易链接到我们的文档、聊天和博客/社交媒体中，鼓励其他人加入我们。它本质上是将我们的 IRC 文档页面引入 Matrix，并使只需点击一下即可加入工作组或类似的组。通过清晰标记的推荐房间，新成员可以找到合适的地方提出问题。
（请注意，空间功能仍在实验阶段，处于 Beta 版——这是预期目标，但目前我们会在文档页面上链接到 Matrix 房间。）
更进一步，我们可以将我们的房间完全公开，这允许在 Matrix 中“窥探”——这允许访客（以只读模式）查看聊天，以便他们在注册之前查看这是否是加入并提出问题的正确频道——很难再降低入门门槛了。如果有人想尝试，我已经在一个小型工作组房间中启用了此功能。
安全和行为准则
Matrix 拥有良好的审核和行为管理工具。与 IRC 不同，Matrix 中不存在未经身份验证的用户（存在访客用户，但这并不相同，而且目前也存在问题），因此垃圾邮件问题要少得多（事实上，我只见过一次严重的 Matrix 垃圾邮件攻击，而且处理得比 IRC 好得多）。如果是骚扰而不是垃圾邮件，那么与任何聊天平台一样，都可以踢出或永久禁止任何问题用户，而且比在 IRC 上直观得多。
然而，Matrix 带来了某种意义上的静默审核革命。Matrix 是联邦化的（我们还没有花太多时间讨论这一点），这意味着还有其他人运营着 Matrix 服务器——并且（用另一个比喻）与电子邮件类似，我们可以共享不良行为者的信息。类似于人们可以订阅自己的电子邮件服务器的黑名单一样，Matrix 服务器可以共享关于禁用列表的信息。这非常重要——如果我们决定信任另一个组（例如 Fedora），那么我们可以订阅他们的禁用列表，任何存在的不良行为者也会立即从我们的社区中移除。形成一个共享价值观和行为准则的项目组可以使这一点变得非常强大。
执行我们对社区期望的标准的工具更为深入，但我不想一直说下去。我会链接到这篇来自 Mozilla 关于 Matrix 在行为准则执行方面的工具的文章，以供参考。
所有权
项目的名称意味着什么？当一个人从工作账户发送电子邮件时，他们代表什么价值观？当你加入某个群体的聊天室时，你在与谁交谈？所有权、命名空间、域名、主权，它有很多名称，但至关重要。
Freenode 事件表明，如果我们不小心，我们可能会很快失去这一点；几乎在一夜之间，我们所有的房间都空了，命名空间变得毫无意义。事实上，Libera 也存在同样的风险——虽然我个人信任 Libera 的管理员，但它仍然是第三方网络。Slack、Discord 等也是如此。事实上，只有电子邮件真正解决了这个问题（哦，又是电子邮件）。我没有 Ansible 电子邮件地址，但我有一个 Red Hat 电子邮件地址，只有 Red Hat 可以将其从我那里拿走。当我从该地址发送电子邮件时，我是在做 Red Hat 的事情，这一点很重要。
Matrix 也可以做到这一点——就像电子邮件服务器使用 MX DNS 记录一样，Matrix 也有命名空间。如果我们希望它们成为那样，我们的房间可以是 #devel:ansible.com（一个 Matrix 房间可以有多个别名），并且主房间地址赋予管理房间的权限。只要我们持有 DNS，我们就拥有房间——这是联邦化的优势之一。
但它更深远，因为我们将拥有要分发的账户，位于第二个 DNS 名称（https://chat.ansible.im）上。为什么是第二个域名？好吧，这里有一些关于 Matrix 主权的详细思考，但其中一个观点是关于模仿和代表性的。这些账户将提供给更广泛的 Ansible 社区，我不希望这些账户与 Red Hat（即 ansible.com）相关联——它们是为社区服务的，ansible.im MXID 的所有权应该与项目电子邮件地址具有相同的权威性。
关于如何分发这些账户（以及在需要时如何收回它们）有一些需要决定的问题，但我会在后面介绍。
我们如何到达那里？即计划
好的，你了解了愿景、顾虑以及 Matrix 如何改善我们的现状。但我们如何到达那里呢？有一些事情需要做，其中一些已经开始实施（因为它们是非强制性的），而另一些则需要我们共同同意实施。
家庭服务器
我关于主权和域名所有权的说明基于拥有我们自己的家庭服务器。我们可以自行托管它，但是我们没有做好自行运维的准备，而且我们希望支持我们的开源供应链。因此，我们已获得 Red Hat 的资金，用于支付使用 Element Hosting（ems.element.io）的 Matrix 家庭服务器费用。这将为我们提供必要的域名所有权和用户账户，以便社区开始向 Matrix 过渡。
值得注意的是，我与之交谈的所有社区都对 Element 赞不绝口。到目前为止，与他们合作一直是一种乐趣，而且他们非常乐于接受反馈，因此我相信这种关系会很好，并且我们可以在需要时进行改进。如果你想了解 Mozilla 是如何做的，可以阅读他们经历的过程。
正如前面提到的，我们正在设置两个域名。第一个是一个小型仅限管理员的实例，用于控制 ansible.com 命名空间——为我们提供 Ansible 主房间名称以及执行我们行为准则的审核工具。此处的账户将供维护管理员安装的人员使用（目前是我和 Gundalow，但我们希望在短期内降低巴士因子），并且不会用于日常使用。第二个是用于用户账户的主家庭服务器（ansible.im）。这两个实例都已于 2021 年 6 月 24 日上线，尽管 ansible.com 实例在与 DNS 协调事宜期间尚未进行联邦化。
用户体验
我正在参考 https://chat.mozilla.org 来寻找灵感——清晰显示对用户的期望、链接到行为准则页面等。如果你创建一个账户并登录，行为准则会再次显示。Synapse（家庭服务器软件）可以存储同意信息，因此我们可以要求用户同意行为准则。Web UI 很清晰，我们可以从我们的文档和媒体中链接到它，人们可以跳到社区频道作为第一个联系点。我们正在设置 ansible.im 以使其看起来类似，Gundalow 正在努力（但我们都不擅长页面设计，所以请耐心等待：P）。
Matrix 基金会（负责维护 Libera 桥接）已友好地授予我们对 Libera/Matrix 房间的管理员权限（默认情况下，libera.chat 房间只有桥接作为管理员），因此，一旦 ansible.com 实例正常工作，我就能将 ":ansible.com" 房间 ID 添加到每个房间。为了完整性，我已开始添加 :ansible.im 别名。Libera.chat IRC 频道名称不会更改 - 这些只是 Matrix 侧的别名，我们将使用有意义的名称（例如，#community:ansible.com 将是 #ansible-community:libera.chat 的别名）。
这些房间已经组织成一个空间（目前为 #ansible-space:matrix.org），我将在未来几周与 Element 会面，就空间总体提供反馈，如果您参与了空间测试版，请告诉我您的使用体验。
账户
这是我们需要决定如何处理的一个领域。正如我们所讨论的，Matrix 账户类似于电子邮件地址，我们不会随意向任何人提供 Ansible 电子邮件地址。我们应该对 Ansible 账户同样谨慎 - 我们不希望有人使用 Ansible ID 骚扰他人或进行诈骗。这意味着我们需要两件事 - 一个发放账户的系统，以及一个收回账户的流程。
为了发放账户，我认为很明显我们不希望开放注册。其他组织（Mozilla、Fedora）这样做，但它们规模更大，并且有其他 IAM/SSO 系统将 Matrix ID 绑定到一起 - 我们没有。GNOME 处境类似，并且正在开发一个与 Keycloak 集成的系统，允许现有用户为新请求“担保”，两个担保即可获得批准。该系统尚未准备好，但 GNOME 将其公开并欢迎合作。在此期间，我建议我们采用手动担保的方式，管理员（可能是，但不只是）收到请求，请求从社区获得必要的担保，然后创建账户。创建和处理请求的确切细节有待确定（通过拉取请求或类似方式？），但原则很明确。
从技术上讲，删除账户非常简单，但我们需要制定政策。显然，任何违反我们行为准则的行为都是删除账户的理由 - 我们社区的安全非常重要。自然会认为，那些远离 Ansible 的人应该收回他们的账户 - 但由于我们按活跃用户每月付费，因此在实践中可能不需要这样做（只有当用户仍在 Matrix 上活跃，但不在 Ansible 上时，才需要这样做）。尽管如此，我们应该保留这样做的权利，即使在实践中我们不常使用它。同样，Thib 也有一些我同意的想法
如果您违反政策，组织可以并且很可能会收回您的账户，并且不会让您有机会检索您的数据。如果您离开组织，也可能并且应该收回您的账户。这些账户确实可以比作工作电子邮件账户：您应该将使用此账户的活动限制在您为提供该账户的组织所做的事情上，并且不能期望在您离开后保留它。
遗憾的是，缺乏多账户客户端确实倾向于让人们使用单个 Matrix 账户处理所有事务，但在理想情况下，情况并非如此，用户会像在工作和私人电子邮件之间一样，将他们的活动隔离开来。不过，目前这将很痛苦，因此，虽然我们需要有收回账户的权利，但我不希望使用该权利，除非我们必须这样做（无论是出于违规还是出于成本原因）。
重要的是，Matrix 是联合的。没有人必须拥有 ansible.im MXID 才能参与我们的社区。但是，这些账户是我们购买的套餐的一部分，因此我们不妨使用它们，它们可能是对用户的一个有用的额外福利，或者对还没有获得 Matrix ID 的用户来说是一个好处。
总有一天，我希望我们的社区能够开放注册 - 但在我们拥有可以将其绑定到的东西（例如 Fedora 和 Mozilla 所做的那样）之前，我认为上述担忧大于好处。我们会实现的 :)
与 IRC 的交互
我再次重申，我们没有停止使用 IRC 的计划。不过，不可避免地，更现代系统的某些丰富功能将在 IRC 上丢失，我们必须接受这一点。也就是说，很多功能都可以正常工作 - 嵌入式 Etherpad 可以提供一个直接链接，供 Matrix 外部使用，同样，Jitsi（或其他会议呼叫软件，如 BBB）也有一个外部 URL。这些将始终清晰地发布，以便 IRC 用户不会被排除在外。同样，我们也乐于调整桥接在我们房间中关于编辑和长行的行为，如果这成为一个重要问题，等等。简而言之，我不想让 IRC 用户感到被忽视 - 我们应该在问题出现时讨论它们。
开始行动
这对我们来说是一个重大的转变，但也是一个必要的转变（在我看来）。作为一个社区，我认为我们需要批准两件事
- 我们，Ansible 社区，接受 Matrix 作为与 IRC 同等重要的合作伙伴，我们欢迎充分利用其功能集。
- 我们发放和删除 ansible.im 账户的政策是什么。
我认为我之前在论证中已经涵盖了（1）。对于（2），我的建议如上所述 - 基于拉取请求的担保工作流程，需要两个现有的 ansible.im 账户的确认才能授予访问权限。对于删除，我们需要在这里添加一些措辞，但我建议这只有指导委员会才能行使的权力，并且仅用于违反行为准则或在 Ansible 社区内不活跃的情况。我期待在不久的将来将这两项声明提交给指导委员会批准。
除此之外，我还希望看到我们定期进行回顾，以便我们在前进的过程中进行调整。这不是一劳永逸的事情，这是一个长期的项目，如果要使其发挥作用，我们需要倾听。我认为第一次回顾应该在我们开始正式推广 Matrix 后的约 1 个月进行。
我感到很兴奋。我希望您也一样。如果您有任何疑问，随时与我联系（通过 @gwmngilfen:ansible.im）。感谢您阅读到最后 :)
