社区无界限：Discourse-as-a-Fabric - 构思与头脑风暴

社区
1

在 ActivityPub 支持：第一阶段 RFC 中，我概述了一项构思练习，旨在评估在 Discourse 中引入 ActivityPub 支持的商业案例，并超越最小可行产品（MVP）的局限，设想如果 Discourse 从一开始就是基于联邦理念构建的会是什么样子：

因此，我将在此启动构思过程，进行一些头脑风暴，暂不考虑当前代码库的技术现实性。我意识到这其中存在许多细节和边缘情况。这是对原生联邦支持可能呈现样貌的一种愿景。让我们开始……

社区无边界

pexels-pixabay-262488
pexels-pixabay-2624883648×2736 924 KB

(照片来源：Pixabay，来自 Pexels)

我们共同生活在一个星球上；) 在复杂的社会结构中交织。为什么 Discourse 社区要局限于单个论坛？

我是 Humane Tech Community (HTC) 的管理员，我们涵盖了广泛的技术相关主题领域，设有「自由 > 隐私」、「对齐 > 伦理」、「对齐 > 标准」等（子）类别。也许范围太广了，确实存在许多其他专门针对这些类别的 Discourse 论坛，并在该领域做得比我们更好。但对于想要了解_整个_人道技术领域概况的人来说，这种广泛的定位是有意义的。

联邦化类别

如果我能将我们的「隐私」子类别与例如 PrivacyTools 论坛的「博客文章」子类别进行联邦化呢？也许仅单向同步主题——因为 HTC 的隐私子类别范围更广——即 PrivacyTools 上创建的主题会出现在 HTC 论坛上，我们的成员可以与之互动。HTC 论坛上的主题帖子随后会传回 PrivacyTools 的对应主题，反之亦然。两个论坛上的主题将保持同步。甚至可能希望将多个 PrivacyTools 子类别单向同步到 HTC 的「隐私」类别中。为什么不以类似方式与其他隐私相关的社区进行同步呢？

另一个例子。Feneas 和 SocialHub 都拥有一个顶层的「ActivityPub」类别。这些类别之间存在重叠和重复，一个社区的成员可能 unaware 另一个社区正在发生的事情。这是一个机遇，「ActivityPub」可作为双向同步的候选对象，使得每个论坛都包含相同的主题列表。

联邦化标签和单个主题

同样的逻辑也适用于标签，即特定标签可配置为进行联邦化。例如，可以设置使得 SocialHub 中带有 #specification 标签的任何主题都联邦化到 HTC 的「对齐 > 标准」子类别中。

主题也可以按个案进行联邦化，通过工具栏命令触发，指定要联邦化的目标论坛，并可能选择主题应出现的远程类别（即论坛类别列表也可用于远程浏览的联邦化）。

成员提及和个人资料查看

当主题被联邦化到另一个论坛时，其中的任何提及都需要调整以反映成员所在的论坛。我在 HTC 的 @aschrijver 用户名在同步后可能在 SocialHub 论坛上显示为 @aschrijver@humanetech。

由于我也是 SocialHub 的用户，我可以在个人资料设置中连接账户，经过验证后，这意味着在同步的主题中，我的本地账户用户名可以被显示。

点击远程用户名或成员头像时，将显示远程论坛的个人资料卡片。再次点击查看个人资料摘要时，它可能仅显示由同步主题互动产生的本地论坛活动指标。或者，更有趣的是，它可以显示所有已知且属于联邦配置论坛的摘要。例如，我将能够发现回复来自另一个论坛中一位非常活跃且专业的成员。

直接消息和通知

通过标记/提及远程成员，DM 可以在所有联邦化论坛之间进行，而不仅限于本地。除此之外，DM 通信的方式与当前仅本地的 DM 没有区别。

从上述所有联邦功能中衍生出对联邦化通知的需求。如果我回复了远程成员的帖子、点赞了他们的帖子，或在同步的主题线程中提及了他们，远程论坛的 UI 可能会出现通知以告知该成员。电子邮件通知也由远程论坛处理。然而，如果该成员在两个论坛上都链接了账户，通知可能会来自首次发生互动的本地论坛。

