作者：ATProtocol. 编译：Cointime：QDD.

在四月份，我们向所有用户推出了一个屏蔽功能。与其他中心化平台不同，Bluesky上的屏蔽是公开的可枚举数据，因为网络中的所有服务器都需要知道它们的存在，以便尊重用户的请求。

当前的公开屏蔽系统只是我们在测试期间积极构建的可组合式审查堆栈的一个方面。我们正在努力开发更复杂的个人和社区级互动控制和审查工具，并且我们鼓励第三方社区开发者为这个生态系统做出贡献。

在本文中，我们将分享公开屏蔽的技术实现，并讨论一些可能的更隐私保护型屏蔽实现的可能性——这是一个正在进行研究和实验的领域。我们欢迎社区提供建议，如果您在阅读本文后有关于如何实现私密屏蔽的提案，请在我们的公共讨论区做出贡献。

什么是屏蔽？

在许多社交媒体平台上，两个帐户之间的屏蔽通常具有以下特点：

对称性：无论哪个帐户首先进行了屏蔽，行为都是相同的。

相互静音：无论在登录状态下还是在登录状态下，两个帐户都无法阅读对方的任何内容（公开或私密）。

相互互动屏蔽：不允许两个帐户之间的直接互动。这包括直接提及导致通知的情况、对帖子的回复、直接消息（DM）和关注（通常会导致通知）。

屏蔽增加了相当大程度的阻力。在许多情况下，仅靠这种阻力就足以缓解冲突。

然而，需要注意的是，屏蔽并不能完全阻止所有可能的互动（即使在中心化社交网络上也是如此）。例如，当内容是公开的，就像在Bluesky、博客或网站上一样，被屏蔽的人仍然可以通过简单地注销或在隐身浏览器标签中打开来轻松访问内容。帖子仍然可以被截屏并在网络内外分享。即使没有直接提及或回复（"subtweeting"，发布屏幕截图等），骚扰仍然可能继续发生。

在大多数现有服务上，被屏蔽的人可以检测到他们已被屏蔽，尽管可能并不明显。例如，如果他们能够导航到屏蔽者的个人资料，他们可能会看到一个显示他们已被屏蔽的屏幕，或者个人资料的缺失足以表明他们已被屏蔽。大多数社交应用程序都为每个用户提供了一个屏蔽的帐户列表。

您可以阅读有关其他平台上屏蔽行为的更多信息：

Twitter

Mastodon

Instagram

在Bluesky中如何实现屏蔽？

屏蔽会阻止互动。被屏蔽的帐户将无法对您的帖子点赞、回复、提及或关注，如果他们直接访问您的个人资料，他们将看到他们已被屏蔽。与其他公开社交网络一样，如果他们注销帐户或使用不同的帐户，他们仍然可以查看您的内容。（这在中心化社交网络上也是标准做法。）

目前，在Bluesky上，您可以查看您屏蔽的帐户列表，而屏蔽您的人的列表则不会在应用程序中显示出来，但熟悉API的开发者可以遍历网络以解析此信息。本节将深入探讨导致屏蔽公开的技术限制，并在稍后的部分中讨论可能的替代实现方法。

在Bluesky中，屏蔽是作为app.bsky.*应用程序协议的一部分实现的，该协议建立在基础的AT协议（atproto）之上。屏蔽是存储在帐户存储库中的一条记录。它们的外观和行为与“关注”非常相似：app.bsky.graph.block和app.bsky.graph.follow的记录模式几乎相同。

然后，通过几个软件部件来实现屏蔽行为。服务器和客户端将索引屏蔽记录，并阻止违反预期行为的操作：帖子不会出现在动态和回复线程中；个人资料获取将为空或带有屏蔽状态的注释；阻止创建回复帖子、引用帖子、嵌入和提及；还会额外禁止涉及其他帐户的任何通知。

AT协议的核心原则之一是帐户持有者对自己的数据拥有完全控制权。这意味着，虽然符合协议的客户端和服务器会阻止被屏蔽的帐户在每个用户的数据存储库中创建回复或其他不允许的记录，但如果客户端拒绝遵守协议，仍然可以绕过这些限制。屏蔽行为本身也不会导致被屏蔽者的存储库发生任何变化，任何旧的回复或提及仍然保持原样。例如，在用户界面的应用程序中，如果有人对您的帖子进行回复，然后您屏蔽他们，他们的回复将对您隐藏。如果以后决定取消屏蔽，他们对该帖子的回复将再次显示，因为回复本身并没有被删除。

尽管屏蔽不会删除其他用户存储库中的内容，但数据不会显示，因为屏蔽主要由其他节点和服务（个人数据服务器、应用程序视图和客户端）强制执行。由此架构产生的一个副作用是，由于屏蔽状态的更改，关注关系不会发生变化，“软屏蔽”（快速屏蔽/取消屏蔽）无法作为移除关注者的机制。虽然关注关系可能仍然存在于图形中，但屏蔽会阻止任何实际的内容查看或交付。作为未来的工作，我们还可以确保在屏蔽状态更改时更新诸如“点赞”计数和“关注者”帐户之类的详细信息。

屏蔽如何在开放联邦系统中工作？

Bluesky是一个建立在支持公开对话的协议上的公共社交网络，所以与博客和网站一样，您不需要Bluesky帐户就可以查看发布到应用程序的内容。为了支持多个服务器、客户端和应用程序视图的开放联邦，每个帐户的数据存储库（包含关注和屏蔽等信息）必须是公开的。整个网络中的所有服务器都必须能够读取这些数据。服务器必须知道您屏蔽了哪些帐户，以便能够执行该关系。

一旦我们启动联邦，将会有许多个人数据服务器（PDS）、客户端和应用程序视图。预期的是几乎所有帐户都将使用尊重屏蔽行为的客户端和服务器。

