“我是一位休闲娱乐程序员。我主要作为 Scuttlebutt project 的创始人和上百个 JavaScript 模型的写作者为人所知。我现在住在新西兰的一艘小帆船上，每天的任务是修理一切出问题的东西。我觉得简单的事物是最好的，这世界上大部分事物都能以更简单的形式存在。“
“I am a recreational programmer known for starting the secure scuttlebutt project, and for writing hundreds of JavaScript modules. I live on a sail boat in New Zealand and am on a quest to fix everything. I think it’s best when things are simple, and that most things could be much simpler.”
–关于Scuttlebutt–
Scuttlebutt 是一个去中心化的安全 Gossip 平台。和其他社交平台一样，在这儿，你不仅能向你的朋友发送消息，还能把帖子分享到 feed 上。最酷的是，这里的底层技术允许消息根据点对点（p2p）Gossip 协议在用户之间直接传递。作为一个去中心化的社交网络，Scuttlebutt 没有任何中央服务器，它的数据是本地化和分布式的，这意味着离线工作也是可行的！另外， Scuttlebutt 这个名字来自于“海聊”，即水手和海盗常常喜欢去船上的水冷器边上闲扯。
Scuttlebutt is a decentralized secure gossip platform. Like other social platforms, you can send messages to your friends and share posts onto a feed. The cool thing is that the underlying technology here means that messages are passed directly between friends via a peer-to-peer (p2p) gossip protocol. As a decentralized social network, Scuttlebutt passes the data from friend to friend, without any central server. The data is localized and distributed so it also happens to work offline! The name, Scuttlebutt, came from sea-slang for gossip. Basically, like a watercooler on a ship, where sailors and pirates go have a yarn.
Scuttlebutt：https://scuttlebutt.nz
让我们重写网络
文/[新西兰]多米尼克.塔尔
译/张晋珲
编 校/翠玉
摘要：网络已经在发展中伴随我们近30年了，其普及性和复杂性也与日俱增。到此为止，我们已经拥有了大量的关于网络的知识。我认为目前我们已经积累了足够多的可以简单地回看从网络诞生以来发生的一切的经验。现在，如果我们从Scratch这样简易的编程工具开始会怎样？我将在本次演讲中分享一些对此的看法。
Abstract：The web has been with us nearly 3 decades, and it’s evolved a lot in that time. It’s also grown massively in complexity. In that time, we have learnt a lot. I think we now have enough experience to look back on everything that has happened in computing since the internet began and simplify it down significantly. So, what would it be like if we just started over from scratch right now? I have some ideas and will share these with you.
大家好，我今天演讲的主题是 “重写网络”。虽然主持人已经多次提到我的名字，但我还是要介绍一下自己的联系方式——你可以在网络上搜索 “Dominic Tarr” 来找到我，我创建了一个新的 Github 主页
“重写网络” 是Scuttlebutt
虽然还处在构思的阶段，但我确信我们应该创造一个全新的、更加安全的Scuttlebutt，尤其要在我们之前成果的基础上进行一些提升。比如，在重建安全等级的同时实施点对点协议。这就是我不把此项目称为安全盾牌的沙箱，而是称之为“重写网络”的原因。“重写” 即 “推倒一切重新开始”，它不仅针对点对点系统，还针对其他例如网络操作系统之类的东西。现存的网络已经持续了三十多年，我们早已知道更好的方向大概是什么样。我不想做重复的事，而是想创造全新的东西。
现在的网络有许多太过复杂的、实际上并不被需要的冗余（Bloat）。HTML的说明规范就称得上是互联网上最无聊的部分，它有1312页。可以想见，通读全文并真正了解这些东西运行原理的人一定很少。但是像JavaScript这样可以做很多事情的东西就只有说71页的说明——就算没看过，我也能很好地了解它的工作原理。我认为有一千多页说明的HTML是不可接受的，更别提除说明之外，如今的互联网上还有诸如IndexedDB之类的一大堆臃肿的协议。现在的网络环境对创新并不友好，很多东西都被捆绑在一起，浏览器则是组成了一个超级单调的巨无霸（monolithic）——所有供应商都需要统一想法，任何创新的设计都会被视为麻烦。包括网络音频（Web Audio）也是个非常臃肿的API，它包括了太多未被删除的多余之物。想要通过在这些东西上添添补补来改变网络环境显然不是个好主意；我们真正需要的是大量持有不同想法的人分别进行实践，看看哪种方法能够变得流行。
今天的网络（web）是如何形成的？90年代初期，所谓的网络只是一个网络化的文档查看器。90年代中期，JavaScript被添加了进来，而如今，它是网络上最主要的编码语言。现在的网络操作系统实际上是一个不太好用的JavaScript应用程序平台，它不是被精心设计出来，而是意外演变而成的。基于此，我希望做一个更好的操作系统。这个系统可以有某些统一性（Unifying Concepts）——在我看来，除了网址（url）和链接（links），现在的网络上非常缺乏统一性。
Unix是一个相对良好的操作系统。诞生于60年代末的Unix具有一点统一性，即“一切都是文件”。Unix是一个字节流，它在创建之初主要被用于处理文本，其核心概念是操纵并结合文本流的信息。Unix所输入的内容可以是文件或程序，这些内容会通过多种方式被处理和再输出。现在几乎所有的操作系统都构建在这一操作系统之上。例如，基于Unix的Linux就是时下最流行的服务器操作系统。Android也基于Linux，Mac OS则是基于FreeBSD——Unix的一个分支。现在还有一些针对Linux的Windows分支系统。有些人觉得，在未来，一个Windows系统的最新版本可能就是一个完全不同交互界面的Linux。要是真有这么一天，我也完全不会感到意外。
但是，行至今日，很多事情都已经改变了。“所有东西都是文件”的想法不再绝对有意义了；现在，我甚至愿意说：“所有东西都不是文件”。在1969年，一个大型组织可能只有一台计算机，用户通过终端连接到同一台计算机，但用户之间不存在联系；但在2020年，一个人可以拥有多台计算机——除了笔记本电脑和手机之外，你可能还会拥有智能手表之类其他精美的东西；甚至于你屋内像是相机和WiFi路由器这样普通物品内部的计算机也都能通过Unix连接在一起。
所以现在，我认为最重要的概念是“一切都是网络”。网络中每台电脑内部都有许多子电脑，也就是所有的CPU内核。这些CPU内核上运行着虚拟机应用程序。在这些应用程序内部，嵌入着类似于另一台嵌套计算机（Nested Computer）的语言，你永远可以成为计算机的制造者之一。在逻辑上，我将计算机定义为“可以模拟为任何其他机器的机器”。只要一台计算机正常工作，组成这些计算机的所有子计算机之间所组成的网络就可以被称作网络。所以，每台计算机都是计算机网络。但很遗憾，现在的操作系统并不基于这样的想法，网络浏览器实际上是浏览网络的一个应用程序，浏览网络意味着要执行安装应用程序的步骤。
如今，每浏览一个网站就意味着要重新安装一次网页应用程序。在客户端上，每个页面都在浏览器的单独选项卡中运行，某一选项卡不知道其他选项卡正在运行什么页面。这就像是数据中心的服务器端运行着一台单独的计算机，而这台单独的虚拟机上则运行着程序。这些虚拟机可能运行在同一台计算机上，也可能分布于不同计算机。但是这对于开发者来说没什么不同——唯一的区别是客户端浏览器和服务器端数据中心分别由客户端发出“拉取请求”和发出“推送请求”。就逻辑来说，“使编码器运行”和“在服务器端发出一个推送”几乎是同一件事，而眼下，我们需要一个新模型，以更好的叙述当前世界所发生的变化。
我们现有的Actor模型（Actor Model）是在70年代创立的，它就像一个数据交接性质的计算单元，被用于描述分布式计算的模型。Actors有地址，人们可以将消息发送到那儿，让其他Actor接收信息。虽然信息的收取常常乱序，一些现实上的限制（Realistic Limitations）甚至会令Actor难以收到这些信息——比如，交换性的分组网络中会导出大量信息，这些信息会丢失，顺序也可能被打乱改；但是，我们可以在此基础上建立协议，创建可靠性。举个例子，CP/IP就是一个能进行数据包重复的协议，它可以修正最底层的错误，我们正应该借鉴这点。
既然Actor模型本身不足以描述我们正在进行的尝试，我于是想到了“Actor/Script模型”。这个模型与Actor模型没有任何矛盾，只是对其进行了进一步编写。我们或许可以根据被发送的信息中包含的脚本创建新的Actor，脚本只是Actor的代码，它甚至可以在运行之前就被修改。这些Actor的层次结构是相互嵌套的。一个母Actor其中可以被创建子Actor（Heirachical Actors），这意味着系统的API和网络之类的东西可以像Actor一样被解决。子Actor的代码可被修改，修改母级代码的子Actors可被拦截，信息则被首先传递给母Actor。这意味着人们总是可以通过修改子Actor的代码来查看子Actor的消息，以便将其先发送到母Actor。在Actor/Script模型中，您可以发送Actor到其他Actor，但您不能保证他们真的发送了一切内容——他们可能会运行某些不太一样的信息。
虽然信息稍有不同，但您可以构建智能合约（Smart Contract）。若我们将网络前端构建成Actor/Script模型，则客户端会将消息发送到服务器，请求获取服务器用以下脚本响应的页面：客户在网页上创建的新标签或新Actor，即Web后端，也就是适合这个网络模型的Actor。当开发人员向包含Actor的数据中心发送消息时，数据中心将会创建作为Actor的Web服务器，然后将客户端请求路由到新的Actor。虽然在这个模型中，客户端只能与发送他们数据的原始服务器交流，无法与其他客户端或者任意其他的服务器通信，但这个层面的交流限制较少，我们实际上可以用很多方法完成原本模型中无法完成的工作。比如，我们可以去部署一个作为Actor/Script模型的智能合约，并将其发送给所有Actor。该合约被网络中每个Actor验证后，整个网络都可以被当做某单一的Actor。但是实话说，我觉得这个想法严重限制了数据吞吐量和效率，而您知道我们可以创造的远不止于一台非常大却也非常慢的计算机。
有时候，病毒和计算机漏洞（Bug）之类的东西就是一种Actor/Script，它就像是一个网络蠕虫（Network Worm）般的自我复制的脚本，一旦被接受，就会自行扫描本地系统以查找它可以继续发送的任何新地址，并将自己发送出去。Actor和僵尸网络(Botnet)也可能是蠕虫，接受着来自中央Actor（即控制者）的脚本。但这或许也是Actor/Script模型的有用之处——它甚至可以描述我们不希望遇见的事物。
另外一点也是蛮有意思的，就是我们建立在命名和数据网络基础上的命名函数网络(Named Function Networking）。就像学术版IPFS，通过命名请求的数据通常是其内容的哈希（Content Hash）和命名函数网络，您可以通过其哈希值引用代码，然后请求在命名数据（Named Data）上输出命名函数网络，并通过它来编译代码或对数据和其他内容执行查询。那么，一个更好的操作系统看起来就应该像WebAssembly一样。
WebAssembly是一种脚本语言，它允许Actor之间互通信息。Actor的地址基本上是任意字节的字符串，母地址是子地址的前缀。WebAssembly使系统API像其他任何Actor一样被寻址和运作；这相对灵活。因此，WebAssembly几乎是完美的选择，一个低水平的编译目标；它是一个跨平台的低层级虚拟机，比Java虚拟机的层级低，但是比LLVM的层级高。WenAssembly本就已经存在于整个既有系统的外部，所以我们也就不需要额外说服任何人使用WebAssembly了。
此外，WebAssembly还是一个很好的沙箱模型，它有很多防止别人修改脚本的方式。例如，除非用户自行令地址匹配一个函数，并为它提供一种询问时间的方法，访问某些API的Web程序集的时间甚至是不可知的，因此它是完全确定的。此外，代码存储与数据存储器不同，一个Unix可执行文件可能编译了一些程序，但它可能还会运行一些其他的内存。一个流程结束后，另一个流程上实际上有代码，但代码可以将指针指向代码存储器，还可以对其进行修改，所以它很适合被用来应对病毒和恶意黑客之类的东西。
就算它因为种种原因无法做到这点，Actor/Script模型也能提供很多改进过的沙箱，用户可以在这些沙箱中进行大量实验，比如禁止将消息发送到某些前缀的Actor中。由于文件系统被设置的前缀将是该目录和文件夹中所有文件的前缀，于是，你完全可以限制特定文件系统对消息的接收。此外，你也可以通过将数据发送到某特定的、可以创建子Actor的系统Actor，来禁止其他前缀创建相对应的新Actor，以建立一个更可靠的、类似“p2p”的网络。
在这样可靠的系统上，脚本被发给Actor时，子Actor a1也将被创造出来，而第二个被发送的脚本则会创造出Actor b1 。第二个Actor可以检查第一个Actor，而第一个Actor不知道此过程。Actor行为上的错误会是可被检测的，因此，你可以提升它的可靠性。若你故意将错误代码发送给a1，要求b1对其进行检查，那么，我们可以通过统计被b1检测为错误的数据来确保问题尽可能完整地被发现。这是一个是高度可信任的代码的网络，由于这些代码只关联到三台电脑，而不是整个互联网的所有计算机，所以当取消运行这些代码也很容易。
最后是一个决定性的建构。想必你会尽可能保证你的代码不被篡改，且不包含任何恶意内容；于是，你可能会把某源代码广播给所有的服务器，让它们来运行代码，并检查它们的输出是否完全相同。你可以创建一个地址相对稳定的代理Actor，将其重新路由，重写消息，再把信息发送给子Actor，并根据相关的规则改变此Actor的行为。此外，你还可以做数据库查询。你可以把发送给数据，扫描此数据并执行各种功能。这在代码相对较小但数据却很大的情况下尤其好用——一小部分代码就足以在不将数据发送给客户端的情况下处理大量的数据。
权限系统的一大问题是如何决定权限内容。我认为，较好的处理的方法不是对所有权限选择“是”或“否”，或允许某个第三方应用获得某些信息，毕竟，这些都是审核员应该做的事；问题在于判断并理解问题的合理权限是什么——这可能比直接查询源代码要容易得多。既然某个程序能在不必查看网络的情况下查看您的文件，那么它就不应该仅仅被用于取消工作。你可以订阅您信任的订阅源所设的特定应用程式的权限，而不必设定每一个应用程式的许可——如果你不同意某许可，也可以换一个更能满足你需要的订阅源。
谢谢！
