会议 #2

第二次会议于 2021 年 2 月 4 日 17:00 GMT 在一个文档上举行，正好是第一次会议一周后。当时一些贡献者无法参加，只有大约半打人出席。因此，决定在此次会议上不做任何重要决定：重要的、有争议的事项将推迟到下一次会议，届时将提前更长时间准备和通知。

在这次会议中，我们查看了各个工作组的进展情况（进展报告）。然后，我们讨论了沟通。接着，我们讨论了社交媒体账号的凭证访问、如何处理我们的论坛，以及如何组织下一次会议。最后，我们对会议期间未涉及的内容进行了快速的问答。

关于Jabber vs XMPP（集体的名称）和推荐的服务器的较长、可能有争议的点已简要讨论，但未做出任何决定。这两个点被推迟到下一次会议。会议在开始约 4 小时 45 分钟后结束。

议程

要点

在本节中，我们将讨论议程中安排的各个要点。

进度报告

在讨论其他议题之前，我们先花点时间回顾上次会议以来取得的成就。在每个小节中，我们首先处理上次会议的工作组积压工作，然后介绍工作组自上次会议以来采取的其他举措。

本节包含简单的进度报告。这将是快速的，问题/疑虑将在议程的专门点中表达，或在本次会议结束时的问题/解答环节中提出。每个工作组的待办事项包括积压的任务，以及在本次会议期间新增的任务。

集体任务

这里，我们谈谈上次会议决定的集体任务，这些任务没有分配给具体工作组：

  • 发布会议 #1 的纪要：在此处完成
  • 发布公告：在此处完成
  • 开始对下次会议日期进行投票：在此处完成
  • 为下一次会议做好准备，将我们今天无法讨论的要点添加到议程中：完成
  • 列出我们想邀请参加会议的其他集体 待办
  • 准备关于如何组织会议和参与会议的教程 待办

待办：

  • 在此处列出我们想邀请参加会议的其他团体 待办
  • 准备关于如何组织会议和参与会议的教程 待办

系统管理员工作组

上次会议的待办事项：

  • 桥接工作组提出的设置桥接解决方案
  • 考虑设置 ConverseJS，让人们可以从网页加入我们的聊天室和会议

上次会议以来的注意事项：

  • ConverseJS 未打包给 Debian、nix 或 guix，我们将不得不手动设置；目前尚未设置 converseJS；xmpp-web 是一个潜在的、更轻量级的替代方案
  • Matterbridge 未打包给 Debian 或 guix，但已打包给 nix（但包已过时）；matterbridge 已从 Debian回溯源代码使用 golang 设置

待办：

  • 配置 Prosody 以支持 BOSH 和匿名登录
  • 考虑是否启用 mod_slack_webhooks，以便 matterbridge 可以创建幽灵用户，而不是通过单一昵称中继消息（高度实验性）
  • 等待更详细的 matterbridge/ConverseJS/xmpp-web 提案并设置它们

网站工作组

上次会议的待办事项：

  • 在网站上开设博客版块 已完成
  • 发布第一次会议记录和我们集体的公告 已完成
  • 在网站上开设微博版块，并授予媒体工作组访问权限 待办

待办：

  • 在网站上开设微博版块，并授予媒体工作组访问权限
  • 整合有用的外部资源
  • 在页面上列出现有聊天室：#chat、#sysadmin、#website、#translations、#bridging、#science
  • 到处显示"施工标志"，让我们的用户知道一切都是正在进行中的工作，欢迎所有贡献

翻译工作组

上次会议的待办事项：

  • 翻译会议第 1 次会议纪要 待办
  • 翻译集体公告：法语 已完成
  • 招募更多翻译人员

上次会议以来的注意事项：

  • 关于法语翻译存在争议：是应使用性别中性（包容性）形式，还是使用国家批准的法语标准变体？

待办：

  • 招募更多翻译人员
  • 为下次会议制定包容性语言提案
  • 翻译第 1 和第 2 次会议纪要

桥接工作组

上次会议的待办事项：

  • 探索多用户聊天桥接解决方案：已选择 Matterbridge 已完成
  • 向系统管理工作组提出具体提案 待办

上次会议以来的注意事项：

  • 在哪里托管 Matrix 账号/聊天室？
    • feneas.org：他们非常担心其系统管理员的状况，以及缺乏贡献者，因此不建议依赖他们做任何事情
    • aria-net.org（Metronome 项目）：他们很乐意为我们托管聊天室和机器人账号，并且我们可以向公众推广他们的Bifrost XMPP <-> Matrix 网关（尽管 Bifrost 仍处于测试阶段）
  • 在哪里托管 IRC 账号/聊天室？Freenode？OFTC？~chat？
  • 如何存储和共享用户凭据？请参阅议程后面的"安全和凭据"部分
  • 在此次会议中测试了 matterbridge（尽管未在我们的基础设施上托管），在 meeting@joinjabber.org 和 irc.tilde.chat 上的#joinjabber 之间中继讨论；看起来非常实用

