Ostrom 的研究中最让我感兴趣的一点是，她展示了社区治理的多样性：规则在表面上看起来混乱无序，但却有着同一套底层结构。更重要的是，她对社区如何自组织和自我治理的理解与当今的社交网络息息相关。在开放社交网络中，新型社区正在建立，人们也在积极尝试这些社区中的治理方式。
2025年11月在柏林举行的Eurosky会议上，技术专家 Robin Berjon 发表了一项声明，其中引用了 Ostrom 的观点，并将其与协议联系起来：“定义协议架构的属性与定义制度中规则的属性是相同的。”我认为这很大程度上是正确的，但我同时也认为我们可以更具体一些。
当今的开放社交网络主要由两个协议组成：ActivityPub和ATProto，它们对于如何组织在线社交生活有着截然不同的理念。两者都没有规定单一的网络拓扑结构，都将如何构建社交空间的基本选择权留给了在其之上进行构建的人。但是，它们的架构决策并非中立：它们塑造并限制了可能出现的拓扑结构、能够形成的社区类型以及这些社区可用的治理工具。
这种具体性至关重要，因为目前ActivityPub和ATProto上实际发生的事情，乍看之下似乎一片混乱。有数十种不同的应用程序、社区实验和治理安排，每一个都在边界划分和控制权归属上做出了不同的选择。但是，正如 Ostrom 发现社区治理系统的多样性可以归纳为若干共享的结构规则一样，开放社交网络的多样性也面临着一套共同的问题：成员资格始于何处、止于何处？谁制定规则？违规行为如何监控？以及有人违反协议时会发生什么？协议并不回答这些问题，但它们确实决定了哪些答案是可能存在的。
理解ActivityPub最简单的方式是：站点之间相互发送消息。一个站点上的人可以关注另一个站点上的人，当其中任何一人发布内容时，他们的站点会将该消息投递给另一方。然而，这种简单性掩盖了一个更深层的问题：站点实际上是用来做什么的？
在Mastodon的大部分历史中占据主导地位的答案是：站点就是基础设施。在2023年接受《The Verge》采访时，Mastodon创始人 Eugen Rochko 在描述产品时，将站点类比为一个实现细节。“把它想象成电子邮件，你就懂了。如果你不喜欢Gmail，你可以换成别的，但你不必完全放弃电子邮件这个概念。”当用户抱怨注册时必须选择站点时，Rochko 的回应是让这种选择消失：通过排序让大型站点显示在前面，添加“替我选择”按钮，并保持mastodon.social作为默认的导流入口。他承认这使Mastodon更接近他声称想要避免的Gmail问题，但将其框定为必要的，称：“可是，我这些年学到的是，拥有一个默认选项是无可替代的，对吧？”
在这种模式下，站点的边界是行政性的，而非社交性的。用户体验到一个单一的网络，理想情况下，他们永远不需要考虑自己的账户是位于这个站点还是那个站点上，站点只需保证正常运行时间、存储和审核执行。社交图谱自由地跨越站点边界延伸，主页信息流从各处抓取内容，使其感觉像是一个单一的网络。这种拓扑结构在功能上是中心化的，尽管其基础设施是分布式的。这解决了一些关于工程和权力分配的问题，但这样做并没有创造出独特的社交空间。
Mastodon目前的领导层正试图摆脱这种模式。他们的新任社区总监 Hannah Aubrey 将Mastodon描述为“一扇前门，而非整座房子”，并谈到了展示和支持其他站点，而不是将所有人都导入mastodon.social。总监 Felix Hlatky 已明确将分散mastodon.social的用户作为优先事项，并指出将用户集中在一个站点上“并非建立社交网络的目的”。这一目标雄心勃勃：从大约1万个站点增加到10万个，Hlatky 表示这“需要在‘创建站点意味着什么’这一问题上进行思维转变”。
在这个较新的模型中，站点边界变成了社交边界，你在Mastodon的体验理应由你加入的社区塑造，而不仅仅是由你在整个广阔网络中关注的人塑造。奥布里将站点启动者设想为“领导者和组织者”，他们希望为自己的社区建立某种东西，无论该社区是由语言、身份、地理位置还是共同兴趣定义的，她将价值主张框定为归属感：“你仍然可以以安全健康的方式与他人共处在一个社区中。”
这不再是一个拥有分布式基础设施的单一网络，而是一个网络的网络，其中每个节点都具有有意义的社交连贯性。Newsmast是一家总部位于英国的机构，正为出版商和社区构建ActivityPub基础设施，他们通过在各个站点社区之上创建品牌应用程序，将社区信息流与出版商的内容相结合，从而进一步推动了这一趋势。他们方法的逻辑结论是“每个社区都有属于自己的应用程序”，而联邦（federation）则是连接它们之间的组织。
Lemmy和PieFed是ActivityPub上类似Reddit的链接聚合平台，它们使情况进一步复杂化。社区（相当于子版块 subreddit）存在于站点上，但可以从其他站点访问，这就创造了双层社交边界：一个社区拥有自己的主题、自己的版主和自己的规范，但它同时也寄身于一个拥有自己的管理员和自己的审核政策的站点上。当来自一个站点的用户参与托管在另一个站点上的社区时，究竟适用谁的规范确实并不明确。站点边界和社区边界重叠却不重合，产生了一种无人完全弄清楚该如何治理的混合管辖拓扑结构。
（PieFed还有一个名为“话题”的功能，它将来自多个社区的帖子聚合到一个围绕单一主题的信息流中，这使得管辖权变成了一团令人愉悦的乱麻：一个帖子可以由站点A上的人发布，发到托管在站点B上的社区中，然后被聚合到托管在站点C上的话题里。当站点A、B和C之间的规则发生冲突时会发生什么，谁也说不清。）
这里的重点是，ActivityPub并不规定单一的拓扑结构。这个协议足够灵活，使得每个应用程序都能在“站点边界在社交层面上有多重要”这一问题上做出根本不同的选择。2023年左右的Mastodon将站点视为不可见的管道；2026年的Mastodon希望站点成为社区。PeerTube将其视为自托管视频库的制度容器，联邦只是次要功能。Lemmy将社区叠加在站点之上，创造了重叠的边界。
在ATProto中，每个用户都有一个个人数据服务器（PDS），以结构化记录的形式存储其内容，应用程序不托管这些数据，而是读取数据。其心智模型有点像一个共享的公共数据湖：每个PDS贡献其数据流，每个应用程序提取与其目的相关的子集。微博客应用程序读取帖子，视频应用程序读取视频记录，代码托管平台读取代码库，所有这些都通过不同的视角来自同一个数据池。ActivityPub以站点为社交单元进行组织，而ATProto则围绕数据进行组织。
Bluesky是构建在ATProto上的主导应用程序，对大多数用户来说，它就是一个类似Twitter的社交网络。Bluesky中的社区形成本应通过自定义信息流发生，Bluesky首席执行官 Jay Graber 将此框定为平台的核心创新。她在2023年写道：“算法，比内容类型或应用程序的外观更重要，它是社交媒体的核心，因为它指导你在那里如何分配注意力。”她描述Bluesky的目标是用开放的“算法市场”取代由单一公司控制的“主算法”。其措辞始终围绕着个人选择和控制：你看到什么、你滚动浏览什么、你订阅什么。Bluesky自己的常见问题解答明确指出了与Mastodon的对比：“在Mastodon上，你的实例或站点决定了你的社区……在Bluesky上，你的体验基于你关注的信息流和账户，且你始终可以参与全球对话。”
但社区不仅仅是一个注意力问题。信息流组织了个人所看到的内容，但没有创造共享空间、共享治理或共享成员资格。在Bluesky的默认实现中，你滚动浏览一个信息流，但你不属于它。信息流层面缺乏社区基础设施，这直接源于设计信息流的目的：它们是为了解决个人策展问题，而不是为了解决集体组织问题。不过，这也并非协议层面的限制，正如Blacksky的案例所证明的那样：当一个信息流被刻意构建为承载社区的基础设施时，它可以做到这一点，拥有专门的审核和明确的成员资格。但Bluesky提供的功能特性更倾向于推动被动消费模式，而非社区建设模式。
对于任何试图在ATProto上建立实际社区的人来说，这是一个问题。服务于Bluesky上黑人社区的Blacksky展示了实际需要付出什么代价。他们的方法是首先构建社区身份，从创建一个产生共享空间感的自定义信息流开始，然后逐步建立自己的PDS托管、审核系统、中继（relay）和应用视图（AppView）。他们的审核中继尤为重要，因为这意味着网络上的任何应用程序都可以接入Blacksky的审核，而不仅仅依赖Bluesky的审核；而他们最近在私密帖子方面的工作，代表了对ATProto默认“所有数据均为公开”这一假设的最明确背离，在协议假设开放的地方划出了封闭空间。
其他面向社区的应用程序也面临类似的紧张关系。Gander（加拿大）、Eurosky（欧盟）和Northsky（酷儿社区）各自针对特定人群，同时也保持全网络视野，目前尚不清楚这些应用在实践中将如何发展：究竟是社区身份还是全网络访问权将成为主要体验。它们正试图在一个被设计为无边界的协议之上创造有边界的社交空间。
还有一些应用程序根本不专注于创建社区空间，这些与创建社区空间无关领域可能才是ATProto架构最自然适用的地方。Tangled是一个带有社交功能的代码托管平台，比起Twitter，它更像GitHub。Margin.at允许用户在网页上撰写对其他用户可见的注释，这是一个有趣的反转，应用层跨越了整个网络，而ATProto在底层作为不可见的管道发挥作用。Germ是一款消息应用程序，它使用ATProto的身份系统（DID:PLC）进行用户身份验证，但其构建实际消息传递基础设施完全是在协议之外。Blento允许你创建个人网站，数据存储在你自己的PDS上。
虽然ATProto的架构倾向于拥有全球数据的扁平社交拓扑结构，但这并非硬性约束，它也可以被用来创建独特的社交空间。
这两个协议为社区形成创造了镜像般的问题：ActivityPub提供了边界，但使得从外部体验这些边界变得困难；而ATProto使得整个网络易于浏览，但根本不提供自然的边界。
在ActivityPub中，站点被设定为社区，但其架构并不支持社区实际形成所需的社交机制。你无法像走进一家街区酒吧那样去访问另一个站点或浏览不同社区的对话。虽然你可以跨越站点边界关注个人，但你无法在不提交身份的情况下存在于一个空间中。正如社会学家长期观察到的那样，社区往往通过“相遇”形成，通过在同一时间出现在同一地点并因邻近而发现共同兴趣。ActivityPub支持“关注”但不支持“在场”，站点边界虽然在理论上很重要，但这并非用户在实践中可以体验到的东西。
“站点即社区”的另一个挑战是，运营站点的人同时是基础设施管理员和社区领导者，而这两个是根本不同的角色，需要不同的技能。Hlatky 坦率地指出了现实：大多数启动站点的人“完全不知道审核意味着什么”。他们出身于技术背景，经历过垃圾邮件浪潮，然后逐渐发现运营站点伴随着什么责任。奥布里关于站点启动者作为“领导者和组织者”为社区建设东西的愿景，描述的是与实际运营站点的人不同的人群，而系统管理员技能与社区管理技能之间的重叠部分很小。Mastodon旨在降低站点托管技术门槛的计划可能会扩大而非缩小这一差距，因为瓶颈不在于运行Docker的技术复杂性，而在于培育社区的社交复杂性。
根据欧盟的《数字服务法案》，站点运营商可能是受监管的实体，在内容审核、透明度和用户保护方面负有合规义务。Mastodon自己最近的战略公告承认了这种紧张关系，承诺对“我们自己的站点”进行监管审计，并探索“如何与社区分享这些知识”。现在，运营Mastodon实例的人被期望集系统管理员、社区管家和合规服务提供商于一身。
跨站点互动问题展示了“站点即社区”模式的局限性。当站点B上的人回复站点A上的人，而站点A围绕内容警告和话题敏感度培养了特定规范时，站点B上的人从未接触过这些规范。站点A的管理员可以在事后做出反应，删除回复、屏蔽账户或完全与站点B断开联邦，但在互动发生之前，没有任何机制可以传达规范。没有大门可进，入口处也没张贴家规。在 Ostrom 的框架中，运作良好的制度要求参与者在行动前理解规则，要求监控是可能的，并且针对违规行为存在分级制裁。ActivityPub的“站点即社区”拥有制裁手段，但缺乏前置步骤：规则对局外人不可见，监控纯粹是反应性的，这意味着该制度拥有执法权，但没有构成权。
标准的反驳观点是，访问其他站点在技术上是勉强可行的：你可以通过网页界面浏览本站时间线，并关注特定社区的人。然而，技术上的可访问性与社交体验之间存在差异。本站时间线是一个原始的、按时间顺序排列的信息流，缺乏关于社区是什么、其规范是什么或其独特之处的上下文。我们可以将其与Reddit相比，在Reddit上，进入一个子版块会立即呈现社区的身份，将其作为一等界面元素：名称、描述、规则、版主、视觉标识。社区是一个可导航的对象，你可以遇到、评估并选择加入。在ActivityPub中，社区只是用户名上的元数据，即使你关注了一群来自同一个站点的人，他们的帖子也会出现在你的主页时间线上，与其他所有内容混在一起，社区背景被展示层剥离了。社区无法在聚合中幸存，因为界面没有保留它。
这并不意味着ActivityPub站点无法作为社区运作。有些确实可以，特别是当社区在站点出现之前就已经存在时：例如播客受众、现有论坛或一起迁移的专业网络。但在这些情况下，社区的凝聚是尽管有架构存在，而非因为架构支持，站点只是为已经在社交层面上真实存在的事物提供了基础设施。当架构不提供相遇机制时，通过“相遇”来建立社区（这是大多数社区实际形成的方式）要困难得多。
对于ATProto而言，社区栖身何处是一个更加开放的问题。在ActivityPub中，答案至少是明确的：社区栖身于站点。这个答案在结构上可能难以实现，但生态系统中的每个人对社区应该在哪里都有共同的理解。在ATProto中，不同的项目正在测试根本不同的答案，而协议本身对它们持中立态度。通过 Ostrom 的视角来看，问题变成了：这些答案中哪一个能真正产生具有清晰规则、有意义的监控和分级制裁的、运作良好的制度？
第一个候选者是信息流（feed）。Bluesky自己的框架将信息流定位为用户能动性的主要机制：一个算法市场取代单一的算法，赋予个人控制自己注意力的权力。但正如Bluesky的FAQ所表明的那样，设计优先级是参与“全球对话”，信息流只是这一全球视野之上的个性化层，而非有边界的空间。用制度术语来说，信息流没有规则制定能力，没有监控功能，也没有制裁手段。它组织的是注意力，而不是人。
第二个候选者是应用视图（AppView），它聚合网络数据并将其呈现为一个连贯的应用程序，在索引、显示、审核和功能方面做出选择。这就是为什么Blacksky建立自己的应用视图意义重大：它创造了一个完全独立的社交空间，由社区选择的版主治理，并展示社区策展的内容。如果社区栖身于应用视图中，那么应用视图的运营者就是场所构建者，ATProto社区则围绕着任何愿意建立和维护该聚合基础设施的人而形成。
第三个答案是完整的基础设施栈。Blacksky再次提供了范例，不仅构建了应用视图，还构建了PDS托管、中继、审核系统以及最终的私密帖子。在他们的模型中，社区不是单一的一层，而是数据托管、审核、应用体验和边界执行的集合体。这是制度上最完整的答案，最接近满足 Ostrom 完整框架的答案，同时也是对社区建设者要求最高的答案。
同样值得注意的是，这种方法看起来与ActivityPub站点模型有些相似，即单个运营商控制数据存储、审核和应用体验。区别在于ActivityPub的站点绑定架构所缺乏的更便捷的数据可移植性和互操作性，以及保持身份与数据分离。这其中的含义是，社区治理的需求可能会强加其自身的架构要求，无论底层协议提供什么。
最后一个选项是专注于将ATProto作为一个数字身份系统，你的身份和数据跨应用程序持久存在，而你的数据存储在你的PDS上。这作为一种可携带的个人场所发挥作用：博主的“场所”跟随他们，软件可以更换，但身份和数据保持稳定。在这里，社区只是涌现的和短暂的，由你的社交连接定义。用 Ostrom 的术语来说，这是最弱的制度答案：它提供了身份的连续性，但没有集体制定规则、监控或执行的机制。社区变成了通过你的连接发生在你身上的事情，而不是你参与治理的事情。
每一个答案都意味着一种不同的拓扑结构。如果社区栖身于信息流，ATProto就是扁平的：一个网络，许多视角，没有边界。如果社区栖身于应用视图，拓扑结构类似于ActivityPub的站点模型，但具有明确的角色分离和数据可移植性。如果社区栖身于完整的基础设施栈，拓扑结构就会分裂成少数几个投入巨大的社区平台，周围环绕着大量根本不尝试建立社区的轻量级应用程序。如果社区栖身于身份，那么根本就不存在集体的社区拓扑结构，只有个体节点。
经过几年的发展，ATProto生态系统产生了一个完全实现的社区（Blacksky）和一系列有前途的项目，这些项目尚未证明它们能够维持社区所需的制度性要求。
ActivityPub和ATProto并非同一理念的两种实现。它们代表了对这些问题的不同形态的回答：在线社交生活应如何组织？边界应落在何处？谁来治理其中发生的事情？以及归属意味着什么？ Ostrom 毕生致力于研究社区如何发展制度来管理共享资源，她的核心发现之一是：最有韧性的安排是通过本地实验而非外部强加进化而来的。她记录的成功社区并没有采用单一的治理模板，而是进行尝试，在大多数尝试中失败，最终达成适合本地条件的规则。在一个情境下有效的做法未必能转移到另一个情境，即使资源和利害关系相似。
开放社交网络正处于这个实验阶段，不同的项目正在测试不同的答案。但这些答案并非同样可行，那些集中制度功能、将规则制定、监控和执行结合在一个连贯运营商手中的拓扑结构，比那些将这些功能分散在各层或任其自然涌现的拓扑结构，能产生更具韧性的治理。无论起点是ActivityPub站点还是ATProto基础设施栈，这一点都成立。协议塑造了可用的答案，但社区治理有其自身的结构性需求，而这些需求并非无限灵活的。
但实验并不等同于成功，这两个协议都尚未展示出可扩展、可复制的社区形成模型。ActivityPub对于社区栖身何处有一个清晰的答案，但这在结构上被证明难以实现。ATProto的架构暗示了一个更加个人化和全球化的网络，但像Blacksky这样的项目也表明建立社区是可能的，即使这需要扩展协议。
Robin Berjon 在柏林发言时观察到，协议的结构属性与制度的结构属性是相同的。如果他是对的，而且证据越来越表明他是对的，那么开放社交网络面临的问题就不是哪个协议会获胜，而是这两个生态系统中的任何一个能否产生其中形成的社区实际需要的制度设计。