Project Xanadu: さらに振り返る

Project Xanadu: さらに多くの後知恵

Project Xanaduの成功と失敗に関する回顧録：設計の反復、意味のあるユースケース、実用性の欠如が、価値あるビジョンを実用的なものに成熟させるのを妨げた。（そして私のアプローチとの対比。）

2024年12月、サンフランシスコ訪問中に、私は最後の瞬間に、そこでしか起こり得ないパーティーに招待される幸運に恵まれました。それは、ハイパーメディアの先駆者であるテッド・ネルソンの1974年のマニフェスト『Computer Lib/Dream Machines』の50周年を祝うもので、Project Xanaduのハイパーテキストのビジョンを称賛するものでした。私は20年間英語のWikipediaに貢献しており、15年間Gwern.netに取り組んできたので、ハイパーテキストについて強い意見を持つ人々のパーティーを欠席するわけにはいきませんでした。

ホストのジェームズは、ネルソンの記念品を驚くほど豊富に用意してくれていました。その本（実物は私が思っていたよりもはるかに大きく印象的で、拡大鏡が必要なCompact OEDに似ており、それも提供されていました）、ネルソンの1997年の著書『The Future of Information』だけでなく、彼のスワースモア大学の謄写版雑誌のコピー、そして最も印象的だったのは、様々なXanadu実装のコピーを実行しているいくつかのビンテージコンピューターでした。

テッド・ネルソンは87歳でまだ生きていましたが、残念ながら出席できませんでした。幸いなことに、出席者の一人は、Autodesk時代（1988年〜1993年頃）の元Xanaduプログラマーの一人であり、彼の話を聞くことができました。

それらは、私たちがコンピューティングの初期時代をロマンチックに捉えがちですが、ハードウェアの制約は非常に厳しく、生産的な開発を困難にしていたことを思い出させてくれました。過去のソフトウェアシステムにおけるいくつかの失望は、制約を回避するためにどれだけの時間と創意工夫が費やされたかを思い出すと、より理解しやすくなると思います。例えば、McIlroy 1982年の論文は、1MB未満のRAMに収まる便利なスペルチェッカーを得るために、数ヶ月にわたる巧妙なアルゴリズム設計と最適化を行ったことを正当に誇りに思っていますが、これは今日では数行のJavaScript（そしてLLMによって書かれるでしょう）で書かれるでしょう。

例えば、彼が説明したように、彼らはXanaduをSmalltalkでプロトタイプ化しました（これは、非常に生産的で快適な言語/OSであり、そのオブジェクト指向モデルがハイパーメディアに美しく適合するため、理にかなっていました）。しかし、それをC++にクロスコンパイルし、さらにそれをコンパイルする必要がありました…コンパイルに約1週間かかりました。1分でも、1時間でも、1日でもなく、1週間でした。（そして、Gwern.netの数時間に及ぶコンパイル時間が私の開発速度にとって悪いと思っていました！）彼はまた、C++の愚かさやコンパイルの問題に対処するのに多くの時間を浪費しなければなりませんでした。1

私たちが目にしたPCでそれを実行できるようにすること自体が挑戦であり、パーティーの理由の一つでした。

正直に言うと、私は時々、Gwern.netのクライアントサイドのトランスクルージョンやポップアップ機能を実装するのにSaid Achmizが数日しかかからなかったのに、Autodesk時代のXanaduの年月が、複数のフルタイムのマンイヤーを費やしても、なぜこれほどわずかな成果しか上げられなかったのか疑問に思っていました。しかし、当事者からいくつかの苦労話を聞いたことで、物事を正しく理解し、当時の人々がいかに信じられないほど計算能力に乏しかったかを思い出させてくれました。（CPUよりもストレージの方が悪かったかもしれません。PDF、PostScript、HTMLファイルをホストできることを当然のことと思っていますが、私のホストしているドキュメントの相当な割合は、1990年代中盤のPCの総ハードディスク容量（おそらく50MBのハードディスク）を超えています。一方、Gwern.netのエッセイのMarkdownソースファイル自体は約40MB、注釈はその倍、そして最終的なサイトは221,438MBです！）

