ActivityPub

1.1 社交网络工作组

2.1 规范概述

本规范定义了两套紧密相关且相互作用的协议：

客户端到服务端的协议，或称"社交 API"

该协议允许客户端代表用户执行操作。例如，移动设备应用程序使用此协议与用户的行为体的社交信息流互动。

服务端到服务端到协议，或称"联合协议"

该协议用于在不同服务器上的行为体之间分发活动，将它们连接到同一份社交图谱中。

ActivityPub 规范的设计使得实现了这些协议中的一个后，支持另一个协议所需的额外工作将非常少。 但是，服务端仍可以仅实现其中一个协议。 这带来了三个一致性类别：

符合 ActivityPub 标准的客户端

此称号适用于实现了客户端到服务端协议客户端部分的全部内容的任何实现。

符合 ActivityPub 标准的服务端

此称号适用于实现了客户端到服务端协议服务端部分的全部内容的任何实现。

符合 ActivityPub 标准的联合式服务端

此称号适用于实现了联合协议的全部内容的任何实现。

规范的某个部分仅适用于联合协议的实现时，均会明确指出。 此外，在指定要求时，会明确说明这些要求是针对客户端还是服务端（对于客户端到服务端协议而言），或是指服务端到服务端协议中的发送方或接收方服务器。

3.1 对象标识符

[ActivityStreams] 中的所有对象都应该具有唯一的全局标识符。 ActivityPub 扩展了此要求；以 ActivityPub 协议分发的所有对象必须具有唯一的全局标识符，除非它们是有意被设为瞬态的（例如某些类型的聊天消息或游戏通知等短生命周期且不需要能够被查找的活动）。 这些标识符必须属于以下类型之一：

1. 可公开解引用的 URI，如 HTTPS URI，其权限属于其源服务器。 （面向公众的内容应使用 HTTPS URI）。
2. 显式指定为 JSON null 对象的 ID，这意味着该对象是一个匿名对象（作为其上级上下文的一部分）

在服务端间通信中发布的活动必须提供标识符，除非该活动是有意被设为瞬态的。 但是，对于客户端到服务器的通信，接收到没有指定 id 的对象的服务器应在行为体的命名空间中分配一个对象 ID 并将其附加到接收到的对象之上。

所有对象都具有以下属性：

id

对象的唯一全局标识符（除非对象是瞬态的，在此情形下 id 可以省略）。

type

对象的类型。

3.2 检索对象

可以针对对象的 id 属性使用 HTTP GET 方法以检索活动。 服务器可以按照 [RFC7231] 中的定义使用HTTP内容协商机制 来选择响应请求时返回的数据类型， 但必须在响应 application/ld+json; profile="https://www.w3.org/ns/activitystreams" 时给出ActivityStreams对象表示格式， 并应当在响应 application/activity+json 时也给出ActivityStreams表示格式。 客户端在检索活动时必须指定一个带有 application/ld+json; profile="https://www.w3.org/ns/activitystreams" 媒体类型的 Accept 标头。

服务端可以对不符合上述要求的请求实施其他行为。 （例如，服务器可能会实现额外的遗留协议，或 使用相同的URI同时提供资源的HTML和ActivityStreams格式）。

服务端可以根据B.1 身份验证和授权中的规定要求身份验证， 并且可以额外地实现其自身的授权规则。 对于未通过身份验证检查的请求，服务器应当返回适当的HTTP错误代码， 或者在对象的存在被认为是私密的情况下返回 403 Forbidden 错误码。 如果源服务器不希望披露私密目标的存在，可以改为返回 404 Not Found 状态码。

3.3 源属性（Source property）

在 [Activity-Vocabulary] 中定义的所有属性之外，ActivityPub 通过源属性（source 属性）扩展了对象（Object）。 source属性作为一种出处形式，旨在传达某种来源，用于派生 content 标记，或支持客户端的后续编辑。 通常情况下，客户端会从 source 转换到 content ，而不是从 content 转换为 source。

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": "草莓 *十分地* 美味！",
    "mediaType": "text/markdown"}
}

4.1 行为体 对象

除 3.1 对象标识符 中强制要求的属性外，行为体对象必须 具有以下属性：

inbox （收件箱）