单点登录 (SSO)

请注意，在上述所有功能中，并不需要 SSO。远程成员不会自动获得对另一个联邦化论坛的特权访问。那么，如果他们在单向同步的主题线程中被提及呢？在这种情况下，他们将收到来自其自身论坛实例的 UI 通知和电子邮件，点击后会被引导至另一个论坛（可能在新浏览器标签页中），在那里他们可以查看主题。如果他们想要回复，则必须先注册并链接账户才能进行回复。

请注意，SSO 在 Fediverse 中是一个棘手的问题，目前尚无完善的解决方案。但对于 Discourse 到 Discourse 的联邦化，SSO 功能的实现可能会容易得多。如果存在 SSO 集成，那么点击通知可能会在当前论坛的上下文中打开主题（作为「远程视图」），并允许成员无缝地与其互动。

联邦化管理与复杂性

整个用例的描述都是基于 Discourse 从一开始就内置了联邦支持的前提。如果实现所有这些功能，它将触及产品的几乎所有特性。与开启此线程的用例——用于类似 FB 的 个性化信息流——不同，这里的联邦化是由论坛工作人员精心管理的，而不是个别成员的一时兴起。

大部分联邦配置是仅限管理员的操作。它应该具有战略性并经过良好规划，以保持社区组织和内容的直观性和逻辑性。联邦设置是作为社区建设工作流程的一部分逐步建立的，而不是随意添加的东西。

互操作性

当然，这种 ActivityPub 支持的愿景并不局限于 Discourse。任何兼容的软件项目都可以成为分布式社区网络的一部分。例如，forem 的开源社区建设软件和 loomio 的协作决策平台，我刚刚将这两个项目指向了这篇帖子。但 Discourse 拥有引领这一切的机遇。

Fediverse 集成

迄今为止，所有的联邦支持都局限于论坛/社区业务领域，但随着 ActivityPub 的集成，互操作性现在可以扩展到拥抱更广泛的 Fediverse，从而实现众多令人兴奋的商业案例。仅列举一些随机浮现在我脑海中的例子：

  • 在 Mastodon / Pleroma 等微博客平台上通过 toots 向整个 Fediverse 宣布论坛帖子。
  • 嵌入的图片会自动上传到 PixelFed 并从那里提供（例如对 Blender 社区很有用）。
  • 日期/时间工具栏允许设置一个面向 Fediverse 的完整 Mobilizon 活动，具备完整的 RSVP 功能。
    • 集成是双向的，其中活动上的 Mobilizon 讨论实际上是 Discourse 主题。
  • 创建具有特殊视频功能的 PeerTube 主题，其中帖子是 PeerTube 上的评论线程。
    • 如果 Owncast 添加 AP 支持（参见此 问题），情况也相同。
  • 您发布的主题自动成为 Writefreely 博客帖子及评论线程。
  • 通过其 ActivityPub 支持，将论坛的部分内容作为应用嵌入到 Nextcloud 中。
  • 通过 Funkwhale 集成播客功能（参见最近的关于播客支持的 视频）。
  • 从 Flockingbird（正在开发中的专业社交网络，类似 LinkedIn 的名录）获取个人资料信息。

看看 ActivityPub 观察列表 上不断增长的应用数量，让您的想象力引导您吧 :smiley:

后果

暂时忘记所有的技术障碍和困难，考虑一下这对 Discourse 作为一个产品意味着什么。或者更准确地说，Discourse 不再仅仅是「一个产品」：Discourse 已成为分布式社区网络。

论坛工作人员不再仅仅是工作人员。他们将采用更广阔的视角来进行社区建设。社区及其内容都存在于整个 Discourse 网络中。工作人员将积极关注其他 Discourse 实例，与它们的工作人员接触以建立合作伙伴关系，并创建有趣的联邦设计，以切割和重组其社区组织和内容，使其对社区成员基础最具吸引力。