待办：

  • 使用 bridging@joinjabber.org 恢复邮件创建 Matrix/IRC 账号
  • 向系统管理工作组提出具体提案

媒体工作组

上次会议的待办事项：

  • 在 Mastodon 和 Movim 上创建账号，并共享凭据 待办
  • 从网站工作组获取凭据，以在微博部分发布 待办
  • 考虑是否应自行托管 Movim 实例，如果是，请联系系统管理工作组 待办

上次会议以来的注意事项：

  • 媒体工作组如何共享凭据？请参阅议程中的"安全和凭据"部分
  • 考虑了 RSS 到 ActivityPub（Mastodon）机器人，发现了多个选项
  • 一些服务在注册时需要电子邮件确认：media@joinjabber.org 是为此目的创建的，是一个重定向到媒体工作组当前成员的别名

待办：

  • 在 Mastodon 和 Movim 上创建账户，并分享凭证
  • 从网站工作组获取凭证，以便在微型博客部分发布到网站上
  • 考虑我们是否应该自托管自己的 Movim 实例，如果是的话，请与系统管理员工作组联系，提出具体建议

沟通

关于我们是否更喜欢使用 Jabber还是XMPP 来指代 Jabber/XMPP 生态系统的议题已被推迟。

有用的资源

我们希望在网站上宣传哪些外部资源？一些想法：

此外，这里有一些关于 Jabber/XMPP 的新闻好去处：

关于如何在网站上整合这些资源的想法将作为网站工作组的一部分进行制定。它们可以根据目标受众进行划分：最终用户、服务器操作员、客户端/服务器开发者。

网站建议

来自上次会议的一些建议，以及自那时以来提出的其他建议，表示我们应该在网站上添加：

  • 教程：已在教程部分完成
  • 常见问题：欢迎贡献！
  • 贡献指南

有人指出我们的网站没有宣传许可证。我们应该采用什么许可证？像 Creative Commons BY-SA 这样的自由版权许可证听起来不错，但这个具体问题将推迟到下次会议讨论。

有人询问我们是否应该在我们的服务器上设置一个维基软件（如MediaWiki）；以下是优缺点列表：

  • + 简单的网页界面，便于没有 git 知识的贡献
  • - 又一个需要维护的应用程序
  • - 我们没有任何集中认证服务，因此人们需要记住更多的用户名/密码（尽管第三方认证可能有效）
  • - 与已经像维基一样的网站冗余（只需要一个网页编辑器）
  • - 与网站（静态文件）相反，动态维基不能在点对点网络（Bittorrent/IPNS/Freenet）上重新分发

作为替代，我们可以：

  • 在我们的代码托管平台上使用仓库维基：不过，这会使得将信息导出到我们的网站变得更加困难
  • 使用 Gitea 的集成 Web 编辑器让非技术人员提交合并请求：然而，Gitea 目前还没有像 Github/Gitlab 那样的集成"fork-and-edit"工作流

另外，有人建议我们可以从以下网站中找设计灵感：

我们提醒大家，JoinJabber 项目是由志愿者运营的，欢迎志愿者网页设计师帮助改进我们的网站。

会议中收集了一些额外的备注。它们已被添加到网站工作组的待办事项中。

安全和凭据

如何共享社交媒体账号（和其他账号）的密码？如何防止未经授权的访问，同时确保密码不会随时间丢失？对于机器人/服务使用的密码，我们可以将它们保存在服务器上。对于人类使用的密码（如社交媒体账号），它们可以暂时保存在贡献者的邮箱中。我们只是在我们的邮件系统上设置了专用别名：

这些别名将把邮件转发给相应工作组的成员。

有人建议使用共享密码管理器。然而，系统管理员工作组的成员不愿意在我们对现有服务有良好支持之前部署另一个服务。作为替代，有人建议可以使用 GPG 加密密码，以便需要的人可以访问。

论坛和邮件列表

我们目前使用Discourse作为论坛，因为这是我们找到的唯一一个在没有 JavaScript 的 Web 浏览器中工作且也可以通过电子邮件使用的解决方案。然而，关于它并非一切都很完美：

  • Discourse 只支持每个虚拟主机一个基本 URL，所以我们无法通过 .onion 地址提供相同的论坛（工单）
  • Discourse 安装仅支持作为 Docker 容器，因此我们应该制作一个 Ansible 角色来支持 Discourse 设置（工单）
  • Discourse 电子邮件堆栈非常糟糕（参见上面的工单）
  • Discourse 不基于 XMPP 协议：虽然这不是不使用该软件的理由，但基于 Jabber/XMPP 的解决方案会让我们更满意
  • Discourse 可能不容易与 Jabber/XMPP 身份验证或其他联邦身份验证机制一起使用

