gotosocial/docs/locales/zh/admin/federation_modes.md
cdn0x12 4d6408015b [docs/zh] Update zh docs: synced to 6c879186 (#4117)
# Description

This PR updates the Chinese documentation to 6c879186 (the latest commit at present).

It also fixed a small typo in the original docs. Since the change is so minor, I didn't make a separate PR.

Last docs/zh update PR: #3884

## Checklist

Please put an x inside each checkbox to indicate that you've read and followed it: `[ ]` -> `[x]`

If this is a documentation change, only the first checkbox must be filled (you can delete the others if you want).

- [x] I/we have read the [GoToSocial contribution guidelines](https://codeberg.org/superseriousbusiness/gotosocial/src/branch/main/CONTRIBUTING.md).

Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4117
Co-authored-by: cdn0x12 <git@cdn0x12.dev>
Co-committed-by: cdn0x12 <git@cdn0x12.dev>
2025-05-03 09:28:16 +00:00

4.3 KiB

联合模式

GoToSocial 当前提供“黑名单”和“白名单”联合模式,可以通过在 config.yaml 中设置 instance-federation-mode,或者使用环境变量 GTS_INSTANCE_FEDERATION_MODE 来配置。这些模式如下所述。

黑名单联合模式(默认)

instance-federation-mode 设置为 blocklist 时,你的实例将与其他实例自由联合,没有限制,但你在设置面板中明确创建的屏蔽的实例除外。

当你的实例收到来自不在黑名单内的实例的新请求时,如果请求有效,并且请求者被允许查看所请求的资源(考虑贴文的可见性和任何用户级屏蔽),实例将处理该请求。

当你的实例遇到它以前未见过的贴文或账户的提及或公告时,如果该资源的域未通过域屏蔽条目被屏蔽,它将会去获取该资源。

!!! info "附注" 黑名单联合模式是 GoToSocial 的默认联合模式。它也是大多数其他 ActivityPub 服务器实现的默认联合模式。

白名单联合模式

!!! warning "警告" 白名单联合模式仍然被认为是“实验性”的,我们正在研究其在实际中的表现。它应该如其名称所示,但可能会在其他地方导致错误或出现边缘情况,我们还不确定!

instance-federation-mode 设置为 allowlist 时,你的实例将仅与通过设置面板明确设为允许的实例联合,并限制任何未被允许的实例的访问。

当你的实例收到来自白名单之外实例的新请求时,它将拒绝处理该请求。如果请求来自白名单中的域名,你的实例将处理该请求(考虑贴文的可见性和任何用户级别的屏蔽)。

当你的实例遇到它以前未见过的贴文或账户的提及或公告时,它只会在资源所属域名被明确允许时才去获取资源。

!!! tip "提示" 白名单联合模式在你希望仅与选择的“可信”实例联合的情况下非常有用。然而,这会影响发现过程。在黑名单联合模式下,你会通过转发和回复自然地遇到未知实例的贴文和账户,但在白名单联合模式下,这样的偶然发现不会发生。

因此,建议你要么先从黑名单联合模式开始,然后在确定喜欢哪些其他实例后切换到白名单联合模式,要么从白名单联合模式开始,并在首次启动实例后准备好并导入白名单,以便“启动”它。

结合屏蔽与允许

!!! danger "危险" 结合屏蔽和允许是一项棘手的工作!

在导入白名单和黑名单时,你应该始终手动审核列表,以确保不会无意中屏蔽你不想屏蔽的实例,因为这可能带来 **非常令人困扰的副作用** ,例如关注/粉丝关系的移除、贴文的删除等。

有疑问时,请始终首先显式添加白名单条目作为保险策略!

同时屏蔽和允许同一个域名是合法的,而这两个操作结合之后的效果取决于你的实例目前正在使用哪种联合模式,具体如下所述,你可以在下面找到流程图。

在黑名单模式下

如下图所示,在黑名单模式下(图的左侧),显式添加允许条目可以用来覆盖域名屏蔽。

这在你从其他人处导入黑名单,但导入的黑名单中包含了一些你实际上不想屏蔽的实例时很有用。为了避免屏蔽这些实例,你可以先为这些实例显式创建允许条目。然后,当你导入黑名单时,显式允许的域将不会被屏蔽,并且创建屏蔽所导致的副作用(删除贴文、媒体、关系等)将不会被处理。

如果你以后移除对于同时存在屏蔽的域的显式允许,该实例将被屏蔽,并且将处理屏蔽创建的相关影响。

相反,如果你为被屏蔽的域添加显式允许,将处理解除屏蔽的相关影响。

在白名单模式下

如下图所示,在白名单模式下(图的右侧),显式域名屏蔽条目会优先于显式域名允许条目。在运行白名单模式时,必须满足以下两个条件才能允许一个实例通过:

  1. 实例没有存在对应的显式域名屏蔽。
  2. 实例存在对应的显式域名允许。

如果上述任何条件不满足,请求将被拒绝。

展示两种联合模式分别如何处理入站请求的流程图