Mastodon 最近为网站推出了一款官方的分享按钮，托管在 share.joinmastodon.org。与中心化的平台不同，fediverse 没有单一的 URL 可供链接。一个用户的账户可能存在于成千上万个站点中的任何一个之上。因此，当有人点击网站上的“分享”按钮时，需要弄清楚这个 URL 应该分享到哪个正确的站点上。尽管以前出现过第三方的解决方案，但没有一个真正流行起来。Mastodon 给出的答案是一个带有品牌标识的小组件，网站所有者可以将其嵌入，上面完整配有 Mastodon 的徽标。
宣布推出该按钮的博客文章的最后一句话最耐人寻味：“我们期待在更多网站上看到 Mastodon 的徽标，它可能会与其他社交媒体平台并列，甚至可能作为主要的分享链接。”这种表述方式将 Mastodon 置于了与 Twitter、Facebook 和 LinkedIn 并列的图标行列之中，不再将其视为共享协议的一个实现，而是将其视为一个平台。
该分享按钮是通过 Mastodon 自己的 API 和基础设施来运作的，而不是通过 ActivityPub。这是多年前做出的一个设计选择所导致的直接结果：Fediverse 拥有一个用于站点之间的通信的标准化的协议，但对于用户如何与他们的站点进行交互，却没有标准化的协议。在实践中，这个空白被 Mastodon 的 API 填补了。Mastodon 的 API 是开源的，但它并不是一个开放标准。它由单一项目来设计、维护和更改，并没有采纳生态系统其他部分的意见。Fediverse 只有一半是建立在开放标准之上的。用于站点到站点通信的层是标准化的。而接口层，即用户实际接触的部分，则是通过专有的 API 来使用的。
ActivityPub 协议规范大致由三个部分组成。首先是定义 ActivityPub 对象的结构，比如规定“每个对象都应该有一个特定格式的 ID”。其次，定义站点之间如何交换信息并向彼此发送 ActivityPub 对象。这是协议的服务端到服务端部分。第三，定义站点如何与客户端交换信息。这是协议的客户端到服务端部分，也称为 ActivityPub API。就此而言，Mastodon 以及 Fediverse 的大多数项目，都已经实现了 ActivityPub 协议的前两部分。至关重要的是，几乎没有人在实现第三部分。
你使用过的每一个 Mastodon 应用程序，无论是 Ivory、Ice Cubes、Tusky、Phanpy、Elk 还是任何其他应用，都是通过 Mastodon API 与你的站点通信的，它们中没有一个使用 ActivityPub 的客户端到服务端协议。Fediverse 的其他部分也是如此：Lemmy 有自己用于客户端的 API，Misskey 也有自己的 API，等等。Fediverse 没有共享的客户端协议，只有一系列与各个独立站点实现相绑定的专有 API。在这些特定于平台的 API 中，Mastodon 的 API 是最重要的，因为 Mastodon 在 Fediverse 的用户群体中占据主导地位。它的 API 起着“影子标准”的作用。整个第三方客户端、工具和集成的生态系统都是针对它来构建的。
服务端软件要想具备可用性，就需要客户端。既然针对 Mastodon API 的客户端已经存在，替代服务端实现最终都会为了可用而去克隆它。如果你想让你的用户能够使用 Ivory 或 Tusky，你就必须实现 Mastodon API。大多数微博项目都是这么做的，GoToSocial、Pleroma 及其分支 Akkoma、Friendica 都实现了该 API 或提供了对它的兼容。Misskey 的一些分支（如 Sharkey）同时实现了 Mastodon API 和 Misskey API，允许你将 Phanpy 等面向 Mastodon 的客户端与 *key 系列的站点一起使用。Lemmy 和 Misskey 的 API 拥有自己的客户端生态系统，但它们都无法像 Mastodon 那样施加跨生态系统的影响力。
即使是专门为了提供与 Mastodon 不同体验而存在的软件项目，最终也依赖于它的 API。它们必须遵循一个围绕 Mastodon 特定的微博模型而设计的受限接口。那些不符合 Mastodon 设想的功能，比如表情回应、非按时间顺序排列的时间线，或者论坛式的主题帖，要么完全无法通过该 API 暴露出来，要么就需要客户端对每一个支持这些功能的站点进行特殊化适配。
2019 年提交的在 Mastodon 上实现 ActivityPub 客户端到服务端协议的最初功能请求，正是这样警告的：“Mastodon 是池塘里最大的一条鱼，很多客户端开发者选择了我们的专有 API。风险在于，当涉及到 Fediverse 中的客户端到服务端通信时，我们的专有 API 将成为事实上的标准。”
一家新闻网站想要让读者在 Fediverse 上分享文章。由第三方开发者构建的通用的“分享到 Fediverse”工具确实存在。但这些工具都没有足够的机构分量、品牌认知度或可发现性，去说服出版商真正嵌入它们。当一家新闻机构决定添加分享按钮时，他们寻找的是与页面上已有的 Twitter 或 Facebook 按钮地位同等的东西。Mastodon 是唯一能提供这一点的Fediverse 项目。对于 Fediverse 来说，唯一现实的分享按钮就是 Mastodon 分享按钮，它带有 Mastodon 的徽标，并通过 Mastodon 的基础设施进行路由。
首先，它将软件等同于网络。按钮上写的是“分享到 Mastodon”，而不是“分享到 Fediverse”。使用 Misskey、Pleroma、GoToSocial 或几十种其他Fediverse 站点实现中任何一种的读者，看到的是一个不属于他们的品牌。一个运营着非 Mastodon 站点、且不想代表其社区展示 Mastodon 徽标的站点运营者，没有真正的替代方案。
其次，它强化了主导地位的循环。如果发布者嵌入了 Mastodon 分享按钮，非 Mastodon 站点上的用户就会获得较差的体验，甚至根本无法使用。这就把用户和站点运营者都推向了对 Mastodon 的兼容，进一步巩固了那些非开放标准的 API 作为默认接口的地位。
新闻网站还应该添加“分享到 Pleroma”按钮吗？“分享到 Misskey”按钮？“分享到 GoToSocial”按钮？如果网络实际上运行在一个共享的客户端协议上，那么一个拥有真正机构支持的单一通用分享按钮是可能的，因为这将是一个协议级别的功能，而不是一个软件级别的产品。分享操作必须通过特定平台的基础设施和品牌标识来进行路由，这一事实正是标准缺失所造成的直接后果。
Mastodon 不实现 ActivityPub 社交 API 的决定并非武断之举：该规范确实存在不足。Mastodon 的创始人 Eugen Rochko 曾将客户端到服务端的规范描述为“极其简陋”，指出它缺乏对通知、搜索、自动完成、域名封锁、静音以及社交应用程序所需的许多其他功能的定义。他的结论是：“最终，你会定义太多的自定义词汇和端点，以至于你还不如干脆直接使用 Mastodon REST API。”
这种批评对规范现状的看法是正确的。一个试图仅仅基于该规范来构建全功能社交应用程序的开发者，将不得不自己发明绝大部分使应用程序具备可用性的东西。ActivityPub 客户端到服务端规范定义了一个写入接口（将活动发布到你的发件箱，然后由站点处理它们），但在客户端需要的其他所有方面都留下了巨大的空白。在标准的规范中，没有获取主页时间线的标准方法，没有通知系统，没有搜索，也没有媒体上传机制。考虑到当时规范的状态，Rochko 做出了一个无可厚非且很可能是正确的工程决策。
但这个决定的后果却造成了一个自我强化的循环。规范是不完整的，所以 Mastodon 构建了自己的 API。Mastodon 的 API 成为了事实上的标准，因为 Mastodon 主导了整个网络。因为 Mastodon API 是事实上的标准，所以人们没有压力去完善那个开放规范。并且由于开放规范仍然不完整，随之而来的下一个项目面临着与当年 Mastodon 相同的选择，只不过现在他们还必须去克隆 Mastodon API，以便接入现有的客户端生态系统。标准的不完整是一个实实在在的问题，但同样成为问题的是，占主导地位的软件提供商拥有最大的权力，也负有最大的责任来帮助解决这个问题。
让情况变得更加复杂的是，对于 Fediverse 中一个功能完备的客户端到服务端协议实际上应该是什么样子，目前并没有共识。问题不仅仅是“需要有人来完成这个规范”。在最近几周里，这一直是 ActivityPub 开发者之间热烈讨论的话题。
对单纯的 C2S（客户端到服务端）实现的一个批评是，仅仅在一个现有的类似 Mastodon 的站点之上暴露 ActivityPub 端点，并不能带来太多的好处。开发者 kopper 将此称为“JSON-LD 风格的 Mastodon API”问题：结果是得到了一个与专有 API 同样僵化和受限的 API，却没有量身定制带来的好处。如果 Mastodon 不加修改，只是简单地用 C2S 替换它们的 API，你仍然无法对帖文发送表情回应。Mastodon 的数据库中根本没有“贴文的表情回应”这个概念。kopper 认为，C2S 真正的收益在于能够将数据托管与数据解释分离开来。站点变成了一个几乎无状态的数据主机，而一个独立的客户端层负责处理解释、索引、时间线和审核。
Fedify 开发者 Hong Minhee 指出，当你将这种架构映射到我们熟悉的术语上时，“哑服务端（dumb server）”就是数据库，“客户端层”是应用站点，而“前端”就是实际的客户端应用。这其实就是目前的架构，只不过标签向下平移了一层。有趣的问题是，哪个接口会被标准化。在 kopper 的模型中，答案是最底层的边界，即数据主机和客户端层之间的边界，而前端则仍然被锁定在特定的客户端实现上。C2S 的互操作性承诺——即任何应用都可以连接到任何站点的理念——被向下推了一层，变得让最终用户触不可及。
这种分歧实际上关乎可移植性的真正含义：是数据的可移植性、身份的可移植性、接口的可移植性，还是某种组合。
为改变这种状况而进行的最有组织的尝试，是 W3C 社交网络社区组下属的、由 Evan Prodromou 领导的 ActivityPub API 工作组。该工作组已经定义了 30 多个用户故事，涵盖了当前规范中的空白：OAuth 标准化、功能发现、媒体上传、通知、搜索、内容过滤、审核工具等等。它明确的“非目标”之一就是标准化 Mastodon API。其目标是使 ActivityPub 社交 API 足够全面，以便客户端开发者可以基于它进行开发，站点开发者可以去实现它，而不是将 Mastodon 的 API 确立为标准。
该工作组仍处于早期阶段。它的许多关键交付物都标记为“待定”。而且，作为其参与将最能改变当前局面的实现方，Mastodon 至今尚未表示出任何兴趣去实现该工作组产出的成果。
想象一下，如果构建电子邮件客户端的唯一方法是实现 Gmail 的 API。Thunderbird、Apple Mail、Outlook 以及所有其他客户端都需要去克隆 Gmail 的接口契约。那些希望其用户能够访问第三方客户端的电子邮件站点，将需要暴露兼容 Gmail 的端点。网站上的“通过电子邮件分享”按钮将通过 Gmail 的基础设施进行路由，并显示 Gmail 的徽标。任何运行自己邮件站点的人在分享内容时，仍然会看到 Gmail 的品牌标识。
这大致就是今天 Fediverse 的状况，而 Mastodon 扮演着 Gmail 的角色。不同之处在于，电子邮件有 IMAP 和 SMTP，这些客户端协议不仅被标准化了，而且被普遍采用。每个电子邮件站点都实现了它们，每个电子邮件客户端都期望使用它们。这些协议不仅仅是被写成了规范，它们还具有正统的权威地位，也就是说，没有任何严肃的电子邮件提供商会考虑去不支持它们。Fediverse 没有对等的东西。ActivityPub 社交 API 虽然有规范，但并未被采用，而且它缺乏那种能够使其被广泛采用的权威地位。
这里的问题不在于分享按钮本身。Fediverse 将其联邦层建立在一个开放标准之上，但却任由其客户端层被其主导的提供商所垄断。建立在这个专有接口之上的工具和集成越多，这种技术锁定就会变得越深。