对 [ActivityStreams] OrderedCollection （有序集合）的引用，该集合包含行为体接收到的所有消息；参见 5.2 收件箱。

outbox （发件箱）

一个 [ActivityStreams] OrderedCollection （有序集合），包含行为体创建的所有消息；参见 5.1 发件箱。

此外，ActivityPub 实现应当提供以下属性：

following （关注）

一个指向 [ActivityStreams] 集合的链接，该集合包含此行为体正在关注的行为体；参见 5.4 关注集合。

followers （粉丝）

一个指向 [ActivityStreams] 集合的链接，该集合包含关注此行为体的行为体；参见 5.3 粉丝集合。

实现可以 提供以下属性：

liked（点赞）

一个指向 [ActivityStreams] 集合的链接，该集合包含此行为体点赞过的对象；参见 5.5 点赞集合。

{
  "@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 对象，这些端点可能对该行为体或引用该行为体的其他人有用。 此映射可以作为值嵌套在行为体文档中，也可以是指向包含这些属性的 JSON-LD 文档的链接。

endpoints 映射可以包含以下属性：

proxyUrl

端点 URI，该行为体的客户端可以通过此 URI 访问需要身份验证的外站 ActivityStreams 对象。 要使用此端点，客户端需按 x-www-form-urlencoded 格式提交 id 参数，参数值为要请求的 ActivityStreams 对象的 id。

oauthAuthorizationEndpoint

若客户端到服务端交互使用 OAuth 2.0 不记名令牌[RFC6749] [RFC6750] 进行身份验证， 此端点指定一个 URI，通过浏览器完成认证的用户可在该 URI 上获取新的授权许可。

oauthTokenEndpoint

若客户端到服务端交互使用 OAuth 2.0 不记名令牌 [RFC6749] [RFC6750] 进行身份验证， 此端点指定一个 URI，客户端可以在该 URI 获取访问令牌。

provideClientKey

若身份验证和授权使用链接数据签名和 HTTP 签名，此端点指定一个 URI，通过浏览器完成认证的用户可在此 URI 上将授权客户端的公钥用于 客户端到服务端的交互。

signClientKey

若身份验证和授权使用链接数据签名和 HTTP 签名，则此端点指定一个 URI，在一段时间内，行为体的密钥可以在该 URI 上对客户端密钥进行签名，以代表行为体与外部服务器进行交互。

sharedInbox

此端点为可选端点， 用于广泛传递公开寻址的活动及发送给粉丝的活动。 sharedInbox 端点也应该是公开可读的 OrderedCollection 对象，其中包含寻址到公共特殊集合的对象。 从 sharedInbox 端点读取内容时，禁止呈现未寻址到公共（Public）端点的对象。

5.1 发件箱 (Outbox)

行为体通过 outbox 属性在其配置文件中暴露发件箱，供 ActivityPub 服务发现。 outbox 必须是一个 OrderedCollection（有序集合）。

发件箱流包含用户已发布的活动，但具体包含的内容取决于发起请求的用户获取活动的权限（即，outbox 的内容会根据读取者的权限进行过滤）。 如果用户提交了一个未进行 身份验证 的请求，服务端应返回用户所有的 公开 帖文。 这可能包括用户发布的所有相关对象，但可用条目的数量由软件实现与服务器管理员自行决定。

发件箱接受 HTTP POST 请求，其行为参见 客户端到服务端交互 部分。

5.2 收件箱 (Inbox)

行为体通过 inbox 属性在其配置文件中暴露收件箱，供 ActivityPub 服务发现。 inbox 必须是一个 OrderedCollection （有序集合）。

收件箱流包含行为体接收到的所有活动。 服务端应当根据请求者的权限筛选内容。 通常情况下，收件箱的拥有者可以访问收件箱的全部内容。 根据访问控制规则，某些其他内容可能公开，若其它不拥有收件箱的用户也可以在特定条件下访问收件箱，则可能需要进行身份验证。

服务端必须对通过收件箱返回的活动进行去重。 若同一活动既发送给行为体的粉丝，也直接发送给特定的关联行为体，但服务端未能对收件方列表进行去重，则可能产生重复。 此类去重必须通过比较活动的 id 实现，并去除任何已存在的活动。

能够进行联合的服务端上的行为体的收件箱可接受 HTTP POST 请求，其行为参见 信息投递 部分。 不进行联合的服务端应当在接收到 POST 请求时返回 405 Method Not Allowed。

5.3 粉丝集合 (Followers Collection)

每个行为体应当拥有一个 followers （粉丝）集合。 这是一个包含所有对该行为体发送过关注活动的行为体的列表，行为体被添加到粉丝集合是收到关注活动的一个 副作用（side effect）。 可以通过该集合找到所有关注当前行为体的用户的列表。 followers （粉丝）集合必须 是 OrderedCollection （有序集合） 或 Collection （集合） 类型，且 可以根据执行身份验证的用户的权限或在未进行身份验证时进行适当过滤。

5.4 关注集合 (Following Collection)

每个 行为体都 应当 拥有一个 following （关注）集合。 这是该行为体关注的所有人的列表，行为体被添加到关注集合是发送关注活动的一个 副作用。 following （关注）集合 必须 是 OrderedCollection （有序集合） 或 Collection （集合） 类型，且 可以根据执行身份验证的用户的权限或在未进行身份验证时进行适当过滤。

5.5 点赞集合 (Liked Collection)

每个行为体可以 拥有一个 liked （点赞）集合。 这是该行为体产生的所有 Like （点赞）活动中所有对象的列表，这些对象被添加到点赞集合是 产生点赞活动的一个 副作用。 liked （点赞）集合 必须 是 OrderedCollection （有序集合） 或 Collection （集合） 类型，并且可以根据执行身份验证的用户的权限或在未进行身份验证时进行适当过滤。

5.6 公共寻址

除 [ActivityStreams] 集合与对象之外，活动还可以被寻址到特殊的“公共”集合，其标识符为 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 的活动应可供所有用户访问，无需身份验证。 实现不得将活动传递到“公共”集合；它无法接收实际的活动。 然而，行为体 可以 拥有一个 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 客户端寻址

客户端负责正确地为新活动设定目标地址。 在某种程度上，这取决于客户端的特定实现，但客户端必须注意，服务端只会将新的活动转发给 to、 bto、cc、bcc和audience 字段中的地址。

粉丝集合和/或 公共集合 是作为新活动默认目标地址的良好选择。

客户端应当查看通过 object、target、inReplyTo 和/或 tag 字段被附加到新活动中的任何对象，获取它们的 actor 或 attributedTo 属性，且 可以获取它们的地址信息并将其添加到创建的新活动的 to 或 cc 字段中。 客户端可以递归处理附加对象，但如果这么做， 应当设置递归层级限制。 （注意，这并不表示客户端应将被列为接收方的行为体集合逐一展开为独立的收件方）。

客户端可以允许用户在界面上修改该目标地址。

例如，当 Chris 点赞 Amy 撰写的以下文章时：

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en-GB"}],
  "id": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
  "type": "Article",
  "name": "最小 ActivityPub 更新客户端",
  "content": "今天我写完了 morph 这个用来发布 ActivityStreams2 内容的客户端...",
  "attributedTo": "https://rhiaro.co.uk/#amy",
  "to": "https://rhiaro.co.uk/followers/",
  "cc": "https://e14n.com/evan"
}

