Discourse 的实例有很多。我不确定确切数量，但我自己在几十个实例上都有账号。很难追踪所有内容，而且我经常在不同的、但并非截然不同的社区中遇到讨论相似议题的主题。由于部分参与者在不同讨论中反复出现，这些议题本可以在各个实例间共享。如果能够跨实例共享此类主题，而无需多次登录、交叉引用主题，并能与相关方进行流畅的讨论，那将大有裨益。
将 ActivityPub 用户视为“临时用户”（staged users），就像处理来自 Discourse 实例外部的外部邮箱用户一样，似乎是一个不错的起步折中方案。
RSS 订阅源当然有助于你在一个地方追踪正在进行的主题，但它无法带来比 Discourse Hub 应用不同的功能，也无法让你参与其中。
@hellekin 这一点我拿不准。也许你说得对，也许不对。
世界上有大量的夜店、餐厅、超市、软件等等。有些在地理位置上，或者在所提供的服务方面，甚至非常接近。难道我们应该认为，不同地方提供相同的事物却被分开是“愚蠢”的吗？这些场所是否应该合并，只保留一个中心化的？
不过，这里的情况稍微复杂一些：社区虽然仍保持某种程度的分离，但它们之间是相互关联的。问题在于，所有社区是否真的“相同”：规则是否一致？氛围是否相同？人群类型是否类似？等等。或许正是这些特质让一个社区成为值得（积极）参与的“特殊之地”：它的独特性。它拥有独特的氛围、独特的幽默感，等等。一种独特的身份认同。其中，人是至关重要的因素：谁会来这里或去那里，是什么样的人。
这或许可以看作是对“多样性”的一种观点：将一切混合在一起，最终导致到处都变得“一样”，因为混合得太彻底了。
另一方面，我们有“链接”和“引用”。没有人阻止任何人去链接、引用或总结其他地方发生的事情。在这种情况下，你可以保留每个地方的独特身份，而不会让一切都变得“千篇一律”。
无论如何，这或许是 ActivityPub 原则本身背后的核心问题，也是将其与 Discourse 集成的意愿所在。当然，如果这只是可选功能，那么任何人都可以按自己的意愿行事。而选项本身通常是一件好事，就我个人而言（我其实不太确定，一个成功的社区为什么会希望其内容被外部共享，并希望外部人员能够与其互动）。
[这有点像《未来水世界》里的情节，最后只剩下塔可贝尔餐厅了，对吧？]
我不太确定你的观点与我之前的帖子有何关联。我并未提及合并社区，只是提到一些共同话题。即便在那时，我也只是建议用户账号可以作为一种代理……
这不正是在“合并”不同社区的 offerings 吗？即使如上一条消息中所说：
Discourse 团队似乎不太愿意这样做，而且其优势/用例也不够明确。如果您看不出我之前的帖子与主题有何关联，那也没关系。抱歉，请忽略它。
绝对不应该。但我还是希望能在本地报纸上看到关于它们的报道，或者在更专业的情况下，在意大利美食鉴赏指南中读到相关内容。事物并非千篇一律，正是这一点让订阅它们变得有价值。回到网络和社区，链接和引用当然很有价值。但它们属于另一种用例，不同于在论坛之间共享话题并在上下文中查看帖子，甚至直接参与讨论。
你说得对，在某些情况下，你不希望混合身份，更不应该将分散的社区完全合并。但你可以根据实际情况，选择性地合并那些有意义的部分。无论是按主题逐一合并、合并特定的（子）分类、标签，还是合并特定的人群以共享内容。
这其实并不完全关乎 ActivityPub。该协议非常底层，构建在 HTTP 之上。你可以用它构建任何东西。很多时候，当人们提到 ActivityPub 时，会下意识地联想到微博（如 Mastodon），因为这是迄今为止最流行的应用。如果你考虑这个领域，每个人都在某种程度上创建了自己的“独特社区”，其定义取决于他们关注了谁。这构成了他们的个人时间线。除此之外，他们可能选择在例如 mastodon.technology 上创建账户，其服务器时间线大致围绕“技术”这一主题。当然，这个领域并不真正适合 Discourse。毕竟，那是微博，而不是社区论坛。
目前，一些微博应用正在将其领域扩展到“群组”的概念。你可以将其视为一种跨越服务器边界的社区概念。因此，虽然我在 mastodon.technology 上，但我可以订阅“意大利面”群组或“气候变化”群组。但这仍然是微博——所有内容都被压缩并扁平化到我的时间线中。
什么是成功的社区？它的边界在哪里？什么属于内部，什么属于外部？这些可能定义得非常清晰，并与身份和多样性相关。但它们本身并不一定与特定的服务器边界相关！
尽管我在《社区没有边界》（Community has no boundary）一文中探讨得非常广泛，但我的思考正是基于我所指出的那些人为的服务器边界（以及这如何可能提升社区的质量、数量和活跃度）。我尚未深入探讨身份问题，而这也是一个值得探讨的重要方面。感谢你在该帖中的回复 @Mevo，我会在适当的时候进一步回应。
感谢 @aschrijver，这非常有帮助。
从第一段中，我领会到“明智地使用”这一理念。
关于第二段，当我提到“ActivityPub”时，我更关注的是它所带来的功能或实现的效果，而非协议本身。比如你提到的“分享/链接内容”或“将内容从服务器边界中解放出来”这样的概念。
某种控制权或权力转移的想法很有意思：社区所有者将不再真正掌控“他们的”用户、“他们的”内容（至少是他们托管的内容）、访客来到他们的平台时能访问什么、信息如何组织和归类等等。用户将拥有更多控制权，更自由地选择他们想要的内容、来源，并打造属于自己的“菜单”。
我能理解这从用户视角来看可能很有吸引力，但从社区所有者的视角来看，可能会让人感到些许不安或担忧。
用餐厅来类比的话，我承认我之前的观点可能有点走得太远，比如把多个地方合并在一起。但我觉得你的类比过于温和：在我看来，这远不止你所描述的那样。这更像是去一家餐厅，却能够点另一家餐厅的菜品，由那家餐厅的厨师制作。这自然会引发一些问题（这也是我观点的核心部分）：为什么那位支付高薪、可能费尽周折才吸引并留住这位厨师的餐厅老板，会愿意不再拥有让顾客选择自己餐厅的明确理由？你的回答大致是：从顾客的角度来看这很棒。是的，当然，我同意。
不过无论如何，你在这点上可能是对的，而我提出的观点看起来很像过去企业对开源技术所抱有的担忧。
@angus 从 NGI 补助金处获得了支持此功能开发的资助，但该资助被拒绝了。我们将在明年申请另一项补助金。
那将非常棒。
有人能总结一下截至 11 月 22 日关于 Discourse 的 ActivityPub 实现的讨论现状吗？在阅读了许多相关帖子后，我目前的理解是这样的：
这个理解正确吗？我在德国的一家大型政党工作，我们确实需要一种能够实例之间共享活动通知的去中心化 Discourse。因此，我对这些想法的当前状态很感兴趣……
是的。
我们使用多个 Discourse 实例来处理 Discourse，用户可以通过以下方式获得集中式通知：
Web 推送通知（适用于 Android、Windows、Linux、MacOS）
DiscourseHub（适用于我们托管的网站，适用于 iOS 和 Android）
电子邮件（适用于任何地方）
更不用说能够订阅 RSS feed，通过 .ics 端点将书签同步到您的日历等。
为什么您需要 ActivityPub 来实现这一点？
是的，根据 OP，RSS 订阅源可能是拥有通用聚合互联网信息源的最佳解决方案。而且随着像 rss.app 这样的网站和 openrss.org 等运动的发展，如今你几乎可以获得任何你想关注的网站的 RSS 订阅源。
我们正在讨论中，可能还没有完全理解之前的讨论内容。
如果我们从集中式设置切换到去中心化设置，并使用多个 Discourse 实例（必须在欧洲本地托管，AWS 不在选项之列），一种“服务器到服务器”的活动消息传递方式将允许用户只登录一个系统，但仍能从另一个系统获取有关有趣活动的信息。
电子邮件“过于拥挤”，我们看到通过“标准新闻通讯”传播的信息覆盖率正在下降。ActivityPub（使用服务器到服务器 API）将允许在一个“首选服务器”上收集来自不同来源的信息。
RSS 订阅确实是一个可能的解决方案，但这需要在不同的服务器上进行注册/身份验证。而且，这需要手动操作，并且使用不同的技术，大多数“非技术”用户对此并不熟悉。
我非常希望能够邀请 Fediverse 的人们以比手动单框更丰富的方式参与我的 Discourse 服务器。
虽然我使用 RSS Feed（事实上，我用它来跟踪多个 Discourse 实例上的新内容），但一个仅支持出站的 ActivityPub / ActivityStream 插件将能触达人们聚集的地方，并有助于提高 Discourse 论坛信息的可用性。
我明白 Discourse 团队从根本上不同意这一点，这是他们的权利。Discourse 的巨大优势之一是，作为一个真正的开源项目，它是在公开场合构建的，而不是被扔过来的，我们不必意见一致。
也许围绕 Discourse 中 ActivityPub 的想法还需要进一步成熟，包括技术和战略层面。
我希望当前的“推特灾难”能迫使更多人（尤其是政治层面的人）重新思考他们自己的“数字主权”出了什么问题。而且，也许这还包括为公共和社区数字讨论领域真正的开源解决方案带来新的机会……
到目前为止，我们一直在推动 Discourse 中的 ActivityPub，并听到许多人试图解释为什么他们需要 ActivityPub……但我们没有听到 @Discourse 团队为什么不想实现它。我试图用一些合理的方法来解决提出的每一个论点，但最终对于远程标识符如何改变信任级别仍然不清楚，因为远程帐户仍然可以被视为本地的_暂存_帐户，并像现在的暂存用户一样受到限制。
有多个相关帖子。我想强调的是，@sam 明确表示，我在这里将“话语团队从根本上不同意这一点”的说法是错误的或过时的：
我预计 CDCK 没有投入资源来完成这项工作的原因是，他们付费客户中很少有人关心这一点，或者至少不像其他功能那样重视它。我怀疑目前以及可预见的未来，社区对这项工作的兴趣远大于企业兴趣。如果 CDCK 承担这项工作，他们因未构建客户要求的其他功能而产生的机会成本可能会很大。（我对此没有内部消息。）
鉴于上面链接的 Sam 的评论，如果一群 Discourse 社区开发者足够关心并愿意构建一个插件，我预计 CDCK 会投入与这些开发者合作，审查和合并使该插件生效所需的任何核心更改。我为 Discourse 所做的少量贡献的经验是，他们优先审查和帮助处理他们自己不会优先做的工作。
作为一个简单的 Discourse 用户（托管了一个小型实例），而且是最近才开始使用的，我无法提供关于如何从技术上着手的确切建议。但我注意到 WordPress 通过其插件正在联邦宇宙中占据重要地位。截至 2023 年 2 月，已有 750 多个网站进行联邦，这已经超过了许多专门的联邦平台。因此，存在着将所有 Discourse 社区（如果它们愿意的话）“神奇地”融入一个更集成化的体系的潜力。主要需要注意的是（很可能）随着采用率的提高，联邦协议将会发展，因此这将是一个需要相关功能同步发展的承诺。
@SeriousFun01 阅读 Federation support for Discourse - #87 by angus 及后续帖子以获取此处更新。 