社区成员本身也将得到更好的服务。更多有趣的内容将流向他们的论坛「门户」，论坛将比仅仅是一个本地事物更加活跃。社区成员将能够发现并与整个网络中其他论坛实例的成员进行互动。事实上，社区边界已被消除：社区无边界。

17 个赞
Humanetech category layout
Forum owners, how do you "fight" Facebook groups?
ActivityPub Support: Phase 1 RFC
Using Discourse as a social media platform
Federation support for Discourse
ActivityPub Support: Phase 1 RFC
ActivityPub Support: Phase 1 RFC
2

公平地说，我只是粗略地浏览了一下，不过：你打算用这个面料创意解决什么问题？

2 个赞
3

首先，我在头脑风暴的输入中描绘了大量不受限制的可能性。但就我个人而言，我希望在两个方面看到改进：一是作为普通社区成员，二是作为社区协调员（目前我在 5 个论坛担任工作人员，偶尔会进行跨论坛发帖）：

  • 作为社区成员，我现在在 15 到 20 个 Discourse 论坛上拥有账号，需要不断切换这些账号（其中一些甚至已被遗忘）并管理密码，还要以类似轮播的方式逐个网站查看热门内容。由于我的兴趣所在，这些论坛的内容领域往往存在大量重叠。现在，即使你邀请我加入你在我最喜爱主题上的优秀论坛，我仍然会非常犹豫，不愿再创建一个新的账号。

  • 作为社区协调员，我也面临类似且相关的问题。我的社区可能规模较小，而你可能会选择加入另一个在相似或部分重叠主题上拥有内容的社区。或者情况恰恰相反。甚至你可能根本不知道那个优秀社区的存在（也许我作为社区协调员知道它的存在，但我是否会专门发布一个置顶主题来告知我的成员呢？）。

一旦联邦支持到位，社区协调员之间就可以通过建立合作伙伴关系实现双赢，为各自连续的受众群体精心规划论坛组织结构，并从彼此的优势中获益。具体来说，这将包括：

  • 能够选择最合适的来源进行联邦连接，从而提供更高质量的内容。
  • 拥有更大的成员基础——即整个联邦的聚合体——从而有更多人与之进行有趣的讨论。
  • 提高所有参与联邦的论坛实例的活跃程度，有助于留住经常访问的用户。

这三个方面——质量、数量和活跃度——是任何成功社区的关键 :slight_smile:

8 个赞
ActivityPub Support: Phase 1 RFC
5

我同意，这确实是个麻烦。我通过添加 Discourse 社区的 RSS 订阅源，并启用内置的每周摘要邮件来解决这个问题。

5 个赞
6

我最近刚读完尼尔·弗格森的《广场与高塔》，该书探讨了社交网络（个体之间隐秘且非正式的社交联系）在世界历史中的影响。这本书远非完美，但它始终强化了你的观点：“社区没有边界”。分布式网络比等级制度更具韧性、创新性和平等性。Discourse 将自己描述为“从零开始的重新构想，旨在重新定义现代互联网讨论论坛在当今世界应有的模样——在一个智能手机、平板电脑、Facebook 和 Twitter 无处不在的时代。”除非 Discourse 的雄心壮志仅仅是成为一时最顶尖的论坛软件，否则集成 ActivityPub 无疑是严肃挑战 Facebook、Google、Twitter 等巨头，并颠覆人们对在线社区所能达到高度的预期的明确路径。

8 个赞
7

@aschrijver 没问题，我个人非常赞同这些想法和思路。

这看起来相当“容易”实现。关于账户部分，你可以使用一个主 Discourse 实例作为 SSO 提供商。其他 Discourse 论坛只需加入该系统即可构建统一的用户基础：你的用户名在整个使用该系统的 Discourse 实例中都是为你预留的。理想情况下，论坛管理员/所有者应在创建论坛时加入。当然，之后加入也是可能的，只是届时需要解决所有重复用户名的问题：管理员必须让那些用户名在系统中已被占用的用户更改用户名。

关于合作部分，利用 Matterbridge 和/或 Discourse API 的插件应该能够实现所有功能。这里只需要进行一些插件的开发和完善工作。