客户端可按如下所示生成点赞活动:

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en"}],
  "type": "Like",
  "actor": "https://dustycloud.org/chris/",
  "summary": "Chris 点赞了 '最小 ActivityPub 更新客户端'",
  "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"
}

接收方的发件箱可以执行投递操作，将活动投递给 Chris （点赞者）的粉丝、Amy 以及 Amy 的粉丝和 Evan，因为他们都收到了原始文章。

在向 outbox （发件箱）提交以下活动时，客户端必须在活动中提供 object 属性： Create、Update、Delete、 Follow、Add、Remove、 Like、Block、Undo。 此外，在提交以下活动时，客户端必须同时向发件箱提供 target 属性： Add、Remove。

6.2 创建活动 (Create Activity)

Create （创建）活动用于发布新对象。 这会产生副作用，即创建了一个嵌入在活动中（位于 object 属性）的对象。

发布 Create 活动时，活动的 actor 应当被复制到对象的 attributedTo 字段中。

创建活动与其 object 的寻址不匹配可能会导致混淆。 因此，服务端在分发开始时应当将创建活动的所有接收方复制到其 object，同样地，也应将 object 的接收方复制到封装的创建活动中。 需要注意的是，之后可以更改 object 的地址而不更改 Create 的地址（例如，通过 Update 活动进行更改）。

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "这是一条 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": "这是一条 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 以反映更新活动中定义的新结构。

