diff options
Diffstat (limited to 'docs/locales/zh/federation/posts.md')
| -rw-r--r-- | docs/locales/zh/federation/posts.md | 522 |
1 files changed, 2 insertions, 520 deletions
diff --git a/docs/locales/zh/federation/posts.md b/docs/locales/zh/federation/posts.md index 0cb2ca02a..61a040f07 100644 --- a/docs/locales/zh/federation/posts.md +++ b/docs/locales/zh/federation/posts.md @@ -217,527 +217,9 @@ GoToSocial 在解析传入的 `Object` 时使用 `content` 和 `contentMap` 属 ## 互动规则 -GoToSocial 使用 `interactionPolicy` 属性告知外站给定帖文允许的互动类型（有前提）。 +GoToSocial 在帖文中使用 `interactionPolicy` 属性，以向外站实例描述对于任何给定的帖子，哪些类型的互动在条件允许的情况下可以被原始服务器处理和存储。 -!!! danger "危险" - - 互动规则旨在限制用户贴文上用户不希望的回复和其他互动的有害影响（例如，“回复家(reply guys)” —— 不请自来地发表冒失回复的人）。 - - 然而，这远远不能满足这一目的，因为仍然有许多“额外”方式可以分发或回复贴文，进而超出用户的初衷或意图。 - - 例如，用户可能创建一个附有非常严格互动规则的贴文，却发现其他服务器软件不尊重该规则，而其他实例上的用户从他们的实例视角进行讨论并回复该贴文。原始发布者的实例将自动从视图中删除这些用户不想要的互动，但外站实例可能仍会显示它们。 - - 另一个例子：有人可能会看到一个指定没人可以回复的贴文，但截屏该贴文，将截屏作为新帖文发布，并将提及原作者或只是附上原贴文的 URL。在这种情况下，他们成功通过新创建的贴文串来达到“回复”该贴文的目的。 - - 无论好坏，GoToSocial 只能为这一部分问题提供尽最大努力的部分技术解决方案，这更多的是一个社会行为和边界的问题。 - -### 概述 - -`interactionPolicy` 是贴文类 `Object`（如 `Note`、`Article`、`Question` 等）附带的一个属性，其格式如下： - -```json -{ - [...], - "interactionPolicy": { - "canLike": { - "always": [ "始终可进行此操作的零个或多个 URI" ], - "approvalRequired": [ "需要批准才能进行此操作的零个或多个 URI" ] - }, - "canReply": { - "always": [ "始终可进行此操作的零个或多个 URI" ], - "approvalRequired": [ "需要批准才能进行此操作的零个或多个 URI" ] - }, - "canAnnounce": { - "always": [ "始终可进行此操作的零个或多个 URI" ], - "approvalRequired": [ "需要批准才能进行此操作的零个或多个 URI" ] - } - }, - [...] -} -``` - -在此对象中： - -- `canLike` 指定可创建 `Like` 并将帖文 URI 作为 `Like` 的 `Object` 的人。 -- `canReply` 指定可创建 `inReplyTo` 设置为帖文 URI 的帖文的人。 -- `canAnnounce` 指定可创建 `Announce` 并将帖文 URI 作为 `Announce` 的 `Object` 的人。 - -并且： - -- `always` 是一个 ActivityPub URI/ID 的 `Actor` 或 `Actor` 的 `Collection`，无需 `Accept` 即可进行互动分发到其粉丝。 -- `approvalRequired` 是一个 ActivityPub URI/ID 的 `Actor` 或 `Actor` 的 `Collection`，可以互动，但在将互动分发给其粉丝之前需要获得 `Accept`。 - -`always` 和 `approvalRequired` 的有效 URI 条目包括 magic ActivityStreams 公共 URI `https://www.w3.org/ns/activitystreams#Public`，贴文创建者的 `Following` 和/或 `Followers` 集合的 URI，以及个人请求体的 URI。例如： - -```json -[ - "https://www.w3.org/ns/activitystreams#Public", - "https://example.org/users/someone/followers", - "https://example.org/users/someone/following", - "https://example.org/users/someone_else", - "https://somewhere.else.example.org/users/someone_on_a_different_instance" -] -``` - -### 指定无人能进行的操作 - -!!! note "注意" - 即使规则指定无人可互动，GoToSocial 仍做出默认假设。参见[默认假设](#默认假设)。 - -空数组或缺少/空的键表示无人能进行此互动。 - -例如，以下 `canLike` 指定无人能 `Like` 该贴文： - -```json -"canLike": { - "always": [], - "approvalRequired": [] -}, -``` - -类似的，`canLike` 值为 `null` 也表示无人能 `Like` 该帖： - -```json -"canLike": null -``` - -或 - -```json -"canLike": { - "always": null, - "approvalRequired": null -} -``` - -缺失的 `canLike` 值同样表达了相同的意思： - -```json -{ - [...], - "interactionPolicy": { - "canReply": { - "always": [ "始终可进行此操作的零个或多个 URI" ], - "approvalRequired": [ "需要批准才能进行此操作的零个或多个 URI" ] - }, - "canAnnounce": { - "always": [ "始终可进行此操作的零个或多个 URI" ], - "approvalRequired": [ "需要批准才能进行此操作的零个或多个 URI" ] - } - }, - [...] -} -``` - -### 冲突/重复值 - -在用户位于集合 URI 中, 且也通过 URI 被显式指定的情况下，**更具体的值**优先。 - -例如： - -```json -[...], -"canReply": { - "always": [ - "https://example.org/users/someone" - ], - "approvalRequired": [ - "https://www.w3.org/ns/activitystreams#Public" - ] -}, -[...] -``` - -在此情形下，`@someone@example.org` 位于 `always` 数组中，并且也存在于 `approvalRequired` 数组中的 magic ActivityStreams 公共集合中。在这种情况下，他们可以始终回复，因为 `always` 值更为明确。 - -另一个例子： - -```json -[...], -"canReply": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [ - "https://example.org/users/someone" - ] -}, -[...] -``` - -在此，`@someone@example.org` 位于 `approvalRequired` 数组中，但也隐含地存在于 `always` 数组中的 magic ActivityStreams 公共集合中。在这种情况下，除了 `@someone@example.org` 需要批准外，其他人都可以无需批准进行回复。 - -在相同 URI 存在于 `always` 和 `approvalRequired` 两者中时，**最高级别的权限**优先（即 `always` 中的 URI 优先于 `approvalRequired` 中的相同 URI）。 - -### 默认假设 - -GoToSocial 对 `interactionPolicy` 做出若干默认假设。 - -**首先**，无论贴文的可见性和 `interactionPolicy` 如何，被[提及](#提及)或回复的用户应**始终**能够回复该贴而无需批准，**除非**提及或回复他们的贴文本身正在等待批准。 - -这是为了防止潜在的骚扰者在辱骂贴文中提及某人，并不给被提及的用户任何回复的机会。 - -因此，当发送互动规则时，GoToSocial 始终将提及用户的 URI 添加到 `canReply.always` 数组中，除非它们已被 magic ActivityStreams 公共 URI 覆盖。 - -同样，在执行接收到的互动规则时，即使用户 URI 不存在于 `canReply.always` 数组中，GoToSocial 也将被提及用户的 URI 视作已存在。 - -**其次**，用户应**始终**能够回复自己的贴文，点赞自己的贴文，并转发自己的贴文而无需批准，**除非**该贴文本身正在等待批准。 - -因此，当发送互动规则时，GoToSocial 始终将贴文作者的 URI 添加到 `canLike.always`、`canReply.always` 和 `canAnnounce.always` 数组中，除非它们已被 magic ActivityStreams 公共 URI 覆盖。 - -同样，在执行接收到的互动规则时，即使贴文作者 URI 不存在于这些 `always` 数组中，GoToSocial 也始终将贴文作者 URI 视为已存在。 - -### 默认值 - -当贴文上没有 `interactionPolicy` 属性时，GoToSocial 会根据贴文可见级别和发帖作者为该帖假定默认的 `interactionPolicy`。 - -对于 `@someone@example.org` 的**公开**或**未列出**贴文，默认 `interactionPolicy` 为： - -```json -{ - [...], - "interactionPolicy": { - "canLike": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - }, - "canReply": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - }, - "canAnnounce": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - } - }, - [...] -} -``` - -对于 `@someone@example.org` 的**仅限粉丝**贴文，假定的 `interactionPolicy` 为： - -```json -{ - [...], - "interactionPolicy": { - "canLike": { - "always": [ - "https://example.org/users/someone", - "https://example.org/users/someone/followers", - [...提及的用户的 URI...] - ], - "approvalRequired": [] - }, - "canReply": { - "always": [ - "https://example.org/users/someone", - "https://example.org/users/someone/followers", - [...提及的用户的 URI...] - ], - "approvalRequired": [] - }, - "canAnnounce": { - "always": [ - "https://example.org/users/someone" - ], - "approvalRequired": [] - } - }, - [...] -} -``` - -对于 `@someone@example.org` 的**私信**贴文，假定的 `interactionPolicy` 为： - -```json -{ - [...], - "interactionPolicy": { - "canLike": { - "always": [ - "https://example.org/users/someone", - [...提及的用户的 URI...] - ], - "approvalRequired": [] - }, - "canReply": { - "always": [ - "https://example.org/users/someone", - [...提及的用户的 URI...] - ], - "approvalRequired": [] - }, - "canAnnounce": { - "always": [ - "https://example.org/users/someone" - ], - "approvalRequired": [] - } - }, - [...] -} -``` - -### 示例 1 - 限制对话范围 - -在此示例中，用户 `@the_mighty_zork` 想开始与用户 `@booblover6969` 和 `@hodor` 之间的对话。 - -为了避免讨论被他人打断，他们希望来自三名参与者以外的用户的回复仅在获得 `@the_mighty_zork` 批准后才被允许。 - -此外，他们希望将贴文转发/`Announce` 的权利限制为仅限于他们自己的粉丝和三个对话参与者。 - -然而，任何人都可以 `Like` `@the_mighty_zork` 的贴文。 - -这可以通过以下 `interactionPolicy` 来实现，它附加在可见性为公开的帖文上： - -```json -{ - [...], - "interactionPolicy": { - "canLike": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - }, - "canReply": { - "always": [ - "https://example.org/users/the_mighty_zork", - "https://example.org/users/booblover6969", - "https://example.org/users/hodor" - ], - "approvalRequired": [ - "https://www.w3.org/ns/activitystreams#Public" - ] - }, - "canAnnounce": { - "always": [ - "https://example.org/users/the_mighty_zork", - "https://example.org/users/the_mighty_zork/followers", - "https://example.org/users/booblover6969", - "https://example.org/users/hodor" - ], - "approvalRequired": [] - } - }, - [...] -} -``` - -### 示例 2 - 长独白贴文串 - -在此示例中，用户 `@the_mighty_zork` 想写一个长篇独白。 - -他们不介意别人转发和点赞贴文，但不想收到任何回复，因为他们没有精力去管理讨论；他们只是想通过发泄自己的想法去表达自我。 - -这可以通过在贴文串中的每个贴文上设置以下 `interactionPolicy` 来实现： - -```json -{ - [...], - "interactionPolicy": { - "canLike": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - }, - "canReply": { - "always": [ - "https://example.org/users/the_mighty_zork" - ], - "approvalRequired": [] - }, - "canAnnounce": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - } - }, - [...] -} -``` - -在这里，任何人都可以点赞或转发，但无人能够回复（除了 `@the_mighty_zork` 自己）。 - -### 示例 3 - 完全开放 - -在此示例中，`@the_mighty_zork` 想写一篇完全开放的贴文，任何能看到此帖的人都可以进行回复、转发或点赞（即解锁和公开贴文默认行为）： - -```json -{ - [...], - "interactionPolicy": { - "canLike": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - }, - "canReply": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - }, - "canAnnounce": { - "always": [ - "https://www.w3.org/ns/activitystreams#Public" - ], - "approvalRequired": [] - } - }, - [...] -} -``` - -### 请求、获得和验证批准 - -当用户的 URI 在需要获得批准的互动的 `approvalRequired` 数组中时，如果他们希望获得批准以分发互动，应该执行以下步骤： - -1. 像往常一样撰写互动 `Activity`（即 `Like`、`Create` （回复）或 `Announce`）。 -2. 像往常一样将 `Activity` 的 `to` 和 `cc` 地址设为预期的收件人。 -3. 将 `Activity` **仅**发送到要互动帖的作者的 `Inbox`（或 `sharedInbox`）。 -4. **此时不要进一步分发 `Activity`**。 - -此时，互动可视为等待批准，并不应该显示在被互动的贴文的回复或点赞集合等中。 - -可以向发送互动的用户显示“互动待批准”状态，但理想情况下不应该向与该用户共享实例的其他用户显示。 - -从这里开始，可能会出现以下三种情况之一： - -#### 拒绝 - -在这种情况下，互动目标贴文的作者发回一个 `Reject` `Activity`，该活动的 `Object` 属性带有待拒绝互动活动的 URI/ID。 - -例如，以下 JSON 对象 `Reject` 了 `@someone@somewhere.else.example.org` 回复 `@post_author@example.org` 贴文的尝试： - -```json -{ - "@context": "https://www.w3.org/ns/activitystreams", - "actor": "https://example.org/users/post_author", - "to": "https://somewhere.else.example.org/users/someone", - "id": "https://example.org/users/post_author/activities/reject/01J0K2YXP9QCT5BE1JWQSAM3B6", - "object": "https://somewhere.else.example.org/users/someone/statuses/01J17XY2VXGMNNPH1XR7BG2524", - "type": "Reject" -} -``` - -如果发生这种情况，`@someone@somewhere.else.example.org`（及其实例）应视交互为被拒绝。该实例应从其内部存储（即数据库）中删除该活动，或以其他方式表明它已被拒绝，并且不应进一步分发该 `Activity` 或重试该交互。 - -#### 无响应 - -在这种情况下，正在互动的贴文的作者从不发送 `Reject` 或 `Accept` `Activity`。在这种情况下，交互被视为永久“待处理”。实例可能希望实现某种清理功能，达到一定时间期限的已发送且待处理交互应被视为过期，然后按照上述方式被处理为 `Rejected` 并删除。 - -#### 接受 - -在这种情况下，正在互动的贴文的作者发回一个`Accept` `Activity`，该活动的 `Object` 属性带有待批准互动活动的 URI/ID。 - -例如，以下 JSON 对象 `Accept` 了 `@someone@somewhere.else.example.org` 回复 `@post_author@example.org` 贴文的尝试： - -```json -{ - "@context": "https://www.w3.org/ns/activitystreams", - "actor": "https://example.org/users/post_author", - "cc": [ - "https://www.w3.org/ns/activitystreams#Public", - "https://example.org/users/post_author/followers" - ], - "to": "https://somewhere.else.example.org/users/someone", - "id": "https://example.org/users/post_author/activities/accept/01J0K2YXP9QCT5BE1JWQSAM3B6", - "object": "https://somewhere.else.example.org/users/someone/statuses/01J17XY2VXGMNNPH1XR7BG2524", - "type": "Accept" -} -``` - -如果发生这种情况，`@someone@somewhere.else.example.org`（及其实例）应视为交互已被批准/接受。然后，该实例可以自由地将此交互 `Activity` 分发给所有由 `to`、`cc` 等目标的接收者，并附加属性 `approvedBy`。 - -### 验证在粉丝/关注中是否存在 - -如果一个 `Actor` 在其互动规则的 `always` 字段中因为存在于 `Followers` 或 `Following` 集合中而被允许进行交互（例如 `Like`、`inReplyTo` 或 `Announce`），则其服务器仍应等待来自目标帐户服务器的 `Accept`，然后才更广泛地分发交互，并将 `approvedBy` 属性设置为 `Accept` 的 URI。 - -这样可以防止第三方服务器被迫以某种方式验证互动的 `Actor` 是否存在于接收互动的用户的 `Followers` 或 `Following` 集合中。让目标服务器进行验证，并采信其 `Accept` ，将其视为交互 `Actor` 存在于相关集合中的证明，更为简单。 - -同样，当接收到一个具有匹配 `Following` 或 `Followers` 集合的 `Actor` 的互动请求时，接收互动的 `Actor` 的服务器应确保尽快发送出 `Accept`，以便交互 `Actor` 服务器可以带着适当的接受证明发送出 `Activity`。 - -这个过程应绕过通常的“待批准”阶段，因此没有必要通知 `Actor` 待批准的交互，因为他们已明确同意。在 GoToSocial 代码库中，这被称为“预批准”。 - -### `approvedBy` - -`approvedBy` 是一个附加属性，添加到 `Like` 和 `Announce` 活动以及任何被视为“贴文”的 `Object`（如 `Note`、`Article`）中。 - -`approvedBy` 的存在表明贴文的作者接受了由 `Activity` 作为目标或由 `Object` 所回复的互动，并现在可以分发给其预期观众。 - -`approvedBy` 的值应为创建 `Accept` `Activity` 的接收交互贴文作者的 URI。 - -例如，以下 `Announce` `Activity` 的 `approvedBy` 表示它已被 `@post_author@example.org` `Accept`： - -```json -{ - "actor": "https://somewhere.else.example.org/users/someone", - "to": [ - "https://somewhere.else.example.org/users/someone/followers" - ], - "cc": [ - "https://example.org/users/post_author" - ], - "id": "https://somewhere.else.example.org/users/someone/activities/announce/01J0K2YXP9QCT5BE1JWQSAM3B6", - "object": "https://example.org/users/post_author/statuses/01J17ZZFK6W82K9MJ9SYQ33Y3D", - "approvedBy": "https://example.org/users/post_author/activities/accept/01J18043HGECBDZQPT09CP6F2X", - "type": "Announce" -} -``` - -接收到一个带有 `approvedBy` 值的 `Activity` 时，外站实例应解引用字段的 URI 值以获取 `Accept` `Activity`。 - -然后，他们应验证 `Accept` `Activity` 的 `object` 值是否等于交互 `Activity` 或 `Object` 的 `id`，并验证 `actor` 值是否等于接收交互的贴文的作者。 - -此外，他们应确保解引用的 `Accept` 的 URL 域名等于接收交互贴文的作者的 URL 域名。 - -如果无法解引用 `Accept` 或未通过有效性检查，则交互应被视为无效并丢弃。 - -由于这种验证机制，实例应确保他们对涉及 `interactionPolicy` 的 `Accept` URI 的解引用响应提供一个有效的 ActivityPub 对象。如果不这样做，他们会无意中限制外站实例分发其贴文的能力。 - -### 后续回复/范围扩展 - -对话中的每个后续回复将有其自己的互动规则，由创建回复的用户选择。换句话说，整个*对话*或*贴文串*并不由一个 `interactionPolicy` 控制，而是贴文串中的每个后续贴文可以由贴文作者设置不同的规则。 - -不幸的是，这意味着即使有 `interactionPolicy`，贴文串的范围也可能不小心超出第一个贴文作者的意图。 - -例如，在上述[示例 1](#示例-1---限制对话范围)中，`@the_mighty_zork` 在第一个贴文中指定了 `canReply.always` 值为 - -```json -[ - "https://example.org/users/the_mighty_zork", - "https://example.org/users/booblover6969", - "https://example.org/users/hodor" -] -``` - -在后续回复中，`@booblover6969` 无意或有意地将 `canReply.always` 值设为： - -```json -[ - "https://www.w3.org/ns/activitystreams#Public" -] -``` - -这扩大了对话的范围，因为现在任何人都可以回复 `@booblover6969` 的贴文，并可能也在该回复中标记 `@the_mighty_zork`。 - -为了避免这个问题，建议外站实例防止用户能够扩大范围（具体机制待定）。 - -同时，实例应将任何与仍处于待批准状态的贴文或贴文类似的 `Object` 的交互视作待批准。 - -换句话说，只要某条贴文处于待批准状态，实例应将该贴文下的所有互动标记为待批准，无论此贴文的互动规则通常允许什么。 - -这可避免有用户回复贴文，且在回复尚未得到批准的情况下继续回复*他们自己的回复*并将其标记为允许（作为贴文回复的作者，他们默认拥有对贴文回复的[回复权限](#默认假设)）。 +有关更多详细信息，请参阅单独的 [互动规则](./interaction_policy.md) 文档。 ## 投票 |