或者，针对新论坛，可以采用“多站点”方案：在一个主 Discourse（可以是上述 SSO 提供商的同一个实例）上创建分类，一个分类即代表一个“论坛”。通过调整一些设置，你可以将用户“锁定”在特定分类内，移除对主“分类”的提及，并将其重新定义为不同的“论坛”。通过启用子分类，每个论坛仍保留两级分类结构。虽然还有一些调整工作需要做，但这能直接实现统一的用户基础以及站内私信互通（因为你们都在同一个 Discourse 上！）。

你可以结合这两种方案：将部分论坛托管在主 Discourse 上，同时让外部论坛链接到它。我认为将你的愿景变为现实相当容易。如果有兴趣，我可能愿意参与这项工作（不过我需要一些帮助）。我已经注册了域名 webforum.link，可用于此项目。

附注（在看到之前的帖子后）：ActivityPub 是“开放”的。而上述想法则更为“封闭”，仅限于 Discourse 论坛。此外，加入的难度也会更大。

3 个赞
8

@aschrijver，继我们在 ActivityPub Support: Phase 1 RFC - #50 by Mevo 上的帖子交流之后，我也想在这里继续探讨这个问题（这是一个更合适的主题）：

最近我发现了一件非常有趣的事情：一些人创建了一个名为 Openbazaar 的免费去中心化市场。其基本理念是打造一个完全开放的平台，任何人都可以上架任何商品进行销售，且不存在任何限制或审查的可能性。它基于加密货币进行支付，并提供对卖家的评价功能，同时设有调解员系统，用于仲裁可能出现问题或纠纷的交易。交易本身完全不收取任何费用，整个平台 100% 免费（仅在调解员需要介入的情况下，才会收取少量调解费用）。

从纸面上看，我认为这个构想非常棒。然而，它却从未真正普及开来。另一方面，像 eBay 或 Amazon 这样对每笔交易收取相当高费用的平台，却运营得非常好。

关键在于，拥有一个能够控制某项事务、有动力使其成功（因为他们能从中获得经济利益），并愿意为此目标投入资源的人或组织，通常比那些免费、开放且崇高的理念更容易取得成功。这或许令人遗憾，但在现实中，这似乎就是普遍发生的情况。

Mastodon 是否取代了 Facebook 和 Twitter？未来会吗？用户似乎并没有对 Facebook 上铺天盖地的广告感到厌倦。

无论如何，在我看来，你在关于联邦化（federation）的观点中似乎没有考虑到这一方面。因此，我想提出这一点供你参考（或至少让你了解）。这并不意味着支持联邦化功能或建立合作伙伴关系不是一个好主意。但追求“完全联邦化”也可能削弱运营软件的吸引力，因为它最终仅仅变成一个“节点”，而不再是你能够掌控的东西。至少在某种程度上，这两者截然不同。

1 个赞
9

平台的使用增长并非线性。以 Signal 为例：斯诺登曾说“使用 Silent 或 Signal”，该应用随之发展，但长期仍属于小众。而当 Gafam 发布不当信息，且埃隆·马斯克表示“使用 Signal”时，数十万用户随即涌入，因为他们同时依据相同标准进行了评估，而该应用恰好满足了他们的需求。

近期，一些用户可能已悄然离开 Twitter 和 Facebook，鲜有媒体报道，原因是他们信息流中主要的互动来源账号已被删除。

社交媒体系统越趋向混乱，用户同步进行大规模“卸载应用 A、安装应用 B"的可能性就越高。

1 个赞
10

我不确定 Signal 的例子是否真的具有可比性。在这里，有一个明确的新增功能，以及人们使用它的理由：“使用加密通信，确保你的言论保持私密，无人能窃听”。这相当于从非加密转向加密。

但当从一个“封闭”且“孤立”的平台转向一个“开放”平台时，如果我们考虑“完全联邦化”，它是否真的为用户带来了什么？是否真的为他们增加了功能？有些人可能会说是的，因为他们看到自己参与多个社区，而联邦化可以聚合这些体验（我理解登录多个不同社区是多么繁琐）。但与此同时，如果所有用户都迁移到一个“封闭”的社区并使其占据主导地位，对他们来说结果也几乎相同。我不确定他们是否会察觉差异，或者是否真的想要“开放性”。

