5.0 KiB
🛠️ ActivityPub 接入 Solar Network 的分步清单
⸻
🧱 1. 准备 & 设计阶段
1.1 理解 ActivityPub 的核心概念 • Actor / Object / Activity / Collection • Outbox / Inbox / Followers 列表 ActivityPub 是使用 JSON-LD + ActivityStreams 2.0 来描述社交行为的规范。 
1.2 映射你现有的 Solar Domain 结构
把你现在 Solar Network 的用户、帖子、关注、点赞等： • 映射为 ActivityPub 的 Actor / Note / Follow / Like 等 • 明确本地模型与 ActivityStreams 对应关系
比如： • Solar User → ActivityPub Actor • Post → ActivityPub Note/Object • Like → ActivityPub Like Activity 这一步是关键的领域建模设计。
⸻
🚪 2. Actor 发现与必要入口
2.1 实现 WebFinger
为每个用户提供 WebFinger endpoint：
GET /.well-known/webfinger?resource=acct:@
用来让远端服务器查出 actor 细节（包括 inbox/outbox URL）。
2.2 Actor 资源 URL
确保每个用户有一个全局可访问的 URL，例如：
并在其 JSON-LD 中包含： • inbox • outbox • followers • following 这些是 ActivityPub 基础通信的入口。 
⸻
📮 3. 核心协议实现
3.1 Inbox / Outbox 接口
Inbox（接收来自其他实例的 Activity） Outbox（本地用户发布 Activity 的出口）
Outbox 需要： • 生成 activity JSON（Create、Follow、Like 等） • 存储至本地数据库 • 推送到各 follower 的 Inbox
Inbox 需要： • 接收并 parse Activity • 验证签名 • 处理活动（如接受 Follow，记录远程 Post 等）
注意： • 请求需要验证 HTTP Signatures（远端服务器签名）。  • 必须满足 ActivityPub 规范对字段的要求。
⸻
🔐 4. 安全与签名
4.1 Actor Keys
每个 Actor 对应一对 RSA / Ed25519 密钥： • 私钥用于签名发送到其它服务器的请求 • 公钥发布在 Actor JSON 中供对方验证
远端服务器发送到你的 Inbox 时，需要： • 使用对方的公钥验证签名
HTTP Signatures 是服务器间通信安全的一部分，防止伪造请求。 
⸻
🌐 5. 实现联邦逻辑
5.1 关注逻辑
处理: • Follow Activity • Accept / Reject Activity • 更新本地 followers / following 数据
实现流程参考：1. 本地用户发起 Follow 2. 推送 Follow 到远端 Inbox 3. 等待远端发送 Accept 或 Reject
5.2 推送 content（联邦同步）
当本地用户发布内容时： • 从 Outbox 取出 Create Activity • 发送到所有远端 followers 的 Inbox 注意：你可以缓存远端 followers 数据表来减少重复请求。
⸻
📡 6. 消息处理与存储
6.1 本地对象缓存
对于接收到的远端内容（Post / Note / Like 等）： • 需要保存到 Solar 的数据库 • 供 UI / API 生成用户时间线 这使得 Solar 能把远端联邦内容与本地内容统一展示。
6.2 处理 Collections
ActivityPub 定义了 Collection 类型用于： • followers 列表 • liked 列表 • outbox、inbox
你需要实现这些集合的获取与分页逻辑。
⸻
🔁 7. 与现有 Solar Network API 协调
你可能已经有本地的帖子、用户 API。那么： • 把这套 API 与 ActivityPub 同步层绑定 • 决定哪些内容对外发布 • 决定哪些 Activity 类型需要响应
比如：
Solar Post Create -> 生成 ActivityPub Create Note -> 发往联邦
⸻
📦 8. 测试与兼容性
8.1 与现存联邦测试
用已存在的 ActivityPub 实例测试兼容性： • Mastodon • Pleroma • Lemmy 等
检查： • 对方是否能关注 Solar 用户 • Solar 是否能接收远端内容
ActivityPub 规范（W3C Recommendation）有详细规范流包括： • Server to Server API 你最重要的目标是与现存实例互操作。 
⸻
🧪 9. UX & 监控支持
9.1 用户显示远端内容
从 Inbox 收到内容后： • 如何展示在 Solar UI • 链接远端用户的展示名 / 头像
9.2 监控 & 审计 • 失败的推送 • 无法验证签名的请求 • 阻止 spam / 恶意 Activity
⸻
🏁 10. 逐步推进
建议按阶段 rollout：
阶段 目标 Stage 1 实现 Actor / WebFinger / Outbox / Inbox 基本框架 Stage 2 支持 Follow / Accept / Reject Activity Stage 3 支持 Create / Like / Announce Stage 4 与远端实例互联测试 Stage 5 UI & Feed 统一显示本地 + 联邦内容
⸻
📌 小结
核心步骤总结：1. 映射 Solar Network 数据模型到 ActivityPub 2. 实现 WebFinger + Actor JSON-LD 3. 实现 Inbox 和 Outbox endpoints 4. 管理 Actor Keys 与 HTTP Signatures 5. 处理关注/发帖/点赞等 Activity 6. 推送到远端 / 接收远端同步 7. 将远端内容存入 Solar 并展示 8. 测试与现有 Fediverse 实例互通
这套步骤覆盖了 ActivityPub 协议必须实现的点和实际联邦要处理的逻辑。 
⸻
如果你想，我可以进一步展开 Solar Network 对应的具体 API 设计模板（包括 Inbox / Outbox 的 REST 定义与 JSON 输出示例），甚至帮你写 可运行的 Go / .NET 样例代码。你希望从哪一部分开始深入？