我们希望听到您的声音！帮助我们深入了解 Ansible 生态系统的现状。
参与 Ansible 项目 2024 年调查

Ansible 和 Matrix

来源

架桥 - Ansible 社区在聊天方面下一步需要走向何方

这篇文章很长，因为我有很多内容要讲。但我将首先介绍总体情况，如果您想了解详细信息，可以继续阅读。请注意，在现阶段，这代表着我的观点 - 正如我将在最后重复的那样，我的目标是让社区批准这一点，但首先我必须说服你们 :)

世界在变化，我们也随之变化。我们的沟通方式一直在发展，而且周期性地，如果我们想吸引新人加入我们的社区，我们就必须跟上时代的步伐。今天，这意味着提供一个让新老贡献者都感到受欢迎、安全和有价值的地方，并提供丰富的界面和低门槛。我想要帮助构建它，因为我担心如果我们不这样做，我们将逐渐消失，而 Ansible 值得拥有更好的未来。

我将阐述如何利用 IRC 的坚实基础，成为一个以 Matrix 为首（但不仅仅是 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、成为优秀的开源公民并支持我们的供应链来做出贡献
      • 这意味着 Matrix 房间可以获得类似 #welcome:ansible.com 的地址
      • 我们可以为贡献者提供 Matrix 账户（稍后详细介绍）
  • IRC 保持维护
    • IRC 不会消失！那些对自己的工作流程感到满意的用户不应该被抛弃
      • 对希望让自己的设置在 Matrix 中工作的用户应该提供帮助
      • 应在可能的情况下解决问题。我们可以使用许多调整选项来改善 IRC 端的体验，但我们需要记住，目标是使我们的聊天现代化，并且随之而来的一些变化。
    • 我们旨在帮助用户逐渐过渡到 Matrix，并在合适的情况下提供 Ansible Matrix 账户
  • 我们致力于更多地使用 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 可以将 HTML 窗口小部件嵌入到 UI 中（例如，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 希望壮大其贡献者社区，这并不奇怪，但它更深远。随着即将推出的 "Spaces" 功能，Matrix 允许我们将聊天室组织成逻辑层次结构，并通过单个 URL 链接到整个空间。这使得我们可以轻松地将其链接到我们的文档、聊天和博客/社交媒体中，鼓励其他人加入我们。它本质上是将我们的 IRC 文档页面 迁移到 Matrix，并一键即可跳转到工作组或类似的组。通过明确标记的推荐聊天室，新成员可以轻松找到提问的好去处。

（注意 Spaces 仍处于实验阶段和测试阶段——这是预期的目标，但目前我们会在文档页面上链接到 Matrix 聊天室）。

更进一步，我们可以将我们的聊天室完全公开，这在 Matrix 中允许“窥视”——这允许访客以只读模式查看聊天内容，然后他们注册，让他们一键，在浏览器中查看是否这是加入并提出问题的正确频道——很难让门槛低于此。我已经在 一个小工作组聊天室 中启用了此功能，如果有人想尝试，可以试试。

安全与行为准则

Matrix 拥有良好的审核和行为准则工具。与 IRC 不同，不存在未经身份验证的 Matrix 用户（有访客用户，但情况不同，并且目前处于故障状态），因此垃圾邮件问题要少得多（事实上，我只见过一次严重的 Matrix 垃圾邮件攻击，并且处理得比 IRC 好得多）。如果发生骚扰而不是垃圾邮件，那么与任何聊天平台一样，可以踢出或永久封禁任何问题用户，并且比 IRC 上直观得多。

然而，Matrix 带来了某种意义上的审核静默革命。Matrix 是联合的（我们还没有花太多时间讨论这个），这意味着还有其他人运营着 Matrix 服务器——并且（再次）类比于电子邮件，我们可以共享关于不良行为者的信息。类似于可以订阅自己的电子邮件服务器的黑名单一样，Matrix 服务器 可以共享关于封禁列表的信息。这非常重要——如果我们决定信任另一个组（例如 Fedora），那么我们可以订阅他们的封禁列表，并且任何在那里的不良行为者也会立即从我们的社区中移除。形成一个共享价值观和行为准则的项目组可以使这一点变得非常强大。

执行我们期望社区遵守的标准的工具要深得多，但我不想永远谈论下去。我将链接到 这篇文章，其中包含 Mozilla 对 Matrix 在 CoC 执行方面的工具的一些思考。

所有权

项目的名称意味着什么？当一个人从工作帐户发送电子邮件时，他们代表什么价值观？当你加入某个群体的聊天室时，你在与谁交谈？所有权、命名空间、域名、主权，它有很多名称，但至关重要。

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 如何改善我们的现状。但是我们如何实现呢？有一些事情需要做，其中一些已经开始实施（因为它们是非约束性的），而另一些则需要我们共同达成协议才能实施。

Home Server

我关于主权和域名所有权的说明基于拥有我们自己的 Home Server。我们可以自行托管它，但是我们没有做好自行运营的准备，并且我们希望支持我们的开源供应链。因此，**我们已获得 Red Hat 的资助，用于支付 Element Hosting (ems.element.io) 上的 Matrix Home Server 的费用**。这将为我们提供必要的域名所有权和用户帐户，以帮助社区开始向 Matrix 迁移。

值得注意的是，我与之交谈的所有社区都对 Element 给予高度评价。到目前为止，与他们合作非常愉快，而且他们非常乐于接受反馈，因此我相信这种关系会很好，并且我们可以根据需要进行改进。如果您想了解 Mozilla 是如何做到的，请阅读他们 经历的过程。

