ActivityPub

1.1 Social Web 工作组

2.1 规范配置

本规范定义了两个密切关联并互有交互的协议：

客户端到服务器协议，或 "Social API"

该协议允许客户端代表用户行动。 例如，手机 App 可用该协议与用户的 actor 社交流交互。

服务器到服务器协议，或 "联邦协议"

本协议用以在不同服务器的 actor 之间分发活动，将他们编织进同一社交图谱。

ActivityPub 设计思路是，只要任一协议实现，支持另一个的成本极低。 但服务器可选实现其中任意一个。 因此有三类一致性级别：

ActivityPub 兼容客户端

适用于实现客户端到服务器协议的全部客户端部分的任何实现。

ActivityPub 兼容服务器

适用于实现客户端到服务器协议的全部服务器部分的任何实现。

ActivityPub 兼容联邦服务器

适用于实现全部联邦协议部分的任何实现。

如果某部分只适用于联邦协议实现，会在规范中特别说明。 此外，每当有具体要求时，会说明要求适用于客户端、服务器（针对客户端-服务器协议）或服务器到服务器协议中的发送/接收服务器。

3.1 对象标识符

[ActivityStreams] 的所有对象应具唯一全局标识。 ActivityPub 进一步要求，所有通过 ActivityPub 协议分发的对象必须具唯一全局标识， 除非它们有意为临时对象（如某些聊天消息或游戏通知，仅短暂存在，无需可查询）。 标识符需符合如下之一：

1. 可公开 dereference 的 URI，比如 HTTPS URI，且授权域归属其原服务器。 （对外内容建议使用 HTTPS URI）。
2. 明确标记为 JSON null，此时是匿名对象（属于父上下文一部分）

服务器间通信时，活动需必须带标识符，除非活动本就为临时事务。 而客户端到服务器通信时，服务器收到未指定 id 的 outbox 对象， 建议给其分配 actor 命名空间下的对象 ID 并附加到对象上。

所有对象都有下列属性：

id

对象的唯一全局标识符（临时对象可省略）。

type

对象的类型。

3.2 获取对象

可用 HTTP GET 方法根据对象的id属性 dereference，获取活动。 服务器可以按 [RFC7231] 所述实现 HTTP 内容协商， 选择响应类型， 但必须对 application/ld+json; profile="https://www.w3.org/ns/activitystreams" 提供 ActivityStreams 对象的表示， 并且建议对 application/activity+json 也提供 ActivityStreams 表示。 客户端必须用 Accept 头带上 application/ld+json; profile="https://www.w3.org/ns/activitystreams" 类型以便获取该活动。

服务器可以对未满足上述要求的请求采取其他在合理范围内的行为。 （如实现遗留协议，或对同一 URI 可返回 HTML 及 ActivityStreams 表示）。

服务器可以要求按 B.1 身份验证与授权 的说明进行授权，也可实现自有授权规则。 服务器建议对未通过授权校验的请求返回合适的 HTTP 错误码，若对象为私有可给 403 Forbidden。 若服务器不希望泄漏私有目标 existence，可以直接返回 404 Not Found。

3.3 source 属性

除了 [Activity-Vocabulary] 定义的所有属性，ActivityPub 在 Object 上新增 source 属性。 source 属性用于指示 content 标记是由什么源内容转换而来，作为溯源之用，也便于客户端未来再次编辑。 一般来说，source 到 content 的转换由客户端完成，反向则不然。

source 的值本身是对象，包含自有的 content 和 mediaType 字段，表明源内容信息。

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en"}],
  "type": "Note",
  "id": "http://postparty.example/p/2415",
  "content": "<p>我 <em>真的</em>喜欢草莓！</p>",
  "source": {
    "content": "I *really* like strawberries!",
    "mediaType": "text/markdown"}
}

4.1 Actor 对象

除了3.1 对象标识符要求的属性外，Actor 对象必须具备以下属性：

inbox

指向一个 [ActivityStreams] OrderedCollection ，包含该参与者接收到的所有消息；详见 5.2 Inbox。

outbox

指向一个 [ActivityStreams] OrderedCollection ，包含该参与者产生的所有消息；详见 5.1 Outbox。

