2021年头一个月针对美国总统换届的种种争夺中,最让人大跌眼镜的便是以Twitter为首的互联网媒体平台对特朗普账号的绞杀——找个理由,将其禁言乃至封号,并且是以一种近乎连坐的方式。这和他们以前喜欢标榜的言论自由态度大相径庭,以至于美国人也终于看到了它们手上有且有意愿使用的这种权力。
然而美国人的讨论却又走上了老路,即企业是否有权对自己平台上的数据随意修改,或者是这一行为是否违背了法律规定的言论自由。这种讨论大约是不会有什么结果的,而哪怕这一次有结果也在长期上作用不明显——法律的滞后性已经显现出来了,所以它们是否违反了「过去」的法律条纹并不是核心,核心的是如何确保它们将来不会再在另一个角度作出类似的事情。
在我看来,新形势下需要新的思路,而这个新思路就着落在技术本身——是否有新的(或者老的)互联网技术可以降低平台的掌控力(权力)?
答案是肯定的,而且这些技术早已存在。它们的理念十分简单,但相当多人欠缺一个知道它们以及知道它们好在哪里的机会。
我在以前的文章中对这类平台有所简单介绍,不过是出于社交媒体这个特定用途的。这篇文章尝试用简单的语言解释这些技术的核心,以便让更多的人对「另一个可能的互联网」有所了解。当然,不可避免地,其中会涉及一些技术理念,但我会尽量减少它们对理解正文的影响。
最基本的网络服务模式
大多数人熟悉的互联网(或者更确切的叫因特网)是由网站以及一些需要联网的软件(智能手机的软件被称为app)所组成的。它们的服务方式很直接:软件的提供方运营着一个平台(本质上是服务器),每个用户通过对应软件连接到平台上,然后平台提供对应的服务。
举个例子:腾讯有一些服务器运行着QQ的服务(平台),QQ的用户需要安装QQ客户端(即对应的软件),然后在客户端上登录自己的账号(连接到平台上),然后继续在客户端上和好友聊天(平台提供相应服务,但需要你使用对应的软件)。
网站也是一样的模式,但更通用化:网站的建设者搭建服务器(平台),用户通过通用的软件「浏览器」通过「网址」连接到对应的服务器上,然后服务器返回网页(提供服务)。
在计算机尤其是互联网的语境下,「通用」就意味着「标准化」,也意味着「开放」。
但「开放」什么?开放的是「协议」——前面提到的「对应的软件」和「平台」之间的通信会通过某一种固定的预先决定好的方式进行,这种特定的方式被称为「协议」。
所以为什么QQ必须使用专门的客户端访问?因为QQ的协议是封闭的,而且腾讯公司不遗余力地确保其协议不被解析(或至少明面上不被解析)。
为什么网站可以通过任意的浏览器访问而不用使用特定的某个公司的浏览器?因为网站和浏览器之间通信的协议HTTP(本文不讨论HTTP和HTTPS等的区别,因为这些细节不影响大框架)是开放的,而网页本身也是由标准化的HTML写成的,所以任何人都可以制作一个软件(浏览器)来和网站通信并展示网页。这一系列标准及其上的东西被称为「万维网」(WWW,World Wide Web)。
那么为什么B站既有网站也有对应的软件(app)?因为B站的服务器同时支持两种协议,分别为浏览器和其软件使用。
上面这些你也许在其他地方也看过,但我觉得还是有必要叙述一下,因为重点马上就到:
大多数现有的服务有一个共同的特点:你只能在它们的服务器上和它们服务器上的其他用户/数据交互,而不能和其他服务器上的用户/数据交互。
比如说,我有一个QQ号,而我的朋友某甲没有QQ号却有Skype/Line/Slack账号,那么我不能从QQ上添加某甲的这些账号为好友(更不能给某甲的账号发送消息)。同理,新浪微博的用户不能关注网易微博/腾讯微博上的用户,反过来也不能。
许多人可能会觉得这是「理所当然」的,因为他们「从一开始使用网络时就是这个样子」。这种逻辑的谬误再显然不过,但不将其拎出来很多人完全意识不到。正如先人所说,我们使用的工具会塑造我们的思维模式。
一些人可能意识到了,万维网和这些服务还稍有差别:你可以在一个网页上「超链接」到另一个网页(用户点击时进行「跳转」),而完全不用考虑它们是不是同一个公司/网站上的。是的,万维网的确比它们优秀,但还有更优秀的例子——电子邮件。
被部分人遗忘的电子邮件系统
许多活在垄断互联网企业支配下的低年龄新用户可能根本没有怎么使用过电子邮件,但电子邮件系统源远流长且历久弥新。
用过电子邮件的人应该都知道,当你想发送邮件时,需要填写收件人,而收件人的格式是[email protected]。其中BBB.CCC部分是和网站服务同源的「域名」,标明了该用户所使用的邮件服务提供商,比如qq.com和foxmail.com是腾讯的,outlook.com和hotmail.com是微软的。而其中的AAA则是该用户在该服务器下的用户名。
通过这样的模式及相应的机制,邮件系统可以让在服务商A上的用户与服务商B上的用户交流。其方式简单且有效。再加上电子邮件也有标准化的「用户(客户端)-服务器」通信协议(POP3、IMAP、SMTP),于是不同用户手上的(使用不同客户端的)电子邮件体验可能天差地别,但他们依然可以无任何障碍地交流。
之所以电子邮件邮件系统可以这样,而QQ、B站等服务做不到,正是由于电子邮件系统有标准的「服务器间」通信协议:它和前面那种简单的「用户-服务器」模式有显著不同,除了「用户-服务器」的通信协议外,还有「服务器-服务器」的通信协议。
这种添加了「服务器-服务器」通信协议的服务模式,被称为「互联」(federated)服务/系统。
互联系统
电子邮件只是互联系统的一个最常见且典型的例子。事实上,你日常中所用的多数服务都可以是互联的。
一时之间你可能想不到都有什么,那么我就来提几个醒:即时通信服务(如QQ、微信),微博客服务(如新浪微博、Twitter),社交网络服务(如QQ空间、Facebook),视频平台(如B站、Youtube),购物平台(如淘宝、亚马逊)。
比方说,即时通信可以选择基于XMPP协议的或者是基于matrix协议的服务(个人更倾向于后者),微博客可以选择mastodon或者GNU Social,社交网络可以选择friendica或者diaspora*,等等等等。这些都是不同的软件,任何一个人搭建的任一服务器实例(常被称为pod或hub),都可以和相兼容的另一pod交互——之所以说是「相兼容的」而不是说「同一软件的」,是因为有许多软件之间也是可以互相交互的,是相互兼容的。
那么,和非互联的系统相比,互联系统有什么劣势呢?尤其重要的是,为什么企业都选择封闭的系统而非互联的系统呢?
第二个问题的解答很简单:互联系统会让企业失去很多依靠垄断可得的盈利机会,所以企业不选择。 因为如果是互联的系统,如果企业A的服务不好(比如有许多广告),那么用户完全可以在企业B的服务上注册账号,且不损失任何与企业A上的用户交互的能力;如果所有企业的服务都不好,那么还可以自建服务器,或选择非企业的服务器。 这和技术优秀与否关系不大,甚至和是否需要投入额外成本(去写文档)的关系都不大,纯粹利益的考量足以使企业不愿意这么做。
当然,如果从纯粹的技术角度考虑,互联系统也有一些绕不过去的问题需要解决。但这些问题从用户的角度几乎是无感的,所以用户没有任何理由站在非互联系统一边。
互联系统绕不过去的问题主要是「服务器-服务器」之间的传输速度问题,或者说是由此引起的「延迟(延时)」问题以及更技术一些的「一致性」问题。但从用户的角度看,在这些服务上,多数十乃至数百毫秒的延迟并没有影响,毕竟用户自己的网络抖动都可能引入不止这些的延迟。至于视频通话,多数情况下都是P2P连接,也就是视频的双方直接建立连接,完全绕过软件的一般通信结构,所以也不需要操心。
那么(对用户来说)只要引入系统间互联就是完美的「另一种」方案了么?也不是。用户的数据依然存储在某一个服务商的服务器上,当需要切换服务时这仍然会有问题。哪怕引入GDPR的机制要求数据全部可导出,你的联系人仍然需要手动重新添加。
有办法解决这个问题么?有,引入「游牧身份」(nomadic identity)。
游牧身份
游牧身份的概念建立于互联系统之上,专门为了解决「无缝切换服务商」这个问题。至少以我所知,它是由HubZilla/Zot提出的一种理念(技术)。
它的理念很容易理解:不强行假设用户从属于「某一」实例(pod),不使用基于实例的用户标识,而使用另一种和实例无关的方法来标识用户。在HubZilla上,所选择的方法是为每个「用户」(实际是每个channel,但对理解概念来说不重要)生成一个非对称密钥对,用公钥来标记用户。
因而,每个用户可以任意选择一个实例作为自己的起点,然后添加联系人。之后在其他的备用的实例上「关联」上自己原先的实例,这样不同实例之间就进行了同步,在任一实例上都可以完整、同步地进行操作。在需要切换实例时,用户只需要删除原先实例上的身份即可。
这可以说是对互联系统中的用户身份迁移的最完美解法了,而且它没有引入许多额外的成本(除了用户所挑选的每个pod都需要存储一份该用户的信息外)。但目前少有其他系统使用类似的方案,不知道究竟只是没打算/来得及实现,还是对技术犹有疑虑——用户的唯一身份标识目前采取非对称密钥,但在「将来」会有被破解的风险。
分布式平台
像前面每个方案一样,游牧身份的方案仍然有一个绕不过去的假设:每个pod都需要具有可以正常访问的(长期的)公网IP地址。另外,各个实例之间通信的安全也需要保障,一般的选择都是通过HTTPS/SSL/TLS,所以也需要确保DNS解析没有问题以及可以拿到SSL证书(通过Let's Encrypt基本可以解决第二个)。
但如我们所知,IPv4地址早已枯竭,IPv6的广泛使用还欠缺不少火候,于是许多人自己的电脑无法拿到公网IP地址。但仍有人希望可以将数据完全握在自己手中,希望可以在自己的电脑上搭建服务器。也有人纯粹就是不想遵循上述模式。
于是还有另一种完全不同的技术路线,它使用(几乎)完全的分布式理念,以在这种需求下运行。解释其理念会需要解释大量技术及细节(且每个协议的做法都不尽相同),所以本文不对其详细解释。但重要的是有这样的平台,其数据完全存储在用户(们)自己的设备上,完全不需要商业公司或大平台。
但由于这些特点,经营非法勾当的人也喜欢这类平台,以至于它们已经几乎成为非法的代名词。但技术毕竟只是技术。
至于该技术路线本身,延迟是其最显著的劣势。这里不再是多少毫秒,而是多少秒或是多少分钟的延迟。在一些领域中,该性质导致其已几乎不可用。但在一些其他领域中,它也有其不同寻常的优势。最显著的一个便是在没有广域网连接的情况下,局域网中该类技术可以迅速将人连接、组织起来。在灾难情况下可以说这是唯一的方案。
优劣和选项
前面谈及了三种(或者说两种)备选的技术方案,都可以用来解决平台垄断的问题,且各有各的特点(优劣势)。
以我个人的观点来看,互联系统是打破垄断但又不影响创新激励的最佳选项。主要理由有三点(基于「平台之间可以保证互联」这个前提):
- 用户不会被锁死在一个平台上,所以平台不能无限扩大自己的权力。
- 平台可以通过改善自己的服务来吸引用户,创新仍然受到激励。且用户有更大的动力切换到更优的平台而不必受制于「原先的联系人都在那里,我一旦切换就再也联系不上了」这类因素。
- 平台之间虽然有竞争,但由于互联,所以不会出现恶性竞争。比如不会出现竞争后达成垄断,用户体验低于竞争之前的状况。
当然,如前面所说,互联也有其对性能的少许可能劣势,但毕竟瑕不掩瑜,且随着网络硬件的提升以及存储器的进步,这些劣势也许都不再重要。具体选择哪种方式来实现互联,则是需要继续讨论的。但无论哪种,至少互联的基础是确定的,而且没有技术难度的,所以总之是可以推进第一步的。
这样还有一个好处,那就是对内容的分类/分级也可以根据不同的平台来进行,而不再是一个平台一刀切。一个平台可以决定是否接受其他某些特定平台的内容(或只接受某些特定平台的内容),进而组合成更灵活的社区分级。当然,这些都需要进一步讨论,但至少提供了另一种可能性。
为了防止一些人的奇谈怪论,这里需要强调两点:
- 开放性和创新完全不矛盾,也和对自己的改进完全不矛盾。比如matrix协议就在不断升级和扩展,这一切都不影响服务的正常运行。
- 开放性必然导致互联网企业现有的收入模式受到影响(比如通过锁死用户,然后大量投放广告;或者违规使用/处理用户数据)。但哪一次的技术创新不会对其产生影响呢?每次的影响之后都会有新的收入模式出现,而且一般也都带来了更好的用户体验。
我们可以想象互联场景进入应用后的新互联网生态:在基础协议上,各个服务器/平台之间可以互相交互;各个平台各有其独特之处,所以都能留住各自的用户;平台上的对协议的创新可以首先在自己平台应用,在一定时间后,协商确定如何将该创新的协议部分开放成标准协议的一部分;新入场的开发者/企业不必太过操心如何将用户导入自己的平台,主要精力放在开发产品即可,因为平台的基础是开放的,必然有相应的开源服务端软件可以直接使用。
创新没有激励的话,就没有人会进行创新,所以(在共产主义社会实现之前)不能要求每个创新都立即完全公开;但同样自然地,企业是不愿意自己的摇钱树被公用的,所以我们需要一种企业之外的力量保证其运行。
而在另一个方向上,在讨论大规模实行的技术时,也应当考虑分布式平台。一个近期的实例便是欧美多国(人)所用的新冠接触追踪系统,就是通过蓝牙信号判断和其他人的接触密切程度,之后再通过对数据库的检查反向查找阳性患者的密切接触人员。这一系统的最大优势就是不用担心信息泄漏,因为信息没有存储在除了自己手机以外的任何其他地方,甚至也不需要移动通信公司追踪用户的信号。当然它也有劣势,所以我更倾向于将该方案和我国的方案结合一下,形成一个更好的新方案。
总结
上面讨论的是技术方案,但其背后的理念并不仅限于互联网。类比到线下,则是在大公司进行圈地并不断扩张的过程中,需要有人(比如政府)打击大公司,划出公共空间(互联系统),保障它们不被大公司圈走(私有平台)。并且需要建立新的「驰道」(标准协议),统一行车标准,而非由各个独立王国出于各自利益建立不同标准(封闭协议)。换句话说,就是对网络生态进行一次「车同轨,书同文」的改造,并且保障改造的持续。
希望这篇文章提到的技术可以启发大家的思考,并在有选择时尽量倾向于更优秀的方案。我知道市场不是万能的,所以更希望国家尝试规范互联网企业的时候考虑运用一下这些技术的思维,给出一个更加理想的解决方案。
希望我们的「信息基础设施」可以更进一层,从仅有硬件和网络本身的保障,扩展到对信息产业生态的保障。毕竟,垄断最终会扼杀创新,而信息产业中垄断者(大企业)手中还有人质(用户的数据)和对建筑的引爆器(生态),比老式的垄断的危害更显著。
您可以在Hypothesis上的該群組內進行評論,或使用下面的Disqus評論。