NodeBB中ActivityPub协议的安全接收策略优化

背景介绍

在NodeBB论坛系统中，ActivityPub协议的实现是其支持联邦化(Fediverse)功能的核心部分。当系统接收到来自其他联邦实例的活动(Activity)时，需要对这些活动进行有效性验证，以确保系统不会盲目接受任何内容，从而提升系统的安全性和资源利用率。

问题分析

在ActivityPub协议中，常见的活动类型包括Create(Note)和Announce(Note)等。这些活动可能来自任何联邦实例，但并非所有活动都与本地系统相关。盲目接收和处理所有活动会导致：

1. 不必要的资源消耗（存储、计算等）
2. 潜在的安全风险（垃圾信息、恶意内容等）
3. 数据冗余和混乱

解决方案设计

针对这一问题，NodeBB团队设计了一套精细化的活动接收策略，根据活动类型和上下文关系进行过滤。

Create(Note)活动处理策略

对于创建笔记类型的活动，系统会进行以下检查：

1. 作者关系验证：检查活动对象(object.attributedTo)是否被至少一个本地用户关注。如果是，则接受该活动，因为这表示内容来自用户关心的来源。

2. 主题链验证：通过getParentChain()方法检查活动是否属于一个已存在的主题讨论链。如果能够追溯到本地存在的主题ID(tid)，则接受该活动，确保讨论的连贯性。

3. 提及验证：检查活动对象的标签(object.tag)中是否包含对本地用户的提及。如果活动直接提及了本地用户，则应该被接收以确保用户能收到相关通知。

Announce(Note)活动处理策略

对于转发(boost)类型的活动，验证策略有所不同：

1. 本地内容验证：首先检查被转发内容的对象ID(object.id)是否是本地已有的帖子。如果是，则接受该转发活动，因为这表示本地内容正在被传播。

2. 转发者关系验证：如果被转发内容不是本地的，则检查转发者(actor)是否被至少一个本地用户关注。只有来自被关注用户的转发才会被接收，减少无关内容的传播。

实现考量

最初考虑使用中间件(middleware)模式统一处理这些验证逻辑，但由于不同活动类型的验证条件存在较大差异且相互排斥，最终决定在各自的控制器中分别实现这些检查逻辑。

特别值得注意的是，对于Announce(Note)类型活动，需要确保它能够跳过某些适用于Create(Note)的检查条件，保持转发功能的正常工作。

技术价值

这种精细化的接收策略为NodeBB带来了多重好处：

1. 性能优化：减少了不必要的活动处理，降低了系统负载
2. 用户体验：确保用户只看到真正相关的内容
3. 安全性增强：有效过滤潜在的垃圾或恶意内容
4. 数据质量：保持数据库内容的关联性和价值

这种设计模式也为其他实现ActivityPub协议的系统提供了有价值的参考，展示了如何在开放协议与系统资源管理之间取得平衡。