大学の雑誌は驚きであり、めくってみると楽しかったです。若い頃のテッドはすでにたくさん書くのが好きで、自分のアドバイスを配っていました。誰かが、ネルソンはハリウッド監督になることを夢見て、代わりにテクノロジーに進んだことを後悔したと言いました。それは理にかなっており、彼の作者的なソフトウェア開発のアプローチ（例えば、50年経っても彼が「プログラマーではない」と主張すること「not a programmer」）や、「編集決定リスト」のような映画編集の比喩の使用を説明していると思いました。

私も『Computer Lib/Dream Machines』をきちんと読んだことがなかったので、数ページをめくってみました。複数のコラムで構成された非常に大きな本で、できるだけ多くの情報を詰め込もうとしていたのが興味深かったです。ネルソンは読者がコンピューターについて何も知らないと仮定しており、バイトやファイルのような基本的な概念を説明するためにゼロから始める必要があります。（年配の方なら本当に拡大鏡が必要でしょう。）

後の（そしてはるかにマイナーな）本『Future of Information』も、章の構造がユニークで、中心的な要約章があり、複数の順序で読むことができた点で興味深かったです。

Yuxi Liuは、Xanaduが、データベースやAIと密接な関係を持つ、カリスマ的なリーダーが一度も考えを変えず、オープンソースを嫌い、同様の「病的な科学」の兆候を示した、もう一つの有名な長期間にわたる壮大なプロジェクトであるCycに似ていると指摘しています。そして、それを考え、Xanaduの資料を再読すると、私も同意します。

私はXanaduのPCを少し触ってみましたが、それが動いていることに感心しましたが、私やパーティー参加者のほとんどはそれに触れるのをやめました。UIが異質すぎたのです。ジェームズのデモを見るか、それに類するものが必要でした。ハイパーテキストシステムは、特に25年前に使ったか、あるいは一度も使ったことのないコンピューターのOSで動作している場合、即時の探索には向きません。

しかし、画面に表示された典型的なProject Xanaduのデモ、つまり創世記の冒頭部分と、トランスクルージョンやコメントを示すために右にジグザグに伸びる有名な行を見て、突然悟りを得るために、それらをそれほど多く使う必要はありませんでした。

「なんてこった—全く読めない。」

特に線が交差していたため、線は混乱した散らかりでした（サイドノートのレイアウトにおける永続的な問題で、アウトラインによってさらに悪化していました）。画面が非常に小さかったため、「サイドノート」のどれも読むことができませんでした。スクロールしているだけでも、多くの可能な位置で、線のために何も読むことができませんでした！何も読めないことが多いドキュメントUIが、良いアイデアだと思われたことがあったのでしょうか？2 UIはひどすぎました—決して機能しなかったでしょう。私の4Kモニターのような大きな画面でも、それは望みません。

そして、テキストの選択について考え、UIが本当の問題ではないことに気づきました。そして、何十年もの間、問題はチームでもありませんでした。

サイドバイサイドの範囲トランスクルージョンという概念全体が、問題を探している解決策なのです。

範囲指定のトランスクルージョンとコメントは、創世記の本文には理にかなっていました。そこには各行の詳細な注釈があり、複数の矛盾するテキスト（有名な自己矛盾する創世記の創造の物語のように）からどのように編集されたかを整理する多くの聖書批評があります。しかし、私が「ねえ、Gwern.netでもサイドノートや範囲トランスクルージョン/コメントを双方向のバックリンク付きでできるよ、そして私の『Suzanne Delage』短編分析で実際にやっている！」3と考えたとき、突然気づきました。できるけれど、ほとんどやりません。なぜなら、誰も本当にそれを必要としていないからです。これは、テッド・ネルソンの「並列文書の例」「Examples of Parallel Documents」を見ると特に顕著です。再びテキスト批評（聖書、『ハムレット』、「羅生門」と映画『羅生門』）、バージニア権利章典が米国権利章典に影響を与えたという広げられた例、そして非常に疑わしい例—聖人のリスト、組織内の電話通話、そしてコメディTVエピソード…？