正如前面提到的，我们正在设置两个域名。第一个是一个小型仅限管理员的实例，用于控制 ansible.com 命名空间——为我们提供 Ansible 主要聊天室名称以及执行 CoC 的审核工具。此处的帐户将用于维护管理员安装的人员（目前是我和 Gundalow，但我们希望在短时间内降低巴士系数），并且不会用于日常使用。第二个是用于用户帐户的主要 Home Server（ansible.im）。这两个实例都已于 2021 年 6 月 24 日上线，不过 ansible.com 实例尚未进行联合，因为我们正在解决 DNS 相关问题。

用户体验

我正在参考 https://chat.mozilla.org 获取灵感——明确显示对用户的期望、指向行为准则页面的链接等等。如果您创建帐户并登录，则会再次显示行为准则。Synapse（Home Server 软件）可以存储同意信息，因此我们可以要求用户同意行为准则。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 会面，就 Spaces 的整体情况提供反馈，因此如果您参与了 Spaces 测试版，请告诉我您的感受。

账户

这是我们需要决定如何处理的一个领域。正如我们所讨论的，Matrix 账户类似于电子邮件，我们不会随便向任何人发放 Ansible 电子邮件地址。我们应该对 Ansible 账户同样谨慎——我们不希望有人使用 Ansible ID 骚扰他人或进行诈骗。这意味着我们需要两件事——一个发放账户的系统，以及一个收回账户的协议。

关于账号发放，我认为很明确的一点是，我们不希望开放注册。其他一些组织（Mozilla、Fedora）是这样做的，但它们规模更大，并且有其他 IAM/SSO 系统可以将 Matrix ID 关联起来——我们没有。GNOME 处于类似的境地，并且正在开发一个与 Keycloak 集成的系统，允许现有用户为新请求“担保”，两个担保就能获得批准。该系统尚未准备好，但 GNOME 正在将其公开，并欢迎合作。在此期间，我建议我们采用手动担保的方式，管理员（可能是我的，但不仅限于我）收到请求，然后请求从社区获得必要的担保，最后创建账号。关于如何发起和处理请求的具体细节有待确定（通过 Pull Request 或类似方式？），但原则很明确。

从技术上讲，删除账号非常简单，但我们需要制定相应的策略。显然，任何违反我们行为准则的行为都将成为删除账号的理由——我们社区的安全至关重要。自然会认为那些远离 Ansible 的人应该收回他们的账号——但由于我们每月按每个活跃用户付费，实际上可能不需要这样做（只有当用户仍在 Matrix 上活跃，但不在 Ansible 上时，才需要这样做）。尽管如此，我们应该保留这样做的权利，即使在实践中我们不会经常使用它。再次强调，Thib 有些想法，我赞同。

如果您违反了政策，**组织可以并且很可能会收回您的账号**，并且您将无法检索您的数据。如果您离开组织，也应该收回您的账号。这些账号实际上可以比作工作邮箱账号：您应该将使用此账号的活动限制在您为提供此账号的组织所做的工作范围内，并且不能期望在您离开后继续保留它。

遗憾的是，缺乏多账号客户端确实倾向于让人们使用单个 Matrix 账号处理所有事情，但在理想情况下，情况并非如此，用户会像在工作和私人邮件之间区分活动一样，将他们的活动分开。不过，目前这会很痛苦，因此，虽然我们需要有收回账号的权利，但我不希望除非必要（出于违规或成本原因），否则使用该权利。

重要的是，Matrix 是联合的。没有人必须拥有 ansible.im MXID 才能参与我们的社区。但是，这些账号是我们购买的套餐的一部分，所以我们不妨使用它们，它们可能是一个有用的福利，或者对于还没有获得 Matrix ID 的用户来说是一个不错的选择。

总有一天，我希望为我们的社区开放注册——但在我们有东西可以将其关联起来之前（例如 Fedora 和 Mozilla 所做的那样），我认为上述担忧大于好处。我们会实现的 :)

与 IRC 的交互

我再次强调，我们没有停止使用 IRC 的计划。不过，不可避免的是，更现代的系统的一些丰富功能在 IRC 上会丢失，我们必须接受这一点。也就是说，很多功能仍然有效——嵌入式 Etherpad 可以有一个直接链接供 Matrix 外部使用，同样，Jitsi（或其他类似 BBB 的视频会议软件）也有一个外部 URL。这些链接将始终清晰地发布，以便 IRC 用户不会被排除在外。同样，如果编辑和长行成为一个重要问题，我们也乐于调整我们房间中桥接器的行为等等。简而言之，我不想让 IRC 用户感到被忽视——我们应该在问题出现时讨论它们。

开始行动

这对我们来说是一个重大的转变，但也是一个必要的转变（在我看来）。作为一个社区，我认为我们需要批准两件事

  1. 我们，Ansible 社区，接受 Matrix 作为与 IRC 同等重要的合作伙伴，并且我们欢迎充分利用其功能集。
  2. 我们发放和收回 ansible.im 账号的策略是什么。

我认为我在之前的论证中已经涵盖了 (1)。对于 (2)，我的建议如上所述——基于 Pull Request 的担保工作流程，需要两个现有 ansible.im 账号的确认才能授予访问权限。对于删除，我们需要在这里添加一些措辞，但我建议只有指导委员会才能行使这项权力，并且仅限于违反行为准则或在 Ansible 社区内不活跃的情况。我期待在不久的将来将这两项声明提交给指导委员会批准。

除此之外，我还希望看到我们定期进行回顾，以便我们边走边调整。这不是一劳永逸的事情，这是一个长期的项目，如果要使其发挥作用，我们需要倾听。我认为第一次回顾将在我们开始正式推广 Matrix 后约 1 个月进行。

我感到很兴奋。我希望您也一样。如果您有任何问题，请随时与我联系（在 @gwmngilfen:ansible.im 上）。感谢您阅读到最后 :)

提供支持