你好 @rishabh、@riking、@codinghorror，
（是的，下面有 TL;DR 摘要）
之前我从 @sl007 和 @hellekin 那里了解到，即使有 NGI0 的资金支持，你们在短期内也不会推进这一阶段（Phase 1）。作为同样推崇基于 ActivityPub 的互操作性的支持者，我当然也觉得这很遗憾。但从 Discourse 的角度来看，作为领先且最受欢迎的论坛软件，其中涉及诸多力量和优先级考量，因此在此背景下做出的这一商业决策可能非常合理：
决策：本 RFC 按当前提议的吸引力不足，因此未被优先考虑，也未列入路线图。
该 RFC 采取了最小可行产品（MVP）的方法，即按照 @Falco 的提议，“首先创建一个类似 Facebook 的跨论坛聚合内容流”。这仅仅是拥有某种形式的原生 ActivityPub 支持后可能产生的众多功能之一。可以说，这样的时间线某种程度上偏离了论坛通常具备的功能，对我而言，这似乎并非真正的核心功能，而更像是一个附加扩展，因此属于“锦上添花”而非“不可或缺”。
另一种方法
既然不再需要急于推出 ActivityPub 支持的 MVP，或许我们可以反其道而行之：
构思：头脑风暴各种互操作用例，并从商业利益和独特卖点（USP）的角度评估其可行性。
也就是说，哪些功能真正值得在 Discourse 中实现？或者更进一步：如果 Discourse 不了解这些可能性，可能会错失哪些机会？
在 @Falco 的 最新帖子 中，他提到了 Lemmy。Lemmy 完全基于与其业务领域相匹配的专用链接数据词汇表构建。他们已准备好 MVP 并投入生产，现在正致力于在其自身领域基础上扩展功能集。这可能包括与另一个领域（即微博领域，Mastodon、Pleroma 等在此领域非常成功）进行联邦互联。
构思过程或许可以遵循以下练习：
练习：让我们设想，如果 Discourse 从一开始就基于其自身的基于 ActivityPub 的业务领域（定义为链接数据词汇表）构建，它会是什么样子。
让我们在这个头脑风暴会议中尽情发挥，让创意自由驰骋。
由此产生的用例列表，如果从商业角度看来足够有趣，或许可以成为路线图的一部分；即使不能，它们也可能激励社区开发插件和组件，为后续阶段的建设奠定基础。
ActivityPub 与 Fediverse
我注意到，关于在应用程序中支持 ActivityPub 的含义，存在广泛的误解。许多人认为这样做的原因是为了“成为 Fediverse 的一部分”。于是，人们的思路立刻转向与 Mastodon 实例进行联邦，即实现与（加入）联邦式微博领域的互操作性。
是的，一旦拥有 ActivityPub 支持，这是一个非常有吸引力的机会。许多其他应用程序，如 PixelFed（Instagram 的替代品）、PeerTube（YouTube 的替代品）以及 Lemmy（Reddit 的替代品），都在寻求实现这一目标。它们使 Fediverse 成为一个更具吸引力的参与空间，并且大量创新正在形成，让 Fediverse 的未来令人兴奋。
但是……
可以认为，像 Discourse 这样面向庞大用户群的组织可能会提出这样的问题：“我为什么要与仅拥有约 400 万用户的 Fediverse 集成？”或者“我为什么要将微博功能集成到完全处于不同领域的软件中？”他们完全有理由这样陈述，并基于此前提放弃 ActivityPub 的实现。
然而……
ActivityPub 的实现远不止于成为（Fediverse 中的微博部分）的一部分。为自身的业务领域设计独特的链接数据词汇表，并让自身的产品实例相互联邦，或者让自身产品及同行业竞争对手（如果他们也采用相同词汇表）的所有实例相互联邦，这完全合乎逻辑。
一个例子是 ForgeFed 项目，该项目旨在为代码托管平台（如 GitHub、GitLab、Gitea、Sourcehut 等）制定互操作性标准。这样做非常有意义，尤其对于较小的代码托管项目而言，可以提供具有吸引力的 GitHub 替代方案（GitHub 已变得过于主导，成为一个日益封闭的围墙花园平台）。如果广泛采用，开发人员将不再需要在互联网上分散的服务器上管理众多代码托管账户，以参与有趣的代码项目、提交问题、发表评论和提交 PR。
（请注意，正如上文所指出的，人们对于独立代码托管平台遍布各处所面临的问题，也正是我和其他人在参与众多 Discourse 社区时所体验到的。）
机遇：Discourse 处于独特位置，可以引领论坛软件的互操作性标准制定，并以与当前 Discourse 功能集完美契合的方式塑造该标准。
贵行业有一些新兴竞争对手，他们具有创新性，采取新方法，并快速迭代以添加新功能（在 Discourse 工作的你们最清楚这些竞争对手是谁 
）。就功能完整性而言，Discourse 仍然远远领先于它们的产品。而且，你们拥有无与伦比的社区来协助产品演进。
但现在存在的互操作机遇也可能转变为威胁。要么竞争对手率先抓住这一机遇，要么——在欧盟《数字市场法案》的推动下——大型科技平台可能会创建与论坛软件领域重叠的产品。在这两种情况下，Discourse 都将更难与该标准保持一致，并在其规范设计中发挥最具权威性的声音。
TL;DR
这篇帖子比我预期的要长。对此抱歉 
总之，我的观点是，鉴于目前对支持 ActivityPub 的立场，从短期的 MVP 式焦点转向更广泛地评估 ActivityPub 互操作性能为 Discourse 带来的独特卖点（USP）和长期定位，可能是明智之举。也就是说，阐述采用 ActivityPub 的商业案例，从构思阶段开始。
（如何最好地组织这项工作——如果您感兴趣的话——我将其留作中间环节，但它可以简单地从一个新的 AP 主题开始，顶部有一个收集用例的总结 Wiki，人们在该主题中讨论用例想法。）