世界中のほとんどのテキストは、実際にフィスクされる必要があったり、特定の行や段落がトランスクルージョンされる必要があったりしません。ほとんど誰もタルムードの注釈のように、何層にもネストされた注釈を行っていません。ほとんどの実際の引用は、ターゲット全体への引用です。そしてそれらでさえ、私たちはその99%を見たくないでしょうし、良い1%をどのように整理すればよいかわからないでしょう。なぜなら、それぞれ異なる目的を持っている可能性があるからです。（オンラインコメントを時々見てください：日付順、人気順、あるいは何らかのカルマや「ページランク」順、長さ順、ページ著者が直接返信したかどうか順に並べますか？）

retrospectively、私は『Lib/Dream』でも『Future』でも、紙媒体で「トランスクルージョン」の例を見たことがないのは、示唆的だと思います。ネルソンは、紙媒体でサイドバイサイドのレイアウトや範囲トランスクルージョンをいくらでも使用できたはずです。なぜなら、ソフトウェアは障害ではなかったからです。彼はそれらを自分でレイアウトしており、好きなように描いたり、イラストを描いたり、コピーしたりすることができました。しかし、彼はそうしませんでした。なぜなら…それは本にはそれほど有用ではないからです。彼自身の本でさえ。（前の段落を引用できるなら、トランスクルージョンは必要ありません。）

映画でさえ、2つの映像ソースを並べて配置し、一方を他方に「コメント」させることが容易であっても、これはめったに行われません。水平または垂直の並置に頼るのではなく、映画は時間の第三次元を使用し、カットやその他のトリックの豊かな語彙を発展させて、同じことを行います（私たちが『戦艦ポチョムキン』以前の映画を見るまで気づけない程度に）。空間的な並置は様々な状況で使用されますが、デフォルトにはほど遠いです。ピクチャー・イン・ピクチャーのようなレイアウトを行うことが慣習となっているのは、まれな状況だけです。主なニッチはライブ放送であり、複数のアングルから撮影して一貫して編集することが不可能な場合です。ライブインタビューを行う場合、2つの顔を同時に表示するのが一般的ですが、後で編集される際には、しばしばカットごとのシーケンスに変換されます。同様に、ストリーマーは、実際のストリームを行うのに忙しく、カットする多数のフィルムソースがなく、忙しい熟練したスタッフがいないため、簡単に「カット」することはできませんが、「ベストヒット」を作成する場合、再配置またはズームインするかもしれません。（ホロライブのストリーマーが、数千万ドルが関わる大規模な年次コンサートで、ストリーミングのようなサイドバイサイド形式を採用せず、より典型的なコンサート撮影を採用すると予想します。ミクエクスポやボーカロイドコンサートのように。）注目すべきは、ライブ放送の予算が非常に高く、品質が最優先される場合（NBAゲーム、NFL、Met HDオペラ放送など）、多数のカメラと「ディレクター」および複数のスタッフを配置できる場合でも、静的なピクチャー・イン・ピクチャーやサイドバイサイドの配置に落ち着くことは通常ありません。代わりに、単一のフィードを異なるカメラ間で急速にカットすることを選択します。これにより、「アクションを追う」ことができ、カメラマンに事前に移動を指示してその場で新しいアングルを作成させ、ゲームの流れの評価に基づいて意味のあるリズムを作成しようとします。

そして、それがGwern.netにこの特定のトランスクルージョン機能を2023年頃まで追加しなかった理由です。文学分析に触発されました。私には必要ありません。英語Wikipediaも必要ありません。Redditも必要ありません。Twitterも必要ありません。個人ブログの約100%は必要ありません…文学批評やテキストのコメントを行う場合を除いて、それはそれほど有用ではありません。これは、ウェブの約0%（2025年または1989年）を説明します。それらの線はすべてクールで未来的ですが、実際のGwern.netのエッセイでそれらをどのように使用するか、そしてそれがどのように見えるかを考えると、頭痛がしてきます。