人们关心的是内容、互动等，但技术如何运作以及由谁控制，对他们来说真的重要吗？转向“联邦化”在某种程度上是社区从“竞争”转向“共享”的过程。它们彼此可能是朋友，也乐意将用户从一个社区引导到另一个，但在封闭状态下，它们仍然相互竞争。

你的第二点很有趣：某些“联邦化”能否防止封禁、账号删除和审查？这可能才是对用户而言真正新增的“功能”。目前在使用 ActivityPub 时，我猜你可能会被单个站点封禁，但只要你注册的站点没有封禁你，你就可以继续向联邦中的其他站点发帖……@aschrijver，你知道这具体是如何运作的吗？（我对 ActivityPub 还不够了解）。你是注册在某个联邦层级，还是注册在联邦中的某个具体站点？能否在联邦层面被封禁？还是说这根本不可能？（按理说应该是不可能的吧？）

@jibe-b 这个问题并不是关于从应用1迁移到应用2，而是将各个封闭的应用与联邦化的（开放的）系统进行对比。同样，也可以存在具有强烈言论自由政策且不封禁用户的封闭独立应用（事后诸葛亮很容易，但“反应提供商”本应预见这一点）。你可以通过彻底去中心化并移除任何人的封禁能力，来保证一个无封禁的环境。不过，我认为防止审查并不是 @aschrijver 的初衷。

1 个赞
11

（为简洁起见，我引用了片段）。这里的餐厅类比其实不太成立。这就像你同时坐在两张桌子旁，并且身处一个更大的“聚合”餐厅，有更多人与你一同庆祝。你所说的可能是对的，但这完全取决于具体的实现方式。

虽然 ActivityPub RFC 主题 和 @hellekin 的 用例 将完全控制权交给了个人，但在上述我的描述中，社区结构完全掌握在社区工作人员手中。他们与其他社区建立合作伙伴关系，并且可能只能在双方同意的基础上分享社区的某些部分。

我认为这样做更符合 Discourse（公司）以及那些投入巨大精力打造自身身份和会员基础的社区管理者的利益。也就是说，这更像是一个 商业案例。因此，工作人员仍将拥有完全控制权，并负责确保社区组织的构成全面且直观。他们是“社区结构的编辑者”。

如果你允许 Discourse 用户完全自由地用来自各处的论坛内容填充他们空白的“门户”，那么你将得到一种完全不同的社区动态。该用例在特定情况下具有价值，但它与“工作人员保持控制”的用例完全不同。当然，介于两者之间的各种灰色地带也是可能的。

是的，我知道它们，我也热爱 OpenBazaar 作为去中心化市场 的理念，但阻止我去尝试它的是加密货币。这是一个信任问题。对许多人来说，这可能也是阻碍他们的原因。但除此之外，是既得 Big Tech 巨大的网络效应使得新进入者很难立足，他们推出新服务，在拥有数百万日活跃用户的网站上进行广告推广，并能够在事情最终兴起之前承受巨额亏损运营。

是的，我同意这一点。这就是为什么我没有聚焦于“完全自由”，而是如上所述聚焦于“工作人员控制”的用例。在此模式下，ActivityPub 支持为 Discourse 作为社区管理者的产品增加了一个独特的卖点（USP），即付费客户。嗯……如果他们选择云托管订阅的话。

在这方面，Discourse（公司）可以通过提供增值服务来使订阅更具吸引力，例如提供发现和配对服务，让不同社区的社区管理者积极寻找合作伙伴关系和协作，以丰富他们（并隐含地丰富彼此）的社区。该服务可供任何人访问，或仅限付费计划客户访问。

它们应该想这么做吗？为什么这应该是目标？作为协议的 ActivityPub 允许 许多不同领域 的 许多不同应用 在任何层级上互操作。每个项目/应用/产品都将追求自己的目标，对于商业软件而言，则是其自身的独特卖点（USP）。