实现建议另外提供以下属性：

following

指向一个 [ActivityStreams] 集合，表示本参与者关注的对象； 详见 5.4 Following Collection

followers

指向一个 [ActivityStreams] 集合，表示关注本参与者的人； 详见 5.3 Followers Collection。

实现可以再补充下列属性：

liked

指向一个 [ActivityStreams] 集合，包含该参与者点赞过的对象； 详见 5.5 Liked Collection。

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "ja"}],
  "type": "Person",
  "id": "https://kenzoishii.example.com/",
  "following": "https://kenzoishii.example.com/following.json",
  "followers": "https://kenzoishii.example.com/followers.json",
  "liked": "https://kenzoishii.example.com/liked.json",
  "inbox": "https://kenzoishii.example.com/inbox.json",
  "outbox": "https://kenzoishii.example.com/feed.json",
  "preferredUsername": "kenzoishii",
  "name": "石井健蔵",
  "summary": "この方はただの例です",
  "icon": [
    "https://kenzoishii.example.com/image/165987aklre4"
  ]
}

实现可以进一步提供以下属性：

streams

一个补充集合的列表，可能对用户有参考价值。

preferredUsername

可用来指代该参与者的短用户名，无唯一性保证。

endpoints

一个 json 对象，映射了额外（一般为服务端/域全局）的端点，这些可能对该参与者或引用者有用。 此 mapping 可以嵌入 actor 文档，也可链至带这些属性的 JSON-LD 文档。

endpoints mapping 可以包含如下属性：

proxyUrl

端点 URI，允许该参与者的客户端访问需认证的远程 ActivityStreams 对象。 用法：客户端 POST 一个 x-www-form-urlencoded 格式的 id 参数， 值为请求 ActivityStreams 对象的 id。

oauthAuthorizationEndpoint

如果认证使用 OAuth 2.0 令牌 [RFC6749] [RFC6750]， 该端点为浏览器认证用户获取授权凭证的 URI，用于 客户端到服务器交互。

oauthTokenEndpoint

如果认证使用 OAuth 2.0 令牌 [RFC6749] [RFC6750]， 该端点为客户端获取访问令牌的 URI，用于 客户端到服务器交互。

provideClientKey

如果使用 Linked Data Signatures 或 HTTP Signatures 做认证/授权，该端点为浏览器认证用户授权客户端公钥提供 URI， 用于 客户端到服务器交互。

signClientKey

如果使用 Linked Data Signatures 或 HTTP Signatures 做认证/授权，该端点为客户端密钥由 actor 密钥签名授权一段时间、代表用户操作外部服务器时提供 URI。

sharedInbox

可选端点 用于大范围推送面向公开与粉丝的活动。 sharedInbox 端点建议也是公开可读 OrderedCollection，只包含指向 Public 特殊集合的对象。 读取 sharedInbox 端点禁止展现非指向 Public 的对象。

5.1 Outbox

outbox 可通过 actor 资料里的 outbox 属性发现。 outbox 字段必须为一个 OrderedCollection。

outbox 数据流包含用户已发布的活动，其内容是否可见还受请求者权限影响（即 outbox 的内容必须根据阅读者的权限过滤）。 若某用户未含 授权信息，服务端仅应返回所有 Public 帖子。 这也许就是用户发布所有相关对象，但数量多少由服务器实现自行决定。

outbox 支持 HTTP POST，详细行为见 客户端到服务器交互。

5.2 Inbox

inbox 可通过 actor 资料的 inbox 字段发现。 inbox 字段必须是 OrderedCollection。

inbox 数据流包含参与者接收到的所有活动。 服务器建议根据请求者权限过滤内容。 一般说，inbox 的所有者能访问全部内容。依据访问控制，部分内容对公共公开，部分内容仅授权用户可见。 非 owner 用户按访问权限限制。

服务端必须对返回的 inbox 活动去重。若某活动既发给了 actor 的粉丝，又发给了其中一位关注者且两端都命中，极易产生重复。实现必须按 id 比较，丢弃已收录的活动，避免重复。

