Owncast私有模式下关注请求处理异常问题分析

问题背景

Owncast作为一款开源自托管直播平台，在启用私有模式(Private mode)时，用户需要通过发送关注请求来订阅主播内容。近期社区发现了一个关键问题：当管理员在后台接受来自其他ActivityPub联邦网络(如Mastodon、GoToSocial等)的关注请求时，对方服务器无法正确识别接受状态，请求会一直停留在"Requested"状态。

问题现象

多位用户报告了相似的现象：

1. 来自GoToSocial和Mastodon实例的关注请求在被Owncast接受后，对方服务器仍显示为"请求中"状态
2. 临时关闭私有模式后，关注请求能正常完成
3. 问题具有一致性，不同联邦服务器都出现相同行为

技术分析

通过深入代码分析和网络活动抓取，发现问题根源在于Owncast在私有模式下生成的ActivityPub Accept活动缺少必要的object属性。

正常模式下的Accept活动

在非私有模式下，Owncast会生成完整的Accept活动，包含以下关键属性：

{
  "type": "Accept",
  "actor": "主播的ActivityPub ID",
  "object": {
    "type": "Follow",
    "actor": "关注者的ActivityPub ID",
    "object": "被关注的主播ID"
  }
}

私有模式下的Accept活动

而在私有模式下，生成的Accept活动缺少了关键的object属性：

{
  "type": "Accept",
  "actor": "主播的ActivityPub ID"
}

问题根源

追踪代码发现，问题出在数据持久层和业务逻辑层的交互上：

1. 当收到关注请求时，createFollow方法能正确保存完整的请求对象
2. 但在查询时，GetFollower方法没有填充followRequest.RequestObject字段
3. 导致后续的SendFollowAccept方法接收到nil值，生成不完整的Accept活动

影响范围

此问题影响所有使用私有模式的Owncast实例，特别是：

• 与GoToSocial实例的交互
• 与Mastodon实例的交互
• 其他遵循ActivityPub协议的联邦服务器

解决方案建议

修复此问题需要：

1. 在GetFollower方法中正确解析并填充RequestObject字段
2. 确保从存储中读取的原始请求数据能正确反序列化为ActivityPub对象
3. 在发送Accept活动前验证所有必需字段的存在性

技术启示

这个问题揭示了联邦社交网络中几个重要概念：

1. ActivityPub协议规范：Accept活动必须包含原始Follow请求作为object属性
2. 数据完整性：持久层不仅要存储数据，还要保证读取时能完整恢复原始结构
3. 模式差异处理：私有模式不应简化核心协议数据结构，而应通过其他方式实现隐私保护

总结

Owncast在私有模式下处理关注请求时生成不完整ActivityPub消息的问题，虽然表面上是简单的字段缺失，但反映了协议实现完整性和数据持久化处理的重要性。开发者需要特别注意在不同功能模式下保持核心协议数据结构的完整性，确保与其他联邦服务器的互操作性。