第一部分很重要。明智地选择你的联邦化方式。如果这样做会让你失去作为产品的所有身份，那么完全联邦化 绝不应 成为目标。

首先，“联邦化”与“联邦宇宙”（the fediverse）是有区别的。如果你使用 ActivityPub 构建联邦化，你可以按任何你想要的方式构建它。如果你构建的目标是集成到联邦宇宙中，那么存在一些既定事实标准来规范运作方式。在用户层面进行全联邦范围的封禁是不可能的，而对特定实例的封禁是基于每个其他实例管理员的决定，并配置在黑名单和白名单中。这些列表通常会被共享（类似于广告拦截器列表），并可能导致某些实例在整个联邦宇宙中被完全封禁（“它们被推到了联邦宇宙的边缘”）。

一个解释该概念的优秀视频是：

就像论坛一样，联邦宇宙中的每个联邦实例都是经过管理的。我认为这是一件好事。仍然拥有完全的自由，因为你可以启动自己的论坛/服务器实例而不进行管理，让一切随意发生。其他人也有基于此原因封禁你的自由。

4 个赞
12

委托社区管理

因为这是一个大胆的头脑风暴，而且我刚刚看到了这个主题 招募志愿者社区管理员 :mega: …… 我就在想：

—> 如果社区管理是联邦化的会怎样？

假设你是一位刚上任的社区管理员，管理着一个新安装的 Discourse 论坛，对管理界面和社区建设实践完全陌生。如果你能在一段时间内邀请一位经验丰富的社区管理员来为你提供建议并指导你，会怎么样？

我知道你们可能会说：“为什么不直接在那个论坛上创建一个管理员账户……根本不需要联邦化！”你说得对。但让我们换个角度，让这件事更有趣一些：如果我想以志愿者或专业人士（即付费）的身份提供我的 Discourse 和社区管理技能呢？

我希望能够在我的“客户组合”中尽可能高效地管理多个社区。这将实现三赢：

  • 新的社区管理员可以获得入职服务，更快地上手。
  • 社区管理员可以更广泛地发挥其技能，不仅仅局限于自己的社区。
  • 以上两点意味着 Discourse 为其产品增加了另一个独特的卖点（USP）。

那么这会是什么样子的呢？我不确定……有很多可能性。以下是一些建议，在每种方案中，被委托的管理员都通过联邦机制从他们自己的论坛门户进行操作，可能同时管理多个社区：

  • 被委托的管理员可以设置论坛设置、安装插件/组件/CSS，但需经真实管理员批准后才能生效。
  • 被委托的管理员可以访问仅限员工的分类和群组，并参与讨论以提供建议。
  • 被委托的管理员处理论坛中提交的举报，只有包含举报的主题会被联邦化并同步到他们的门户。
  • 被委托的管理员了解社区生态，可以帮助安排与其他社区的合作，并促进内容共享。

请结合上文考虑以下观点：

这也可能是一项增值服务，可以与上述内容结合。所有相关方都有兴趣确保被委托的管理员在某种程度上经过筛选，成为优秀的社区管理员。Discourse（公司）可能只允许处于（付费？）订阅状态的用户成为被委托的管理员。Discourse 或其合作伙伴可以提供社区管理课程，通过该课程后将获得由 @codinghorror 认证的批准证书。

好吧……无论你是否喜欢这个想法，对我来说这都是一次不错的头脑风暴，哈哈 :grinning_face_with_smiling_eyes:
也许你能让它变得更好？

编辑：

Discourse 本身也会使用这项服务。在我们开始付费订阅时，Discourse 团队的一名成员曾作为我们论坛员工的一部分，提供类似的帮助。有了这项功能，他们可以从自己的远程“驾驶舱”完成这项工作，或者……将其委托出去。

另一件涉及社区部分共享的事情：有几次当我在 Meta 上发帖寻求特定帮助时，该主题会被设为私密（有时是因为包含敏感信息），并由 Discourse 团队作为“支持工单”处理。通过联邦化，我或许可以将 Meta 的支持部分集成到我自己的论坛中。

4 个赞
13