联邦服务器的参与者 inbox 支持 HTTP POST，详细行为见 Delivery。 非联邦服务器建议遇 POST 请求返回 405 Method Not Allowed。

5.3 Followers Collection

每个actor建议拥有 followers 集合。 该集合包括所有向该参与者发送过 Follow 活动的用户，作为 副作用添加。 这里可查所有关注该 actor 的人。 followers 集合必须为 OrderedCollection 或 Collection ，并可以结合权限过滤。

5.4 Following Collection

每个 actor 建议拥有 following 集合。 其列出演员已关注的所有人，均为 副作用追加。 following 集合必须为 OrderedCollection 或 Collection ，可以结合权限过滤。

5.5 Liked Collection

每个 actor 可以拥有 liked 集合。 该集合是所有该 actor Like 活动对象的集合，均为副作用追加。 liked 集合必须为 OrderedCollection 或 Collection ，可以结合权限过滤。

5.6 公开寻址

除了 [ActivityStreams] 集合和对象外， Activity 还可寻址特殊 "public" 集合，其标识为 https://www.w3.org/ns/activitystreams#Public。 例如：

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://www.w3.org/ns/activitystreams#Public",
  "type": "Collection"
}

发往该特殊 URI 的 Activity 应无认证限制对所有用户可访问。 实现禁止将实际活动直接投递给"public"集合； 该集合不能接收内容。 不过，actor可以定义 sharedInbox 端点，提升公共/粉丝消息的投递效率；详见 7.1.3 共享收件箱投递。

5.7 Likes Collection

每个对象可以有 likes 集合。 该集合包含所有以该对象为 object 的 Like 活动，为副作用自动添加。 likes 集合必须为 OrderedCollection 或 Collection ，可以结合权限过滤。

5.8 Shares Collection

每个对象可以有 shares 集合。 这集合包含所有以此对象为 object 的 Announce 活动， 为副作用添加。 shares 集合必须为 OrderedCollection 或 Collection ，可以结合权限过滤。

6.1 客户端寻址

客户端负责为新 Activity 合理寻址（指定收件人）。 在一定程度上这取决于客户端具体实现，但需注意服务器只会向to、bto、cc、bcc、audience 字段指定的收件人分发 Activity。

Followers 集合和/或Public 集合是新 Activity 默认寻址的好选择。

客户端建议遍历新 Activity 附带对象的 object、target、inReplyTo、tag 字段，获取它们的 actor 或 attributedTo 属性，还可以获取其地址信息，并将这些加入新 Activity 的 to 或 cc 字段。 客户端可以递归遍历嵌套对象，如递归时建议设置递归深度限制。 （注意不建议“展开”被寻址的 actor 集合作为单独收件人）。

客户端可以为用户在界面提供修改寻址的机会。

例如 Chris 对 Amy 这篇文章点赞：

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en-GB"}],
  "id": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
  "type": "Article",
  "name": "Minimal ActivityPub update client",
  "content": "Today I finished morph, a client for posting ActivityStreams2...",
  "attributedTo": "https://rhiaro.co.uk/#amy",
  "to": "https://rhiaro.co.uk/followers/",
  "cc": "https://e14n.com/evan"
}

客户端产生如下 Like：

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en"}],
  "type": "Like",
  "actor": "https://dustycloud.org/chris/",
  "summary": "Chris liked 'Minimal ActivityPub update client'",
  "object": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
  "to": ["https://rhiaro.co.uk/#amy",
         "https://dustycloud.org/followers",
         "https://rhiaro.co.uk/followers/"],
  "cc": "https://e14n.com/evan"
}

接收的 outbox 可据此将消息投递给 Chris（点赞者）的粉丝、Amy、Amy 的粉丝和收到原始文章的 Evan。

客户端向 outbox 提交如下活动时必须在 activity 中提供 object 属性： Create、Update、Delete、 Follow、Add、Remove、 Like、Block、Undo。 另外针对 Add、Remove，还必须一同提交 target 属性。

6.2 Create Activity

Create 活动用于发布新对象。 其副作用是 activity 中嵌入的对象（在 object 属性中）被创建。

Create 活动被提交时，活动的 actor建议复制到 object 的 attributedTo 字段。