正是这种需要多个参与方协调的需求，导致屏蔽必须是公开的。 "静音"行为可以完全在客户端应用程序中实现，因为它只影响本地帐户持有者的视图。屏蔽需要其他参与方（可能是敌对方）的协调和执行，因为涉及到多个（可能是敌对方）的视图和操作。

理论上，一个恶意行为者可以创建自己的不合规的客户端或界面，忽略某些屏蔽行为，因为内容是发布到公共网络上的。但是，向创建屏蔽的人显示内容或通知将是不可能的，因为该行为受到他们自己的PDS和客户端的控制。从技术上讲，恶意客户端可以创建回复和提及，但出于同样的原因，这些回复将是不可见的或至少影响较小。生态系统中符合协议的软件将使这样的内容对网络上的其他帐户不可见。如果有相当比例的帐户选择使用不符合协议的恶意基础架构，我们将认为整个生态系统失败。

请记住，在大多数网络（无论是中心化还是非中心化）上，已经可能以巧妙的方式绕过屏蔽行为，关键是增加阻力。

在联邦系统中还有其他实现屏蔽的方法吗？

是的，我们正在积极探索其他实现方法和新颖的研究领域，以指导我们在AT协议上的开发。我们也欢迎社区对这个问题提出建议和讨论。

一个例子是ActivityPub，它是Mastodon所建立的协议。ActivityPub不需要公开的屏蔽，因为那里的内容默认情况下不是全局公开的——这也是为什么选择加入哪个服务器很重要，因为它限制了您所看到的内容。尽管如此，Mastodon有时会向其他方显示屏蔽信息，这在ActivityPub生态系统中是一个经常讨论的话题。

据我们目前了解，Mastodon上只有在帐户和服务器之间存在显式的关注关系时才会显示内容，并且关注需要相互同意。（实际上，大多数关注请求都是自动接受的，因此这种行为对最终用户来说并不总是明显的。）屏蔽所需的相互静音行为可以在Mastodon上实现，首先禁止两个帐户之间的任何关注，其次是添加常规的“静音”。与Bluesky类似，互动屏蔽行为依赖于服务器和客户端的执行。因此，在Mastodon上，恶意行为者实施一个忽略屏蔽并在线程中显示被屏蔽回复的服务器是有可能的。ActivityPub和AT协议都可以使用解除联邦作为强制机制，断开与不尊重屏蔽的服务器的连接。

我们考虑过用于私密屏蔽的技术方法

一种提议的机制是在Bluesky上使用布隆过滤器来减少屏蔽的公开性。基本思想是将屏蔽关系编码到统计数据结构中，并分发该数据结构而不是实际的屏蔽集合。数据结构可以轻松检查两个特定帐户之间是否存在屏蔽关系，但不容易列出所有的屏蔽。网络中的其他服务器和客户端将使用该数据结构来强制执行屏蔽行为。布隆过滤器可以是每个帐户（即存储在记录中的布隆过滤器），或者是每个PDS，或者是有效地全局的，其中个体PDS实例将屏蔽关系提交给可信的中央服务，该服务将发布布隆过滤器列表。在实现屏蔽之前，我们考虑过类似这样的方案，但存在一些问题和关切：

1. 布隆过滤器不能完全阻止枚举屏蔽，如果恶意行为者只对特定帐户感兴趣，他们仍然可以轻松找到被屏蔽帐户的列表。布隆过滤器只是添加了一个掩码，相对容易枚举屏蔽。尽管所有可能的屏蔽关系矩阵是NxN的（其中N是网络中帐户的数量，在未来可能达到数亿），可能太大而无法进行测试，但实际上，恶意行为者可能只针对知名帐户或特定社区。在这种情况下，只需要测试数十亿个可能关系，对于现代硬件来说将是微不足道的。

2. 布隆过滤器并不便宜。尽管布隆过滤器以高效地减少查找大量哈希的存储空间而闻名，但与单个哈希相比，它们有很大的开销。在屏蔽的上下文中，每次创建或删除屏蔽记录都可能需要生成和分发一个完整大小的布隆过滤器。在规模上，存储和带宽开销在大规模时变得显著，特别是因为大部分社交媒体帐户可能有数千个屏蔽。

3. 对于布隆过滤器开销的减轻存在延迟问题。上述存储和带宽问题可以通过“批处理”或通过一个可信的中央服务来减轻。但这些解决方案在延迟（网络范围内屏蔽生效所需的时间）、信任和可靠性（在中央服务中，它将拥有完整的屏蔽关系枚举）方面都存在问题。

我们的团队仍在积极讨论这个选项，并且可能额外的努力和资源是否值得布隆过滤器提供的不完美但额外的阻力。目前对我们来说还不完全明显，虽然我们目前正在迭代其他审查和帐户安全功能，但我们决定首先使用这个简单的公开系统发布屏蔽。

我们正在探索的其他提议包括：

标签为基础的屏蔽。不尝试阻止整个网络中违反屏蔽关系的所有行为，而是扫描并标记违反行为。

互动门控。将帖子线程和引用帖子的权威放在原始发布者的PDS中，因此不需要将屏蔽信息传递给其他服务器。

零知识证明。我们知道分布式屏蔽的现有零知识方法，比如SNARKBlock，并且正在与可信顾问讨论这个开放研究和实验领域。也许这项研究将会引导我们在未来部署一种新颖的系统。

可信的应用程序视图。帐户可以将他们的屏蔽关系私下注册到他们的PDS中，然后这些服务器将屏蔽元数据转发给少数“受祝福”的应用程序视图。

如果您在这方面有经验或对在分散系统中实现私密屏蔽关系有想法，请告诉我们。请在此处参与我们的讨论。