有名なProject XanaduのUI/UXは、「SFインターフェース」です。『マイノリティ・リポート』の3Dジェスチャーインターフェースや、『スノウ・クラッシュ』の仮想現実のようなものです。誰もが見て、どれほどクールに見えるかに魅了されますが、実際には使用するのが苦痛で、「ゴリラアーム」を引き起こすひどいアイデアです。プロトタイプやモックアップを試すと、使い始めてすぐに、これは機能しないと気づき、完全に捨てなければなりません。

これはハリウッド監督のコメントを思い出させました。Project Xanaduは、ハリウッド監督が考えるワールドワイドウェブの姿だと言えます。実際に実際のプロジェクトで使用してみない限り、それに信じることはできません。テッド・ネルソンがそれほどカリスマ的でなく、説得力のある書き手でなく、自分のビジョンへの信頼が少なかったなら、これはもっと早く明らかになったでしょう。そうではなかったため、ダグラス・エンゲルバートと同様に、ネルソンは（もしそれが言葉であるなら）「カニンガムの法則」の生きた体現者としての名誉を楽しんでいます。つまり、非常に重要なトピックについて非常に間違っていたために、他の人々が正しくなるのを助けた歴史上の人物の一人となったのです。

実際、それはまた、私が常に不思議に思っていたXanaduの著作権への強調についても説明しています。現代世界のどの部分が、有用なハイパーテキストシステムほど有害で反対するものがあるでしょうか？現在の最大主義的な著作権法ですが、Xanaduの17の原則は、「トランスクルージョン」のような些細なことよりも、著作権者のためにウェブを安全にすることに多くの時間を費やしています。それは、任意のレベルのトランスクルージョンでのマイクロペイメントをサポートする必要があり、デフォルトライセンスを持ち、ネットワーク中立性を回避し、任意のソースの許可のないトランスクルージョンを許可するなどが必要です。

Xanaduの17の原則（Wikipedia版）

1. すべてのXanaduサーバーは一意かつ安全に識別されます。
2. すべてのXanaduサーバーは独立して、またはネットワークで運用できます。
3. すべてのユーザーは一意かつ安全に識別されます。
4. すべてのユーザーはドキュメントを検索、取得、作成、および保存できます。
5. すべてのドキュメントは任意の数の部分で構成でき、各部分は任意のデータ型にすることができます。
6. すべてのドキュメントは、所有者がアクセスできる他の任意のドキュメントへの仮想コピー（「トランスクルージョン」）を含む任意の種類のリンクを含めることができます。
7. リンクは可視であり、すべてのエンドポイントからたどることができます。
8. ドキュメントへのリンクの許可は、公開行為によって明示的に付与されます。
9. すべてのドキュメントは、任意の望ましい粒度でロイヤリティメカニズムを含み、仮想コピー（「トランスクルージョン」）を含む任意の部分への支払いを保証できます。
10. すべてのドキュメントは一意かつ安全に識別されます。
11. すべてのドキュメントは安全なアクセス制御を持つことができます。
12. すべてのドキュメントは、ユーザーが物理的な場所を知らなくても、迅速に検索、保存、および取得できます。
13. すべてのドキュメントは、任意の場所からのアクセス頻度に応じて、適切な物理ストレージに自動的に移動されます。
14. すべてのドキュメントは、災害時でも可用性を維持するために、自動的に冗長に保存されます。
15. すべてのXanaduサービスプロバイダーは、ドキュメントの保存、取得、および公開に対して、任意の料金をユーザーに請求できます。
16. すべてのトランザクションは安全であり、トランザクションの当事者のみが監査できます。
17. Xanaduクライアントサーバー通信プロトコルは、公開された標準です。
    サードパーティのソフトウェア開発と統合が奨励されます。

