（为简洁起见，我引用了片段）。这里的餐厅类比其实不太成立。这就像你同时坐在两张桌子旁，并且身处一个更大的“聚合”餐厅，有更多人与你一同庆祝。你所说的可能是对的，但这完全取决于具体的实现方式。
虽然 ActivityPub RFC 主题 和 @hellekin 的 用例 将完全控制权交给了个人，但在上述我的描述中，社区结构完全掌握在社区工作人员手中。他们与其他社区建立合作伙伴关系，并且可能只能在双方同意的基础上分享社区的某些部分。
我认为这样做更符合 Discourse（公司）以及那些投入巨大精力打造自身身份和会员基础的社区管理者的利益。也就是说，这更像是一个 商业案例。因此，工作人员仍将拥有完全控制权，并负责确保社区组织的构成全面且直观。他们是“社区结构的编辑者”。
如果你允许 Discourse 用户完全自由地用来自各处的论坛内容填充他们空白的“门户”，那么你将得到一种完全不同的社区动态。该用例在特定情况下具有价值，但它与“工作人员保持控制”的用例完全不同。当然，介于两者之间的各种灰色地带也是可能的。
是的，我知道它们，我也热爱 OpenBazaar 作为去中心化市场 的理念，但阻止我去尝试它的是加密货币。这是一个信任问题。对许多人来说，这可能也是阻碍他们的原因。但除此之外，是既得 Big Tech 巨大的网络效应使得新进入者很难立足，他们推出新服务，在拥有数百万日活跃用户的网站上进行广告推广，并能够在事情最终兴起之前承受巨额亏损运营。
是的，我同意这一点。这就是为什么我没有聚焦于“完全自由”，而是如上所述聚焦于“工作人员控制”的用例。在此模式下，ActivityPub 支持为 Discourse 作为社区管理者的产品增加了一个独特的卖点（USP），即付费客户。嗯……如果他们选择云托管订阅的话。
在这方面，Discourse（公司）可以通过提供增值服务来使订阅更具吸引力，例如提供发现和配对服务，让不同社区的社区管理者积极寻找合作伙伴关系和协作，以丰富他们（并隐含地丰富彼此）的社区。该服务可供任何人访问，或仅限付费计划客户访问。
它们应该想这么做吗？为什么这应该是目标？作为协议的 ActivityPub 允许 许多不同领域 的 许多不同应用 在任何层级上互操作。每个项目/应用/产品都将追求自己的目标，对于商业软件而言，则是其自身的独特卖点（USP）。
第一部分很重要。明智地选择你的联邦化方式。如果这样做会让你失去作为产品的所有身份，那么完全联邦化 绝不应 成为目标。
首先，“联邦化”与“联邦宇宙”（the fediverse）是有区别的。如果你使用 ActivityPub 构建联邦化，你可以按任何你想要的方式构建它。如果你构建的目标是集成到联邦宇宙中，那么存在一些既定事实标准来规范运作方式。在用户层面进行全联邦范围的封禁是不可能的，而对特定实例的封禁是基于每个其他实例管理员的决定，并配置在黑名单和白名单中。这些列表通常会被共享（类似于广告拦截器列表），并可能导致某些实例在整个联邦宇宙中被完全封禁（“它们被推到了联邦宇宙的边缘”）。
一个解释该概念的优秀视频是：
就像论坛一样，联邦宇宙中的每个联邦实例都是经过管理的。我认为这是一件好事。仍然拥有完全的自由，因为你可以启动自己的论坛/服务器实例而不进行管理，让一切随意发生。其他人也有基于此原因封禁你的自由。