（此处的格式由我调整）。我非常喜欢 @JE-FF 的这个定义，它完美契合了“社区无边界”和“论坛即织网”这些创新理念所应采取的方法。不过，正如我也曾向 @Mevo 提到的，我怀疑 Discourse 是否真的想要挑战科技巨头的社交媒体。如果他们愿意，当然可以，但似乎并无必要。Discourse 本身已经相当成功，且其定位如今已有所不同，即作为多租户 SaaS 服务，一个“独立社区论坛的云端”。不过，通过将社区概念延伸至租户边界之外，他们或许能更好地在与论坛及社交媒体领域竞争对手的较量中占据有利位置。

2 个赞
14

非常感谢，@aschrijver。你的表述非常清晰，老实说，我几乎完全同意你所说的所有内容。我之前撰写消息时，心中有一个想法，认为你提出的方案只是一个“垫脚石”，而“完全（且完全开放）的联邦”才是最终目标。现在，我甚至不确定这个想法从何而来，你甚至可能从未说过类似的话。这可能是我个人的误解（甚至是凭空想象），或者是我把其他人说过的话搞混了。

ActivityPub 所能允许的一切，同时你仍然可以自主选择行事方式——是的，这一切听起来都太棒了。 我想你说得对，人们可能会在 ActivityPub 和联邦宇宙之间产生混淆（你已经在另一个主题中解释过这一点）。

就我个人而言，我非常喜欢你提出的所有想法。在联邦式的“社区管理”方面，能够以这种方式访问版主也会非常有用。例如，当你的社区热度上升，或遇到需要更多版主处理的特殊活动时，你可以临时启用这些版主（所有这些可能在你心中已包含在“社区管理”的概念中。你确实提到了“标记”功能，但你同样可以访问更多“管理员”类型的人员，而不仅仅是“版主”或“社区管理者”，如果你将这些任务视为不同的职能的话）。

正如之前所说，所有这些都可以“通过插件和/或独立站点”在侧面实现（可以有一个“自由职业者”独立站点，列出并提供服务，让人员直接入驻社区工作。虽然不如拥有一个专属平台那样理想——该平台可通过 ActivityPub 实现远程管理和聚合——但这已经是一个很好的开端）。

这一切都取决于 Discourse 团队是否愿意采纳其中一些想法，并直接在 Discourse 中实现它们。

4 个赞
15

我对此持不同意见。我一直利用多站点设置来促进对 Discourse 实例的群组所有权，使一个紧密的群体能够成为其自身的“工作人员”，同时与更大的社区保持直接联系。在我看来，通过运用辅助性原则（即决策应尽可能贴近实践层面来制定），调整社区边界能够赋予社区力量。

16

首先，你似乎将他所说的话解读为“如果没有某种‘工作人员管控’，用户就会行为不端”，但在我看来，他并非此意。其次，他只提到了“完全不同的社区动态”，并未对此做出好坏的评判。你实际上通过称其为好事而表示赞同（它仍然是“不同”的）。

但这并不是讨论的焦点。讨论并非关于这种“管控”，也不是针对用户有任何问题。

17

是的，这主要在于展示选项范围的广泛性，以及针对特定场景进行灵活调整的自由度。如果我只关注 ActivityPub 这一核心，它能让联邦功能的实施者完全掌控“球权”。已实现的用例都是同样有效的（前提是它们是在产品开发过程中经过深思熟虑而设计的）。

我注意到 @hellekin 的情况确实处于自由度较低的一端，值得进一步探讨。@hellekin 比我同时管理着更多的论坛，而且方式颇具创意，这一点在 SocialHub 论坛上可见一斑，各个 ActivityPub 软件团队可以掌控论坛中属于自己的板块。这些团队通常还拥有另一个独立的论坛（例如 Mastodon 的情况）。我们应当鼓励他们进行“双重工作”，以便让 AP 社区了解他们自行开发的软件中所嵌入的自定义联邦扩展。此外，SocialHub 还拥有一些可被视为卫星论坛的附属论坛。

3 个赞
18