私は、これらが可能または望ましいと信じられた方法を常に不思議に思っていました。著作権者はもちろん、これのいずれにも従うことを拒否し、Xanaduを恐怖と嫌悪で拒絶するでしょう。なぜなら、それは数え切れないほどのビジネスモデルと知的財産制度、および取引を爆破し、悲劇的共有地の悲劇、ホールドアウト、プリマドンナ、著作権所有者の支配などによって即座に停滞するからです。しかしもちろん、あなたが自分自身をハリウッド監督だと見なすなら、著作権の神聖さについて強い感情を持ち、トランスクルージョンの論理に従ってフリーソフトウェア/オープンソース（最後のXanaduの原則にもかかわらず、ネルソンは明らかにFLOSSを信じておらず、NDAを主張していました）に反対することに熱心になり、あなたが期待するような「セマンティック」ウェブを信じるでしょう…何でもうまくいくと。

インターネットで80億人がオンラインになり、世界の多くがインターネットで動いている現実とは対照的です。それは、起こりうるすべてのことが1日に無数に任意に起こる悪夢のようなダークフォレストです。あなたが信じていたすべての不変の法則が、世界のどこかで壊れていることが判明します4。そして、トラックバックの双方向リンクのようなすべての素敵な機能は、スパマー、愚か者、悪党、国家主体、出現するバグ、またはハッカーによって無慈悲に悪用されるでしょう…

これらの原則のほとんどは、現実世界で試さない限り意味がありません。現実世界では、それらの多くが疑問の価値があるだけでなく、多くの主体によって激しく反対されるだけでなく、 outright illegal であることがわかります。（堅牢な分散ファイルストレージの原則を最も体現し、効率のためにユーザーが要求するファイルに近づけたシステムの一つは… Freenetでした。これはすぐに児童ポルノで悪名高くなりました。）

したがって、私にとって、Project Xanaduは、設計者が投資しすぎる前に、設計をモックアップおよびプロトタイプ化しなければならない理由のケーススタディです。Xanaduは「Worse is Better」の犠牲者ではありませんでした。それは単に問題を探していた解決策でした5。（似たようなことがArbitalにも当てはまるようです。それは、Eliezer Yudkowskyという唯一の実際のユーザーを持っていましたが、ビジョンを伝えることや、必要なようにモックアップされた明確なプロトタイプとユースケースのセットを作成することに苦労しました。そしてXanaduのように、それは長期的な非営利FLOSSの努力であるべき四角いペグが、ソフトウェアスタートアップ企業の丸い穴に押し込まれたものでした。）

Xanaduのデモとユースケースは、必要であればハサミと糊で紙にどのようにレイアウトされたのでしょうか？6 なぜそれらは常に「創世記」のような、まったく代表的でないユースケースなのですか？もしあなたが座って、近くにある普通の技術文書や雑誌を範囲トランスクルージョンの山に変えようとしたら…それはどれほどうまくいくでしょうか？範囲トランスクルージョンが挿入されたテキストのどれだけが、可能またはべきでしょうか？（このXanaduに関するページでさえ、現時点では、外部から大きなブロックをトランスクルージョンする必要があるのは1つの点だけです。WikipediaからコピーされたXanaduの原則のリストです。これはすでにポップアップリンクでカバーされており、インライン化は簡単です。）

もしあなたがこれを行った場合、答えは急速に「はい、ハイパーリンクが必要です。それらは非常に役立ちます。画像、音声、ビデオなどの任意のメディアタイプ、または書籍の特定のページにリンクできる必要があります。リンク切れしないリンクが必要です。スクリプト言語が必要です（Xanaduはこれについて沈黙しています）。しかし…これらの他のことのほとんどは本当に必要ありません。もし私がGoogle Docsのような分散型共同編集エディターを作成していたなら、CRDTsやXanaduの同様の「enfilades」のようなものが必要になるかもしれませんが、公開している文章では必要ありません！」となるでしょう。

そして私にとって、Gwern.netに取り組み始めたとき、ほとんどすべての機能は私が持っていたユースケースによって駆動されていました（主に私が怠惰だからです）。Said Achmizでさえ、私たちの方法は複数のユースケースを待ってから、それらをすべて有効にしながら実装することでした。（必然的に、Gwern.netは非常に大きく複雑になったため、エッジケースを発見し、設計を改訂する必要があり、多くの変更については、それらを放棄しています。）

