科学・技術
Xanaduはエージェントを待っていた
Xanadu was waiting for agents (zed.dev)
要約
この記事は、テッド・ネルソンのハイパーテキスト構想「Xanadu」と、現代のコンピューティング技術、特にエージェントの登場によってその構想が実現可能になった経緯を論じています。ネルソンが提唱した「常に参照、決してコピーせず」「常にバージョン管理、決して上書きせず」という原則は、現代の分散システムやバージョン管理システム(Gitなど)の基盤技術によって、かつてないほど実現に近づいています。
全文翻訳
テッド・ネルソンが今年、私の頭の中から離れない。ネルソンはコンピューティングのパイオニアであり、1965年に彼のキャリアを定義するプロジェクト、プロジェクトXanaduの一部としてハイパーテキストという言葉を造語した。Xanaduで、彼はコンピューティングが何になりうるかについて特定のビジョンを持っており、それをドキュバースと呼んだ。彼は、ドキュメントのすべてのバージョンを保持できるシステムを想像した。ハイパーテキストリンクは、ソースとデスティネーションの両方を知り、引用は参照(コピーではなく)によって保持されるため、含まれるテキストはすべてそのアイデンティティとソースを維持する。このバージョンのコンピューティングでは、すべてが相互に接続され、xanalogical(相互アナログ的)になるだろう。私たちは、スパン(テキストの断片)までの帰属について話している。xanalogicalであるとは、2つのルールに従うことである。決してコピーせず、常に参照する(ネルソンの造語、トランスクルージョンとしても知られる)。決して上書きせず、常にバージョン管理する。ネルソンが設計したように、Xanaduはシステムの複雑さと膨大なブックキーピングの負担を自身で管理するため、ユーザーは決して忘れないシステムというメリットだけを体験することになる。無制限のブックキーピングというビジョンは、無制限のストレージと将来性のある命名スキームを必要とするが、ネルソンがXanaduに取り組んでいた数十年間、どちらも存在しなかった。そのため、90年代にウェブ技術が爆発的に普及したとき、開発者は容易さを優先してxanalogicalコンピューティングを迂回した。リンクは単純な文字列となり、ターゲットが移動すると壊れる。メンテナンスはユーザーの問題となり、システムの責任ではなくなった。しかし、誰でも素早く出荷するのは簡単だったし、実際そうした。Xanaduは、新時代の約束からコンピューティングで最も有名なベーパーウェア(実現しなかった製品)へと衰退した。ネルソンは、ウェブはハイパーテキストが意図していたものの平坦化されたパロディであると説明することにキャリアを費やしてきた。彼は正しいが、人々がすべてのリンクをたどったり、すべてのバージョンを比較したりする必要がなかったため、それは問題ではなかった。私たちは落ち着きのない種であり、他人が追っているリンクをたどったり、バージョンを読んだりする傾向がある。平坦で十分だった。そしてエージェントが登場した。エージェントが厄介な協力者であるという事実が、ネルソンのシステムにとって完璧な市民でもある理由だ。エージェントは、引用のソース、それに関する議論、実行された正確なコードに添付されたスタックトレースなど、人間が一度に頭に入れられる以上の層のサブテキストをたどることができる。フラグメントベースの表現は、それらの参照をロスレスにするため、テキストが変更されても各層は同じスパンに付着したままになる。エージェントはこれらの次元を一緒に読み、人間がその作業を監査できるように引用し、毎回、すべてのリンクを根気強くたどることができる。しかし、エージェントが見つけられるように、それらのリンクは実際にどこかに存在する必要がある。ネルソンのビジョンを今再訪すると、DeltaDBの設計目標とDeltaの約束を認識する。人間の注意力の限界に合わせて歴史を何十年も圧縮してきた後、私たちはより...xanalogicalなものによってより良くサービスされる新しい現実にいる。部品が存在する前にシステムを構築する方法数年前、私はEngelbartの1968年のデモを見て、共同編集者を作るために、彼のチームがそれに依存するすべて(新しいプログラミング言語、オペレーティングシステム、ディスプレイ)を発明しなければならなかったという私の認識について書いた。ネルソンも同じ問題を抱えていた(ただし、Engelbartが享受していたほどの資金はなかった)。彼は、権威が発行しないコンテンツを命名する方法や、決して削除しないほど安価なストレージなど、ほとんどの部品が存在しなかったため、Xanaduを構築できなかった。彼のチームは何年もかけて独自のデータ構造を手作業で構築したが、プロジェクトは途中で頓挫した。Wiredはネルソンの話を管理不行き届きとして描いたが、私は彼が依存関係ツリーが存在する何十年も前にXanaduを仕様化しただけだと考えている。依存関係ツリーは今日存在する私たちは、他の60年間のロードマップがドキュバースの失われた部品(カーネル開発、写真ストレージ、サーバーレスコールドスタート、共同カーソル)を提供してくれたため、今日Deltaを構築できる。ブレークスルーが普通の仕事を持ちながら、コンピューティングの次の時代を可能にするというのは、非常に興味深いと思う。中心のない世界のための時計。Lamportタイムスタンプ、1978年。人間とエージェントによるすべての操作は、アクターとLamportタイムスタンプによって名前が付けられ、永遠に続く。嘘をつけない名前。Merkleツリー、1979年、2005年のGitによって普通のものになった。Gitコミットハッシュは、正確な不変のプロジェクト状態に名前を付ける。DeltaDBは、コミット間のすべての状態に、それが派生したGitコミットと、その上に適用されたアクターとタイムスタンプのデルタIDのセットによって名前を付ける。調整なしの収束。CRDT、2011年に形式化され、過去10年間のZed自身の作業の中心。Deltaワークツリーは、異なる大陸の複数の人々とエージェントによって同時に編集できる。削除するには安すぎるストレージ。1981年には1ギガバイトあたり数万ドルかかっていたものが、今は1セントだ。デフォルトですべてのバージョンのすべてを保持する。すべてを複製するネットワーク。常時オンで高速なブロードバンドは、2000年代半ばにダイヤルアップを追い抜いた。すべてのスレッドはライブであり、各参加者のマシンとブラウザにデータが複製されている。数ミリ秒で呼び出されるマシン。FirecrackerクラスのmicroVM、2018年。Deltaのエージェントは、会話の途中で新しい分離されたクラウドマシンをプロビジョニングできる。永続的なコンテンツに対するビューとしてのドキュメント。Max BrunsfeldのTree-sitter、2018年、タイプしながら再解析するのに十分な速さ。Zedで開拓されたGPUI、フレームが描画されるたびにアプリケーション状態から新しいインターフェースを導き出すのに十分な速さ。Deltaスレッドは、永続的な構造化された履歴のライブな投影であり、平坦化されたドキュメントとして保存されるのではなく、再計算される。一つの詳細について、夢が大きすぎると言われ続けたキャリアの中で、ネルソンは夢を見すぎなかった。彼が欠いていた最後の依存関係は、新しい種類のユーザーだった。彼は人工的な読者を想像しなかったが、それらはSF(AsimovのMultivacやStephensonのLibrarianなど)に存在した。Xanaduは何十年も欠けているコンポーネントによってブロックされていたが、最も必要としていたのは完璧なユーザーだった。ドキュバースがバージョン管理で実現する理由実際のコード作成のほとんどは常にコミットの間に行われていたが、人間の記憶で乗り切っていたため、コンテキストを平坦化してもそれほど苦痛ではなかった(そして、キーストローク変更の完全な記録を読む人は誰もいなかった)。しかし、エージェントは何も覚えておらず、すべてを読むため、ネルソンが正確に指定したもの、つまり永続性と接続性を使用して新しい真実の源を捉える方法が必要だ。すべてのDeltaスレッドはその約束を果たす。会話とコードは、共有された履歴の中で一緒にキャプチャされる。画面上では、ファイルは依然として一次元の文字の文字列のように見えるが、その下では、DeltaDBはそれを安定したアイデンティティを持つフラグメントとして表現する。それらのアイデンティティにより、アンカーを作成できる。これは、周囲のコードが変更された後でも解決できるスパンへの参照だ。行番号は、あるスナップショットでテキストがどこに表示されるかを示すことができるが、アンカーは、スナップショット間でどのスパンを意味するかを保持する。エージェントがその座標システムをどのように構築できるかを探求してきた。エージェントが繰り返し読み、編集し、引用し、または戻ったファイルやシンボルは、次のエージェントのランドマークとなり、現在のコードに対して解決され、その理解が形成された会話にリンクされる。その表面表現の下にある因果関係のメタデータ、つまり各フラグメントを生成した操作や、それが構築された前の状態などを保存することで、DeltaDBはモデルに現在のコードだけでなく、その由来、蓄積された注意、および以前の推論をたどる方法を提供する。Xanaduの呪いを避けるXanaduには、最終的な障害モードがあった。これは自業自得だった。それは、劣ったフォーマットとの相互運用を拒否した。DeltaDBを世界に導入するにあたり、私たちはその間違いから学んでいる。既存のGitリポジトリで作業する。すべてのスレッドはGitブランチでもあるため、Deltaを開いたことのないチームメイトは通常のレポを見ることができる。ファイルは本物なので、エージェントが使用できるどのツールともシームレスに統合される。GitHubにリポジトリをミラーリングし続けることで、まだ切り替えの準備ができていない誰とでも作業できる(これは、この移行期間中のオープンソースIDEであるZedのアプローチだ)。