像 Mailman 和 Redmine 这样的常规解决方案只能做论坛或邮件列表，但同时做这两件事却非常糟糕。探索了三种基于 Jabber/XMPP 的解决方案来替换当前论坛：

  • Movim 充满了小（无害的）错误，并且显然不打算用作论坛（维护者告诉我们不要尝试）
  • Salut-à-toi 尚未测试，但从理论上看更合适，并且维护者对我们使用他的项目表现出强烈兴趣；sàt 论坛目前仅在 Web 界面（libervia）或其他 sàt 前端（因此 www + Jabber/XMPP）上工作，但维护者已计划实施完整的电子邮件集成
  • 标准多用户聊天，带有用于只读日志的 Web 界面，并具有搜索功能；此解决方案效果不佳，因为没有主题/类别（信息发现很困难）

我们将在下次会议中启动 salut-à-toi 的测试实例，以便人们可以测试并为项目维护者收集反馈，他们非常希望得到真实世界的反馈。

计划下次会议

到目前为止，我们要求人们在论坛上投票选择会议日期。然而，这需要创建一个帐户才能投票，这使得一些人犹豫不决。我们可以使用像 framadate 这样的公共投票系统。这将在下次会议中进行尝试。

此外，到目前为止，会议前后的大部分工作都由一个人完成。这不需要太多时间（会议前 2 小时，会议后 2 小时），并且 certainly 不需要专业技能（有些拼写错误也可以）。理想情况下，会有更多人参与，这样就不会有人必须为每次会议都做这些工作。这位志愿者仍将准备下次会议，但将制作关于如何组织会议的教程，以便可以被任何人替代。

我们如何宣布下次会议？目前，同一个人或多或少地在许多与 Jabber 相关的 MUC 中发布我们的会议公告。有一些想法：

  • chat@joinjabber.org 和 meeting@joinjabber.org 频道主题已完成
  • 一个专门的 MUC 用于公告？（可能加入另一个频道会让人感到烦恼）待办
  • 来自 媒体工作组 的社交媒体账号已完成
  • 网站上的一个标题，就像我们为第一次会议所做的那样？已完成

会议应该在 chat@ 还是 meeting@ 举行？将讨论分成更小的频道是有意义的，但这也会分裂一个已经很小的社区。在 chat@joinjabber.org 中进行长时间的辩论可能对新来者并不友好，他们可能会因为信息过多而感到不知所措而离开。

我们应该邀请哪些集体和其他项目参加我们的会议？我们如何与他们联系？我们的信息是什么？我们可以设置一个投票，以获取更多客户端/服务器开发者和服务器运营商的反馈：

  • 他们是否希望收到有关 JoinJabber 项目的信息/邀请？
  • 他们希望在 JoinJabber 项目中看到什么？我们可以共同努力的方向是什么？
  • 他们是否希望在 JoinJabber 主页上被宣传？
  • 他们希望我们的集体如何介绍他们？他们代表什么样的用例？
  • 他们在隐私和安全方面做了什么，如果他们对此有任何担忧？有什么可以改进的？他们需要什么帮助？
  • 他们在翻译方面做了什么？有什么可以改进的？

tofu 和 eevvoor 将基于这些内容制定完整的提案，并在聊天室中提交公开审查。

问题解答

避免成为中心点？

问题： 我们如何避免成为生态系统中的中央基础设施？我们如何防止自己成为单点故障，尽管为许多项目提供服务？

答案： 目前，我们专注于仅提供信息，因此这个问题并不那么相关。然而，我们的目标声明我们应该为生态系统提供额外的服务（例如，翻译系统、软件仓库）。

对于特定服务（Weblate、论坛），我们应确保我们的基础设施本质上（尽实际可能）随时可分叉，方法是遵循我们的系统管理员配方。这应该已经是这种情况。此外，根据通用数据保护条例的规定，我们应该使用我们服务的任何成员/项目能够导出他们的数据并将其移动到新位置。最后，我们可能只接受为提供自己域名的项目托管服务，以便他们将来能保持自主性？

对于软件仓库，这是一个更加棘手的问题。如果我们的基础设施被入侵，我们不希望最终在我们的仓库中提供恶意软件。据我们所知，只有GNU guix可以通过以下方式缓解这个问题：

  • 通过通道引入对所有提交强制执行有效的 PGP 签名
  • 强制执行可重复构建，并使客户端能够挑战构建缓存以确保它们对已生成的构建达成一致

众筹