ハイパーテキストについて、私は自問します。「基本的なブログのようなHTMLページや英語のWikipediaページが提供しないもので、私に必要なものは何か？」そして答えは「URLからランダムな段落の塊をトランスクルージョンする必要はありません7。GNU Infoが書くように奨励するような、実際のコンテンツよりも長い目次に入れ子になった、たくさんの小さなアトミックな1文のページは必要ありません。私が必要なのは、一種の要約または概要です。読者ができるだけ速く、摩擦なく閲覧でき、参照を素早くスキップしたり、興味深い引用をたどったりできるようにしたいのです。私は…LupinのWikipediaポップアップのようなものが必要です。これは、最もカジュアルなマウス操作だけでWPをナビゲートできますが、それを強化したものです。」8

XanaduのUIの欠点は、トランスクルージョンを「水平」でサイドバイサイドとして扱い、すべての読み書きがテキストの最も低い生のレベルで行われなければならないと仮定したこと（「タンブラー」などを動機付けた）ですが、それは「垂直」でポップアップ表示され、テキストのさまざまな抽象化レベル（リンクアイコン→タイトル→概要→セクションなど）で「ズームイン」および「ズームアウト」されるべきでした。これにより、任意の範囲を指定できることが重要でなくなります。特に、重要な範囲はより高いレベルに引き上げることができるためです。

ポップアップがシームレスなナビゲーションを提供すると、実際にはどこでもトランスクルージョンを使用していることになります。ポップアップの内側です。そして、すべての概要を提供するという考え方にすべてを賭けると、それを一般化するのは自然です。URLの2つのバージョン（「小さい」概要と「大きい」URL全体）がある場合、なぜ「中」バージョンも持てないのでしょうか？

ここには自然な停止点がないため、アウトライナーのような階層ビューの「セマンティックズーム」「semantic zoom」を単純に採用できます9。これは、セクションから段落の文まで、すべてをインプレースでズームイン/アウトできる開閉機能、またはリンク全体ではなく概要をトランスクルージョンすることに大きく依存するタグディレクトリ（「注釈付き参考文献」を作成するため）、またはXanaduや英語Wikipediaのバックリンクよりも大幅に改善されたバックリンク（他のページでのトランスクルード/リンクコンテキストを表示するために「逆」トランスクルージョンを実行する）など、多くのエレガントなGwern.net UI/UXデザインパターンにつながります。そして、ローカルアーカイブシステムにより、リンクは壊れないだけでなく、多くのURLをポップアップしてクリーニングされたローカルアーカイブバージョンをトランスクルードすることで「プレビュー」できます。

外部リンク

• ディスカッション: HN

---

1. この点の意味を理解するのに少し苦労しましたが、どうやら本当にこうなったようです。これはおそらく、1999年8月に擬似オープンソースとしてリリースされた同じC++コードベースだったのでしょう。ドン・ホプキンス（NeWSやHyperTIESのような初期のハイパーテキストシステムに非常に傾倒していました）は次のように述べています。「彼らは当初XanaduをSmalltalkで書きましたが、その後SmalltalkからC++へのコンパイラを実装し、最終的にそのコンパイラの機械生成出力をリリースしました。それは読みにくく、実質的に役に立たないものでした。それは『オープンソースソフトウェア』のポイントと目的を完全に外れていました。」そして「まったく。誰もそのソースコードで何か役に立つことができると本気で信じていますか？コードを見てください。それはほとんどコメントのないグルーで、グルーをグルーに接着しているだけです。再利用できるものは何もありません。」↩︎
2. これに対し、Gwern.netのUIは、ほぼどこにいても、何をしていても、良い「データインク比率」で多くの有用なテキストを見ることができます。Apple Watchでもサイトを正常に閲覧できます！↩︎
3. アンカーをトランスクルードまたはポップアップできるため、<span>/</div>ラッパーを定義するだけで任意の範囲をトランスクルードできます。したがって、「Suzanne Delage」の場合、各ストーリーの段落を名前付きスパンラッパーで囲み、それにリンクするだけです。（そして、これらのバックリンクはストーリーセクション内にも表示されるため、ストーリーのどの部分が分析の他の部分で参照されているかを確認できます。）元のMarkdownソースで正確なバイト範囲を指定する必要はありません。これは、私が段落を追加または編集するにつれて、それらの範囲が変更され続けたため、良いことです。