我刚刚决定再注册一个 Discourse 论坛，只为帮助他们，并（复制/粘贴）一些来自其他论坛的有用话题链接。这又增加了一个需要管理的 Discourse 用户账户。

该论坛是 Fedeproxy，这是一个新的 ActivityPub 项目，旨在同步代码托管平台（如 Github、Gitlab、Gitea 等仓库）。它可能会成为 Forgefed 协议的一种实现，在此提及它有两个原因：

  1. 这又是一个完全不同的业务领域可以极大受益于 ActivityPub 联邦制的例子。
  2. 如果 Discourse 支持联邦制，该论坛的 #development 分类就可以与 SocialHub 的 #software 子分类进行双向同步，而无需在两个论坛上工作并重复讨论。

更新：

在 Fedeproxy 论坛上，一位用户（顺便提一下，他并不想在这里注册，只是为了发一条帖子）指向了一个有趣的链接数据本体，用于社区，即 SIOC 核心本体规范，其中 SIOC 项目 代表“语义互联在线社区”。该本体在链接数据中定义了以下语义：


semantically-interlinked-online-community-ontology
semantically-interlinked-online-community-ontology600×379 30.1 KB

在此提及，因为它突出了业务领域/词汇表的思维方式，并可以激发头脑风暴 :slight_smile:

（附注：不要被 SIOC 规范中的“语义网”一词误导。这与那无关——过于复杂——而是寻求封闭的链接数据词汇表来定义特定领域。）

更新 2：

我今天发现了一个很棒的项目，其领域与 Discourse 类似，并在那里发起了“社区无边界”的讨论：

PubPub 是 Knowledge Futures Group 的一部分，他们也在开发开放分布式知识图谱项目 Underlay（这接近于我关于从 Discourse 论坛聚合知识的想法 https://codeberg.org/innercircles/seedvault/issues/1）。

更新 3：

我意识到关于社区的讨论比 Discourse 本身要广泛得多，因为社区概念在我们社会中是如此普遍。对于 Fediverse，我发起了一场关于标准化社区领域并据此建模 ActivityPub 扩展的讨论：

7 个赞
19

ActivityPub 是个好主意，但即使是刚推出、将其作为核心功能实现的软件，也不得不修复规范中的不少漏洞——因此对我们来说，先观望一下是更明智的选择。

此外，如果某个特定群体对此充满热情，那么将其作为一个插件来实现也完全可行。

13 个赞
20

如果能看到这样的集成以拉取请求（PR）的形式合并到 chat-integration 应用中，那就太棒了。这样，在添加凭据后，我们只需通过标签、分类或提及即可轻松进行跨平台发布。干杯！

7 个赞
21

感谢 @codinghorror。是的，ActivityPub 规范中确实存在一些空白。但这些空白在很大程度上是有意为之的：一方面，规范制定者不希望创建一个包罗万象、庞大且复杂的技术标准；另一方面，在撰写规范时，他们也无法预知规范将如何演进。因此，他们选择等待参考实现的出现（这也带来了一些弊端，例如 Mastodon 使用了自定义的客户端 API，而非规范中的“客户端到服务器”部分，但 Mastodon 也定义了一些实用的 命名空间扩展 供使用）。

目前，这些空白大多已被其他开放标准填补（尽管仍有一些待完善之处）。例如，服务器到服务器的联邦通信使用 HTTP 签名（较少使用的情况则使用 JSON-LD 签名），联邦用户提及则使用 Webfinger。客户端到服务器通信采用 OAuth2 客户端凭证模式，而服务器能力通信则存在事实上的 NodeInfo / NodeInfo2 规范。

我同意，本线程中讨论的许多内容（可能占大多数）可以通过插件和 Discourse 强大的 API 来实现。正如 @sunjam 所说，如果有人愿意在此领域进行探索，那确实会非常棒：slight_smile:

基于这次头脑风暴，我在 SocialHub 论坛上发起了一些更广泛的讨论，特此推荐：

更新 2021/03/07：在 SocialHub 关于创建社区词汇表 AP 扩展的主题中，我进一步阐述了 Discourse 如何融入社区模型。请查看我的帖子：

7 个赞