互联社交网络是除了互联即时通信系统/IM以外的另一主要互联系统类型。从来没有接触过这类系统的人可以类比互联的效果为：直接在新浪微博关注腾讯微博的人（而不需要去腾讯微博重新注册账号）。

之前在跟人介绍时，我发现有人会将互联系统和SSO的效果搞混。事实上，两者完全不同。仍然以上面在新浪微博S关注腾讯微博T为例：SSO的本质仍然是在T上注册了一个新账户，然后使用T上的账户去关注T上的另一个账户，而你的S账户上仍然是没有对T上的关注；但互联SNS的效果是你直接在S上关注T上的人，不需要在T上重新生成一个账户。如果仍然不理解，那请思考在你不登录T时，即使你做过了“关注”，在你的S账户能否看到T上被你关注的人的消息。

几大比较知名的互联SNS系统为：

• Mastodon
• GNU Social
• Pump.io
• Diaspora*
• Friendica
• HubZilla

既然叫互联系统，每个互联SNS之内各个不同实例/服务器间的用户可以互操作。事实上，这些系统主要分为两种协议（以及HubZilla的Zot），每个协议内不同系统也可互操作。

下文将以协议为主要线索串联不同互联SNS系统特点与分别、大概历史、以及我个人对其看法。其中内容来自我对不同互联SNS系统的了解（包括使用），以及背景阅读（尤其是下文中将会经常引用其图片的这篇文章）。

The Federation与The Fediverse

（来自https://medium.com/we-distribute/a-quick-guide-to-the-free-network-c069309f334）

一般来说，在OStatus协议（及其衍生协议）下的系统（组成的网络）被统称为The Fediverse；Diaspora协议下的系统（组成的网络）被称为The Federation。

Federation一词就是“联邦”之义；Fediverse应该是Federation和Diverse（“多样的”）两个词的组合。

但事实上，如图中所示，不像商业网络，The Fediverse和The Federation并非泾渭分明——许多系统同时支持这两者。比如上面提到但没有分类的Friendica就同时支持两个网络；HubZilla在支持自己的Zot网络之外，也同时支持这两者。

之所以最初有协议的分别，除了（不知道有没有）纯粹的感情因素以外，系统的目的是影响协议设计的主要区别。其中，OStatus协议设计为微博客使用；Diaspora协议被设计来服务更偏Facebook的展板/贴子型社交网络。于是，The Federation中系统的UI设计脱则胎于Twitter；The Fediverse中系统的UI设计则更偏向Facebook。

OStatus协议这边稍有更多历史可讲：OStatus协议是GNU Social整合了StatusNet之后为StatusNet协议改名的产物；而后来，Pump.io在OStatus的基础上进行了一定改动形成了自己的协议。在2012年冬天之后，OStatus主要被一个W3C工作组维护；而后来，W3C成立了W3C Federated Social Web Working Group，并基于Pump.io的协议制定了新的ActivityPub协议，用以取代OStatus（参考自这里）。

ActivityPub

2017年W3C将ActivityPub协议立为推荐的标准，用来取代之前的OStatus协议。

（仍然来自https://medium.com/we-distribute/a-quick-guide-to-the-free-network-c069309f334）

多数网络均转向支持ActivityPub协议（且许多系统已经实现ActivityPub），但Diaspora*似乎并没有做此打算。Nextcloud这一本来并不是SNS的系统也将支持ActivityPub协议，作为跨站/互联消息的分发机制。

我个人是比较希望各个网络可以整合在一个协议之下，以减少维护成本。但ActivityPub毕竟衍生自微博客协议，由于我没有阅读过其协议内容，所以对该协议对其他形式内容（比如版面/贴子）的支持存在疑虑。

HubZilla与Zot

HubZilla是一个比较独特的系统：它没有选择使用OStatus或Diaspora协议，而是自己提出了新的Zot协议。就我个人了解来看，Zot并不是仅仅另一个协议：Zot最为标彰的特点是所谓nomadic identity，这一点在其他协议（包括ActivityPub）中并不存在。

简单来说，nomadic identity允许两件事：

• 使用站点A的身份去登录站点B（同样，不需要在B上创建账户，数据仍然存在A上）
• 当有需要时，将站点A的身份（包括内容）整个克隆至站点B，并且所有关注了A站点身份的人将自动转向关注站点B的身份