**问题：**我们是否计划积极参与 XMPP 服务器/客户端功能的众筹？

**答案：**是的，正如我们在上次会议中确定的目标。我们不会自己发起众筹活动，但可以宣传现有的活动。不过，目前我们尚未收到支持众筹活动的具体提案。

iOS 体验

**问题：**如何引导使用 iOS（具有不太方便使用的客户端）的用户？

**答案：**Siskin 或 Monal 真的有什么问题吗？iOS 客户端很差是不是只是一个过时的说法？请提供更具体的反馈。

自托管责任

**问题：**请让新（和老）用户清楚地了解自托管服务器意味着什么，以及作为管理员你承担的责任。关于运营者如何滥用权力的概述，请参见这篇文章

答案： 这对于提供给最终用户的任何服务或多或少都是如此。我们希望为运营商和最终用户提供更多关于此的信息，以及GDPR合规性。欢迎贡献。

捐赠

问题： 如何接受捐赠？

答案： 我们不接受金钱捐赠，但欢迎每个人捐献时间、精力和想法。您也可以向我们的主机Fosshost或我们推荐的任何上游项目和服务提供商捐赠金钱或设备。

科学工作组

问题： 建议考虑 Jabber/XMPP 作为科学家的平台，并在我们的网站上为此设置专门的用例。

答案： 可以在science@joinjabber.org聊天室成立一个科学工作组，并在下次会议中进一步讨论更具体的提案。

学校工作组

问题： 可以成立一个学校工作组，以推广远程学习和视频会议解决方案，如 Jitsi。

答案： 会议中没有人愿意开始这项工作，但有些人会很乐意欢迎新的贡献者，并可能在未来参与。关于这个问题，德语版指南已经存在。我们可以邀请其作者加入我们的讨论。

基于 XMPP 的多用户协作

不完全是一个问题，但提到了一些用于 Jabber/XMPP 多用户合作的项目：

  • salut-à-toi用于论坛和联邦软件锻造
  • saros用于最多 5 人的实时编码
  • jsXC提供 Nextcloud/Sogo 集成以共享文件等

如果有人想在我们的网站上提及这些用例，同时警告最终用户这些是小众且可能存在漏洞的，欢迎贡献。

推迟

推荐服务器

我们目前在主页上推荐一些服务提供商，但是包含的标准并不清晰。我们显然可以添加更多提供商，但也有人担心某些提供商可能使用谷歌臭名昭著的、对用户不友好的 RECAPTCHA，或同样臭名昭著的 Cloudflare。我们在上次会议中提到，希望建立更客观的标准来决定是否推荐一个服务器。

根据用户的预期使用场景，可能会应用不同的标准：

  • 非营利性：服务提供商是非营利性协会或工作者合作社
  • 无第三方：服务提供商设置的面向用户的服务不包括对第三方资源/调用，如分析、验证码或内容分发网络
  • 巴士因子：服务由一人或多人提供，并设有保障措施，以防一名系统管理员无法继续为项目做出贡献
  • 可持续性：经济模型可理解，并对运营成本和捐款透明
  • 隐私：隐私政策对用户来说是可理解的，并且在我们看来是合理的（存在解释空间）

首先，我们应该决定要支持哪些使用场景，然后再决定适用于任何场景的具体标准：

  • 个人：面向朋友和家人，具有合理的隐私性，但更倾向于可持续性（服务在 10 年后仍然存在）
  • 集体：面向集体和合作社，自带域名并管理自己的虚拟主机，更倾向于可持续性和可靠性；另外，对于此使用场景，我们可能会考虑提供官方账单/报价作为要求
  • 匿名：面向活动家，更重视安全性而非持久性；这个使用场景可能需要重命名（例如"活动家友好"）

已经存在一些列表来引用 Jabber/XMPP 服务提供商：

此外，一些程序可以基于编程测试来发现/评估服务：

通讯

自由许可证

在我们的第二次会议中，有人指出我们的网站还没有许可证。我们所有的生产绝对应该采用版权共享。

加入 Jabber 还是加入 XMPP？

  • Jabber 是思科的商标，通常与 2010 年前的旧 XMPP 相关，或者更糟的是，一些思科公司内部聊天工具被抛弃给 Slack
  • XMPP 在与技术人员将其与过去糟糕的“Jabber”体验联系起来的斗争中面临艰巨的挑战。因此，现代 XMPP 应尽可能与旧 Jabber 保持距离
  • joinjabber.org 应该重定向到 joinxmpp.org，而不是现在的相反情况
  • joinxmpp.org 对于解释现代 XMPP 及其客户端来说是可以的，实际的最终用户采用是由客户端和服务器推荐驱动的，而不太依赖于协议本身
  • 人们说 Jabber 比 XMPP 更容易记住和发音