就是这个。可能还包括远程“点赞”操作。
我注意到，自从埃隆·马斯克开始收购推特以来，Fediverse 的活跃度和人口明显增加。
在我运行的 Discourse 实例（目前有三个）上，我希望能够使用 Mastodon（就我而言）来关注它们并“转推”它们给更广泛的受众，使我的实例上的信息对可能关心的其他人更加可访问和可见。我的所有实例都旨在扩展各种主题的公共知识范围，通过 ActivityPub 集成进行丰富的共享支持将有助于实现这一目标。
将 RSS 转换为 ActivityPub 帮助不大。
如果这是我的项目，它将分阶段进行，并从简单开始：
- 仅发布：将分类作为 Actor，包括主题的回复帖子，并使用
inReplyTo正确地进行线程化。这些帖子将与例如转发到聊天集成的帖子同时发送给关注者，按帖子发送。这需要将（至少一些）分类发布为 Actor 并为每个 Actor 存储关注者。这些分类 Actor 不会关注或点赞。不会使用身份验证访问。它将遵守点赞、阻止和撤销活动。也许还有一个整个服务器的 Actor，以便轻松关注服务器上的所有活动。 - 最小双向：可以选择接受远程
Like操作。 - 更多双向：与
Announce操作（即共享、转推、提升）进行交互，将其添加为点赞或单独显示。 - 用户交互：可选地，支持用户的 Webfinger，以便能够将用户作为 Actor 关注以查看他们的所有帖子。进一步可选地，受限于组（我可能希望将其限制为 TL2，例如），能够与外部 ActivityPub Actor 进行私信交流。这可能（至少是公开的）在其
liked集合中实现用户喜欢的帖子集合。 - 文本双向：可选地，接受来自非成员通过 ActivityPub 的回复作为评论 — 但这一项很棘手，因为它会天真地将其反射出去成为一个新帖子，因此关注者会看到两次。可能需要将帖子标记上其外部引用，而不是发布给关注者的收件箱。
我明确不希望支持从 Discourse 中“关注”ActivityPub Actor；将 Discourse 变成一个（例如）Mastodon 克隆似乎有点浪费。在 ActivityPub 规范的语言中，它不会是一个“符合 ActivityPub 的联合服务器”，这没关系。此外，协议的客户端部分在这个计划中没有任何位置。