6.4 删除活动 (Delete Activity)

Delete 活动用于删除现有对象。 其副作用是，服务端可以将 object 替换为其 Tombstone （墓碑），该墓碑将显示在引用已删除对象的活动中。 如果某一实体请求已删除的对象，服务端应当在响应正文中展示了 Tombstone 对象的情形下使用 HTTP 410 Gone 状态码进行响应，否则使用 HTTP 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 活动用于订阅另一个行为体的活动。

在 发件箱 中收到该活动的副作用是，服务端 应当 且仅应当在随后收到以该 Follow 活动为对象的 Accept 活动时将 object 添加到 actor 的 following 集合 中。

6.6 添加活动 (Add Activity)

在发件箱 中收到 Add 活动时，服务端 应当 将 object 添加到 target 属性定义的集合中，除非：

• target 不被接收到活动的服务端所有，因而接收到活动的服务端无权更新它。
• 出于某些其他原因，服务端自行决定 object 不允许被添加到 target 集合中。

6.7 移除活动 (Remove Activity)

在 发件箱 接收到 Remove 活动时，服务端 应当 从 target 属性定义的集合中移除 object，除非：

• target 不被接收到活动的服务端所有，因而接收到活动的服务端无权更新它。
• 出于某些其他原因，服务端自行决定 object 不允许被从 target 集合中移除。

6.8 点赞活动 (Like Activity)

Like 活动表示 actor 对 object 表示喜欢。

在 发件箱 中接收到该活动的副作用是，服务端 应当 将 object 添加到 actor 的 liked 集合 中。

6.9 屏蔽活动 (Block Activity)

Block 活动用于表示发布此活动的行为体不希望另一个行为体（由 object 属性定义）能够与其发布的对象进行交互。 服务端 应当 阻止被屏蔽的用户与任何由该行为体发布的对象交互。

服务器 不应 将屏蔽活动传递给其 object。

6.10 撤销活动 (Undo Activity)

Undo 活动用于撤销之前的活动。 请参阅活动术语文档中关于 逆活动与“撤销”的内容。 例如，Undo 可用于撤销之前的 Like、 Follow 或 Block。 撤销活动与被撤销的活动必须由同一个行为体发布。 应尽可能撤销副作用。 例如，如果撤销 Like，应相应递减之前已递增的计数器。

在一些情况下，如果已存在明确的“逆活动”，应使用该逆活动。 基于 Create 的活动应改为使用 Delete，基于 Add 的活动应改为使用 Remove。

6.11 投递

联合式服务端 必须 根据 发件箱投递 的规定，对所有发布到 发件箱 的活动执行投递。

7.1 信息投递

以下内容仅适用于相互通信的联合式服务端。

通过首先查找目标的收件箱，然后将活动发布到查找到的收件箱，即可将活动投递到其目标（即行为体）。 通过检查 ActivityStreams 目标地址来确定投递目标；即活动的 to、bto、cc、 bcc 和 audience 字段。

收件箱的确定方法是先检索目标行为体的 JSON-LD 表示， 然后查找 inbox 属性。 如果接收方是 Collection 或 OrderedCollection，则服务端必须（使用用户的凭据）解引用该集合，并发现集合中每个条目的收件箱。 服务端必须限制通过集合执行的递归层数，该层数可以为一层。

服务端必须对最终接收方列表进行去重。服务端必须从接收方列表中排除与正在发起通知的活动的 actor（行为体）相同的行为体。 也就是说，行为体不应该将自己的活动投递给自己。

确定接收方列表后，服务端（使用提交用户的授权）向收件箱发出 HTTP POST 请求，并将活动作为请求正文。 接收方将此活动作为 item 添加到收件箱 的有序集合 (OrderedCollection) 中。 尝试向非联合式服务端上的收件箱进行投递应当导致 405 Method Not Allowed 响应。

对于向第三方服务端执行投递操作的联合式服务端，投递应当异步执行，且如果由于网络错误而投递失败，服务端应当 再次尝试向接收方投递。