Create activity 与包裹对象的地址信息不一致容易让人困惑。因此服务器建议在最初分发时，将 Create activity 的收件人复制到 object，或将 object 的收件人复制给外层 Create。 之后如 object 的收件人发生变更无需同步到 Create 的地址（如后续通过 Update activity）。

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "This is a note",
  "published": "2015-02-10T15:04:55Z",
  "to": ["https://example.org/~john/"],
  "cc": ["https://example.com/~erik/followers",
         "https://www.w3.org/ns/activitystreams#Public"]
}

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "id": "https://example.net/~mallory/87374",
  "actor": "https://example.net/~mallory",
  "object": {
    "id": "https://example.com/~mallory/note/72",
    "type": "Note",
    "attributedTo": "https://example.net/~mallory",
    "content": "This is a note",
    "published": "2015-02-10T15:04:55Z",
    "to": ["https://example.org/~john/"],
    "cc": ["https://example.com/~erik/followers",
           "https://www.w3.org/ns/activitystreams#Public"]
  },
  "published": "2015-02-10T15:04:55Z",
  "to": ["https://example.org/~john/"],
  "cc": ["https://example.com/~erik/followers",
         "https://www.w3.org/ns/activitystreams#Public"]
}

6.3 Update Activity

Update 活动用于修改已有对象。 副作用是object必须被修改为更新活动中定义的新结构，前提是 actor 有权限。

6.4 Delete Activity

Delete 活动用于删除已有对象。 其副作用是服务器可以把 object 替换为 Tombstone 对象，以在引用已删除对象的活动中显示。 当请求已删除对象时，若响应体为 Tombstone，服务器建议返回 HTTP 410 Gone，否则返回 404 Not Found。

被删除的对象示例：

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://example.com/~alice/note/72",
  "type": "Tombstone",
  "published": "2015-02-10T15:04:55Z",
  "updated": "2015-02-10T15:04:55Z",
  "deleted": "2015-02-10T15:04:55Z"
}

6.5 Follow Activity

Follow 活动用于订阅其他用户的动态。

该活动进入outbox的副作用是，当随后收到以该 Follow activity 作为 object 的 Accept activity 时，服务器建议把 object 添加到 actor 的following 集合中。

6.6 Add Activity

当 Add 活动进入outbox时，服务器建议将 object 添加到 target 字段指定的集合，除非：

• target 不属于接收服务器，因而无权操作。
• object 被服务器认为不能被添加到 target 集合（其他原因，由服务器自行裁决）。

6.7 Remove Activity

Remove 活动进入outbox时，服务器建议将 object 从 target 集合中移除，除非：

• target 不属于接收服务器，因而无权操作。
• object 不允许被移除出 target 集合（由服务器自行裁决）。

6.8 Like Activity

Like 活动表示 actor 点赞了 object。

该活动进入outbox的副作用是，服务器建议将 object 添加到 actor 的liked 集合中。

6.9 Block Activity

Block 活动表示发布该活动的 actor 不希望 object 属性指向的另一个 actor 能与自己发布的对象互动。 服务器建议阻止被屏蔽用户对 actor 发布对象的任何交互。

服务器不建议向 object 投递 Block 活动。

6.10 Undo Activity

Undo 活动用于撤销之前的操作。 参见 Activity Vocabulary 文档 逆活动和“Undo”。 例如 Undo 可撤销 Like、Follow 或 Block。 撤销活动与被撤销操作必须为同一 actor。 应尽可能撤销相应副作用。 比如撤销 Like，那么所有计数应相应减一。

某些情况存在明确“逆操作”活动应优先用之。 基于 Create 的活动用 Delete，Add 用 Remove。

6.11 投递

联邦服务器必须按outbox 投递规则，对所有发布到outbox的 Activity 进行投递。

7.1 投递

下述内容仅适用于实现了服务器间联邦通信的服务器。

活动投递给目标（即actor）时，首先查找目标 actor 的 inbox，然后将 activity post 到该 inbox。 投递目标通过查阅 ActivityStreams 的 audience targeting 字段决定，即 to、bto、cc、bcc 和 audience。