这两点特性十分符合我的心意：

• 远程认证这点省去了每次遇到新网站均需要重新注册账号的麻烦
• 多年来（大约四年），我一直在（时不时）寻找远程登录的机制，而找到的最佳机制是OpenID一类。然而，且不说我至今都没有弄明白的OpenID版本，OpenID在多数网站上仍然被作为一种SSO实现：之前提过，SSO本质上也是重新注册。
• 身份的转移则是更多考虑站点切换的问题
• 由于允许身份转移，vender locking的情况会大大降低，迫使服务提供方不能选择压榨用户
• 在特殊情况下（比如站点不再维护），身份的转移降低了迁移成本

当然，第二条主要在没有GDPR的时候（+的地区）比较重要——GDPR规定服务商必须允许用户将自己的数据（用户自己上传/填写的所有数据）导出成机器可读的格式。但即使是有GDPR，用户仍然需要想办法手动告知其他用户自己的迁移。

在一篇文章中，HubZilla直接被称为全包平台（The Do-Everythign System），体现了HubZilla的壮志/野心：HubZilla希望（Zot协议）成为基础，并且在其上构建各种服务，包括SNS、论坛、数据存储……

我个人（四五年来）一直比较希望论坛可以被设计为互联系统，但一直没有找到。HubZilla的设计给了我这个希望，且其实现已经部分涵盖该目的。

使用体会及总结

我个人最近尝试过Mastodon、Diaspora*、HubZilla，印象中以前也试过pump.io以及GNU Social但记忆不是很深刻。

首先，必须要强调的是，不同于旧式的中心化社交网络，互联社交网络是去中心化的。去中心化带来多种便利，但同时也可能会导致从旧时代过来的人思维遇到障碍：互联社交网络的“官方”只有项目网站，并没有“官方实例”（虽然官方一般都提供实例使用，但这仅仅是诸多对等实例中的一个）。想要使用互联社交网络，请选择任意一个你喜欢的实例，或是自己搭建一个实例。一般而言，官方或第三方会维护一份（到多份）实例清单（由于去中心化的本质，清单并不全面，但足够使用），可以从中选择一个。

基本而言，Mastodon符合其微博客服务的定位，且功能全面（内容、可见性、API及授权控制）；另外其多栏的UI算是比较有特点，打破多数微博客服务那种中部瀑布的模式。另外，Mastodon似乎没有为动态设置地理位置的选项。

Diaspora*符合正常的以主题为线索的社交网络（如facebook）定位，但不包含游戏等功能。当然，完全可以将Diaspora*当作微博客使用。

HubZilla则是一个全功能的平台，可以当微博客、长文型社交网络、相册、论坛……需要注意的是，HubZilla将每一频道作为一个主体（每个账号可以建立多个channel，彼此默认独立），并且以频道作为管理单位。我也试过其nomadic identity，迁移自己的频道并且保持联动的更新，其效果的确符合预期。 然而HubZilla的界面看起来总有一种奇怪的简陋感，即使其每个元素并不给人这种感觉。或许自定义主题后会有所改进，但我仅仅尝试了默认提供的数套主题。

在测试中，每种网络内互相关注都很轻易；跨网络的互通测试结果如下（并没有测试所有可能的组合）：

• HubZilla和Mastodon
• HubZilla可以轻易关注Mastodon上的人（以[email protected]形式增加 连接 ）
• Mastodon上可直接搜索HubZilla上的人（只要该HubZilla实例支持和Mastodon互联，一般为ActivityPub协议）
• HubZilla上以MASTODON.INSTANCE/SOME_ONE形式关注Mastodon上的人似乎有问题，其头像右下角会显示“禁止”图标
• HubZilla关注Daspora*上的人似乎需要对方的审核（会在其头像右下角显示一个“禁止”图标）

详细使用体会见部分互联社交网络测试感受

如前面所述，整体而言，我更喜欢HubZilla的设计，于是自己在某一HubZilla实例上安了个窝。（具体地址见个人介绍页面，这里不再赘述；如果找不到，欢迎用你所知的任何可以联系我的方式询问。） 如果是为非我自己的人推荐，Mastodon应该是我首推的，毕竟无论是功能还是设计上看我个人都很喜欢它。