注意：在同一来源的行为体之间分发的活动可以使用任何内部机制，并且不需要使用 HTTP。

7.2 创建活动 (Create Activity)

在 inbox 中接收 Create 活动几乎没有副作用；该活动应当出现在行为体的 inbox 中，且服务端可能会希望在本地存储此活动及其附带对象的表示形式。 然而，这通常在处理投递到 inbox 的活动时也会发生。

7.3 更新活动 (Update Activity)

对于服务端间交互，Update 活动意味着接收活动的服务端应当将其具有相同 id 的 object 副本更新为 Update 活动中提供的副本。 与 客户端到服务端处理更新活动 不同， 这不是部分更新，而是对象的完全替换。

接收服务端必须注意确保发起 Update 活动的行为体被授权修改目标 object。 这至少可以通过确保 Update 及其 object 具有相同的来源来完成。

7.4 删除活动 (Delete Activity)

接收此活动的副作用是（假设 object 被发送活动的行为体/服务端拥有），接收删除活动的服务端 应当删除其对具有相同 id 的 object 的表示形式，并且可以用 Tombstone 对象替换该表示形式。

（请注意，在活动从源服务端传输到外站服务端后，ActivityPub 协议中没有任何内容可以强制远程删除对象的表示形式）。

7.5 关注活动 (Follow Activity)

在收件箱中接收此活动的副作用是，服务端应当生成一个 Accept 或 Reject 活动， 其中 Follow 作为 object，并将其投递到发出 Follow 的 actor。 Accept 或 Reject 可以自动生成，也可以是用户输入的结果（可能在用户进行审核后有所延迟）。 尽管如此，服务端可以选择不显式发送 Reject 以响应该 Follow， 实现者应当意识到发送请求的服务端可能会处于中间状态。例如，服务端可能不会发送 Reject 以保护用户的隐私。

如果接收到引用此 Follow 为对象的 Accept，服务端应当将 actor 添加到目标行为体的粉丝集合中。 如果接收到的活动是 Reject，服务端禁止将发送Follow活动的行为体添加到目标行为体的粉丝集合中。

7.6 接受活动 (Accept Activity)

在收件箱中接收此活动的副作用取决于接收到的 object 的类型，并且可以接受本文档中未描述的类型（例如，Offer）。

如果向收件箱接收的 Accept 的 object 是接收方先前发送的 Follow 活动， 则服务端应当将 actor 添加到接收方的关注集合。

7.7 拒绝活动 (Reject Activity)

在收件箱中接收此活动的副作用取决于接收到的 object 的类型，并且可以拒绝本文档中未描述的类型（例如， Offer）。

如果向收件箱接收的 Reject 的 object 是接收方先前发送的 Follow 活动， 则表示接收方未批准 Follow 请求。服务端禁止将 actor 添加到接收方的关注集合。

7.8 添加活动 (Add Activity)

在收件箱收到 Add 活动后，服务端应当将 object 添加到 target 属性中指定的集合，除非：

• target 不由接收服务端所有，因此服务端无法更新 target。
• 由于某种其他原因，不允许将 object 添加到 target 集合， 这由接收方自行决定。

7.9 移除活动 (Remove Activity)

在收件箱收到 Remove 活动后，服务端应当从 target 属性中指定的集合中移除 object，除非：

• target 不由接收服务端所有，因此服务端无法更新 target。
• 由于某种其他原因，不允许从 target 集合中移除 object，这由接收方自行决定。

7.10 点赞活动 (Like Activity)

在收件箱中收到此活动的副作用是，如果存在 likes 集合， 则服务端应当通过将接收到的活动添加到该集合来增加目标对象的点赞计数。

7.11 推送（分享）活动 (Announce Activity)

在收件箱中接收到 Announce 活动后，如果存在 shares集合，则服务端应当通过将接收到的活动添加到该集合来增加对象的分享计数。

7.12 撤销活动 (Undo Activity)

Undo 活动用于撤销先前活动的副作用。 请参阅 ActivityStreams 文档中关于 逆活动与“撤销”的内容。 Undo 活动的范围和限制与 客户端到服务端交互场景下的撤销活动相同，但应用于联合上下文。