これは、ネルソンがバイト範囲に固執したことの問題点（おそらく、フィルムリールから指定されたフレームをスプライシングするという彼の古い比喩に由来する）が、セマンティクスを無視していることを示しています。

HTMLファイルの「バイト123〜456」をトランスクルードしたくありません。特定の意味のある要素XYZをトランスクルードしたいのです。それは現在バイト123〜456に格納されているかもしれませんが、長さが変更されたり、ページ内またはページ間で移動されたり、任意に書き直されたり、マークアップが挿入または削除されたりする可能性があります。ネルソンが1960年代にフィルム編集について学んでいた頃、フィルムのフレームは事実上「セマンティックに不変」だったかもしれませんが（アナログフィルムで撮影されたフィルムは事実上固定されているため）、テキストはそうではありません。編集履歴全体にアクセスできるかどうかに関わらず、以前に著者が指定した範囲に対応する範囲はすぐに存在しなくなる可能性があります。（テキストフラグメントでさえ、コンテンツアドレス可能な視点を取っています。Webページの最も近い部分を見つけるために、数フレーズまたはキーワードを格納しようとします。）

したがって、古いバージョンからトランスクルードできるように、すべてのアクション履歴にアクセスすることに依存する必要があります。これがラクダの鼻です。そして、それをしたいのであれば、自分でコピーをホストできます！↩︎
4. 「異なるテキストエンコーディングをどのように処理しますか？すべてのものがUTF-8になるわけではないので」といった単純なことさえ、Project Xanaduでは簡単な答えがないようです4。
5. Worse is Betterでは、「Worse」システムは最終的に元のより良いデザインと同じ問題を解決しますが、より悪い方法で（はるかに多くの研究開発を必要とし、より多くの任意制限、ペーパーカット、不必要な複雑さなどを伴うソリューションにつながります）。↩︎
6. あるいは、ホプキンスが1999年に主張したように：「Xanaduはソースコード自体を文書化するために使用されましたか？ブラウズ可能なクロス参照されたMozillaソースコードと比較するとどうですか？あるいは、クヌースのTeXを用いたLiterate Programmingの古典的な作品と比較するとどうですか？」↩︎
7. 特定のパートを引用する必要がある場合でも、私はいくつかの異なるパートを引用する傾向があり、理想的にはそれらは変更されるでしょう。例えば、欠落しているハイパーリンクやコメントを追加するなどです。そのためには、自分でトランスクルードするバージョンを構築する必要があるでしょう。ですから、オリジナルでわざわざやる意味があるでしょうか？↩︎
8. Lupin's Toolは2005年頃のものですが、私の知る限り、Gwern.netのポップアップとトランスクルージョンは、JavaScriptベースのDHTML（1997年頃）のほぼ最初から可能でした。完全に再帰的なポップアップはできなかったかもしれませんが、<script>が新しいJSエンコードデータをロードするのにどれだけ制限されていたかによります。少なくとも、HTTP接続を閉じずにクライアントが任意のデータの要求を偽装できるようにする、または代わりに<iframe>を使用する、あるいはJavaアプレットを補助として使用するなど、大規模なハックなしでは。しかし、私たちのポップアップの最初の数世代は間違いなく簡単に実装できたでしょう。↩︎
9. アウトライナーアプローチがハイパーテキスト全般で普及しなかった理由の1つは、それらが便利である一方で、著者に過度の負担を強いることだと思います。私はウェブサイトデザインを探求するためにこの作業を行うことをいとわないですが、多くのウェブサイトが英語のWikipediaやGwern.netのようになるべきだという考えは狂っています。しかし、LLMは、人間が必要なものだけを書く間に、自動的に要約/展開して完全な階層を構築するための多くの新しいデザイン機会を開きます。これにより、多くの古い「思考ツール」のアイデアが復活し、最終的にそれらが使用可能になると考えられます。↩︎