获取 inbox 的方法：检索目标 actor 的 JSON-LD 表示，然后查找 inbox 属性。 若收件人为 Collection 或 OrderedCollection，服务器必须用用户的凭证 dereference 该集合，并为集合内每项查找 inbox。 服务器必须限制集合递归查找的层数，可以只查一层。

服务器必须对最终收件人去重；还必须排除 activity 的 actor 本人，也就是说，不应把 activity 推送给自己。

然后向 inbox 发起带用户认证信息的 HTTP POST，请求体为 Activity。 收件方将该 Activity 作为 inbox OrderedCollection 的 item 添加进去。 向非联邦服务器的 inbox 投递时，建议返回 405 Method Not Allowed。

联邦服务器向第三方服务器投递推荐异步进行，如因网络故障导致失败建议自动重试。

注意：同源 actor 之间的 Activity 分发可以选择任何内部机制，不一定使用 HTTP。

7.2 Create Activity

收到 Create 活动添加到 inbox，理论上副作用极少；活动会显示在 actor 的 inbox，通常服务器会在本地保存活动及对象的表示。 不过这和一般接收 inbox 活动的处理并无不同。

7.3 Update Activity

服务器间的 Update 活动，接收服务器建议用 Activity 中新对象内容替换本地相同 id 的 object 副本。 与 客户端到服务器交互不同，此为全量替换而非部分更新。

接收服务器必须确保 Update 活动有权修改该 object。最小条件为 Update 及其对象必须同源。

7.4 Delete Activity

收到该活动的副作用为（假定 object 属于发送方 actor / 服务器），接收服务器建议移除等 id 对象的本地副本，并可以用 Tombstone 替换之。

（注意 ActivityPub 无法强制远端服务器根据活动删除接收对象副本，协议仅限于原始发送服务器→远端）。

7.5 Follow Activity

收到该活动添加到 inbox 时，服务器建议生成 Accept 或 Reject 活动，并将其作为该 Follow 的 object 投递给 Follow 的 actor。 Accept 或 Reject可以自动生成，也可以经用户审核后手动。 服务器可以选择不明确回应 Reject，但实现需知这样会导致提交方服务器处于中间态。例如为了保护用户隐私而不返回 Reject。

如果收到一个引用该 Follow 为 object 的 Accept，服务器建议将该 actor 加入 object actor 的Followers 集合。 若收到 Reject，服务器禁止将 actor 添加到 object actor 的Followers 集合。

7.6 Accept Activity

接收 inbox 中 Accept 的副作用取决于收到的 object 类型，也可用于本文件未描述的类型（如 Offer）。

如果 Accept 的 object 为事先发送的 Follow 活动，服务器建议将 actor 加入接收者的Following 集合。

7.7 Reject Activity

接收 inbox 中 Reject 的副作用取决于收到的 object 类型，也可用于本文件未描述的类型（如 Offer）。

如果 Reject 的 object 为事先发送的 Follow 活动，这意味着收件人未批准 Follow 请求。服务器禁止将 actor 加入接收者的Following 集合。

7.8 Add Activity

收到 Add 活动进入 inbox 时，服务器建议将 object 添加到 target 指定的集合，除非：

• target 不归接收服务器所有，因此无权修改。
• 出于其它原因，不可将 object 添加到 target 集合，由接收服务器裁决。

7.9 Remove Activity

收到 Remove 活动进入 inbox 时，服务器建议将 object 从 target 指定集合移除，除非：

• target 不归接收服务器所有，因此无权修改。
• 出于其它原因，不能将 object 从 target 集合移除，由接收服务器裁决。

7.10 Like Activity

收到该活动进入 inbox 的副作用为，服务器建议增加对象的点赞数，将收到的活动加进 likes 集合（如有）。

7.11 Announce Activity（分享）

收到 Announce 活动进入 inbox 时，服务器建议增加对象 share 次数，将收到的活动加进 shares 集合（如有）。

7.12 Undo Activity

Undo 活动用于撤销上一次活动的副作用。参见 ActivityStreams 文档 逆向活动与“Undo”。 Undo 活动的范围和约束与 客户端-服务器交互上下文下的 Undo 活动 一致，但用于联邦场景。