IPFSは何を目指しているのか (Roadmap抄訳)

ALIS の試用がてら、IPFS (InterPlanetary File System) のロードマップ https://github.com/ipfs/roadmap/ の一部を訳してみます。直近の開発計画みたいなところは飛ばして、IPFSの開発思想が分かる「将来の目標(Future Goals)」の部分を抜き出して抄訳・意訳しました。原文もこの翻訳もMITライセンスです。実現性がどれほどのものかは分かりませんが、かなり大きな目標を持ったプロジェクトですね。

IPFSミッションステートメント

IPFS のミッションは、人類の知識を保存し拡大させる、堅固でアップグレード可能な、オープンなネットワークを作ることです。

順番について

各ゴールは D = 難易度（あるいは「距離」）、E = エコシステムの成長、I = 重要性 の3つの軸で順にソートされています。各軸に対して1-5の数字で評価しています。

「難易度」については、簡単なもの、あるいは現状に対する必要な作業等が少ないものから順に並べています。次に「エコシステムの成長」、これはゴールの達成によって利用者が増える可能性の順に並べています。利用者のコミュニティが大きくなれば開発も加速することでしょう。最後の「重要性」は、IPFSが世界にもたらす影響がより重大で良いものである順番に並べています。

📦 パッケージマネージャ (D1 E5 I3)

パッケージマネージャは巨大なデータベースを形成し、管理しています。よく知られたパッケージマネージャを例に挙げると、コードライブラリの配布や（例：npm、pypi、cargo、……）、バイナリやプログラムのソースコードの配布 （例：apt、 pacman、 brew、……）、アプリケーションの配布（アプリストア）、他にもデータセットの配布などに使われています。

プログラミングやコンピュータを使う上で欠かせない要素である上に、IPFSにはぴったりのユースケースです。パッケージマネージャでは、IPFS のコンテンツアドレッシング (content-addressing) や P2P、非中央集権性、オフライン環境で動作することなどが非常に役立つでしょう。既存のパッケージマネージャがデータの配布やパッケージマネージャ自身の更新に、デフォルトあるいは少なくともオプションとして IPFS を使うようになることを目標にします。

訳注：ArchLinuxユーザの方は、IPFS 上のpacmanのミラーとして pacman.store を試すことができます。

新規のパッケージマネージャは IPFS ベースで作られるべきです。コードライブラリやプログラム、データセットなどの配布は恒久的で、堅固で、ネットワークの分断への耐性があり、認証されているべきです。IPFS はそれらを実現します。パッケージマネージャのレジストリはキュレーションとデータのシードを行うのみとなり、利用者全員分の帯域幅を負担する必要がなくなります。レジストリの非中央集権化も可能かもしれません。

🗂 大きなファイル (D1 E4 I3)

2020年中に、IPFS を 1GB より大きいファイルあるいはアーカイブを配布する定番の方法にします。

HTTP は大きなファイルや、あるいは多数の小さなファイルを配布するのに適していません。1GB よりも大きなファイルになると問題が起こり始めます（ダウンロードのレジューム、データの重複、帯域使用の局所集中など）。BitTorrent は一つの静的なアーカイブの配布には適していますが、それ以外の様々な状況では使いにくいものです。

IPFS は多くの問題を解決しますが、まだ大きなファイルを配布する定番のツールとなるほど使いやすいものとなっていません。IPFS が定番のツールとなるためには簡単・快適に使えて、そして高速であるべきです。「1 GB 以上のファイルの転送」という隙間を埋めるには IPFS は最適でしょう。後はパフォーマンスと使いやすさを少し改善するだけです。

🔄 非中央集権型Web (D2 E4 I3)

IPFS は非中央集権型Webアプリの土台となります。

Web 2.0では、Web は中央集権的にコントロールされています。ロケーションアドレッシングモデルやクライアント・サーバ型アーキテクチャが、中央集権的な組織がサービスやデータ、ネットワーク接続などを管理することへの依存を深めているのです。クローズドなプラットフォームが林立し、私たちのデータは中央集権的システムにロックインされています。これは情報流出や政府による管理、あるいは重要なサービスが運営者の独断によって突然終了するといったことへのリスクを高めてきました。

非中央集権型ウェブ (Decentralized Web) の核心は、 P2P 接続を用いることと、そしてユーザが自身のツールとデータを管理できるようにすることにあります。ユーザ同士が直接接続し合い、ハッシュや暗号化といった技術によって検証し、ネットワークは参加者によって管理されます。非中央集権型ウェブは（後に出てくる「分散型ウェブ」と異なり）分断耐性であったり、ローカル、モバイル、ないしオフラインネットワークでも使えることは目指しません。

IPFS は非中央集権型 Web の基礎を設計する上での問題を殆ど解決してきましたが、まだ簡単に使えるものとはなっていません。開発者が非中央集権型でサービスを運用できるようなツールの整備やソリューションの提供が必要です。（ただし、非中央集権的に動くように設計した上で、中央集権的な要素を加えてユーザの体験を向上させるということはあるかもしれません。）既存のシステムと連合して動作させるための設計が移行の要となります。

🔒 暗号化 Web (D2 E3 I4)

アプリとデータがエンドツーエンドで完全に暗号化されます。利用者が何を見て、何を書き、何を使っているのかについてのプライバシーが確保されます。

IPFS 上のアプリと、そのユーザのデータはエンドツーエンドで完全に暗号化され、ユーザのみがアクセスできます。何を書いて何を閲覧しているかといった秘密が最初から守られます。サービスを提供するノードは暗号化されたデータのみを扱い、平文にアクセスすることはできません。アプリ自体も分散され、暗号化され、ユーザの管理下にある安全なサンドボックスに読み込まれます。攻撃者（インターネットプロバイダを含む）はユーザのデータを盗み見ることが不可能になり、更に何のアプリを使っているのかすら分からなくなります。

♻️ 分散型 Web (D2 E2 I4)

情報やアプリはローカルネットワークやオフラインでも同様に使えるべきです。Web を分断しても動き続ける組織にしましょう。

Web とモバイルは、人々にとって最も重要なアプリケーションプラットフォームとなっています。これらが分断されたネットワーク内でも動くことを目指します。ネットワークアプリは使える限りのデータと接続を使い、非同期的にデータをやりとりし、ローカルの接続手段も使うべきです。主要なアプリは、オフラインであったりローカルなネットワークしか存在しない場合でも上手く動作するべきです。メール、チャット、フォーラム、SNS、共同作業ツール、ゲームなどのWebアプリをグローバルなインターネットへの接続なしに使えるべきです。

隣のコンピュータからファイルを受け取るのも簡単にしましょう（Airdropぐらい簡単に）。

訳注：同じ部屋の人にメッセージを送るために、毎度サーバから Web アプリの UI を読み込んで、メッセージの内容が一度サーバに送られて、などといった必要は本当はないわけです。Web アプリはローカルにキャッシュできるべきだし、ネットワークが直接繋がっているのであればそれを通してメッセージが相手に直接届くべき、というのが分散型 Web ですね。

👩🏽‍💻 個人 Web (D3 E4 I2)

データとプログラムをユーザの管理下に置きましょう。

Memex のアイデアを実現します。Web はより個人的なものになります。ユーザのデータはユーザが管理します。どのアプリが、あるいは誰が、ユーザのデータにアクセスできるかをユーザが決められるようにします。ユーザが Web を通して得る情報は全て手元にコピーされます。いつでも見返したり、調べたりできます。仮にアプリケーションの開発が止まってしまっても影響はありません。

👟 スニーカー Web (D3 E2 I4)

断絶したスニーカーネットを介して Web が機能し、情報やアプリを発信できます。

Web は完全に分散して動き、ネットワークの分断をも飛び越えることができるようになります。高レイテンシで途切れ途切れの非同期的な接続を介してアプリやデータのやりとりが行えます。そのように分断されたネットワークの中にいる人々が、他と同じアプリケーションを使い、同じ品質の体験をでき、また他のネットワークに情報発信もできるようになります。

Web は大規模な分断に耐えられるようになります。分断を超えた情報の流通が簡単になり、情報の遮断やコントロールは意味を成さなくなります。

🚀 惑星間 Web (D3 E3 I4)

火星。「惑星間 (InterPlanetary)」の夢を実現しよう！

SpaceX は 2022 年に人間を火星に送り込むことを計画しています。それまでに、IPFS は SpaceX に選ばれるような定番・最良の選択肢となっているべきです。火星の最初の人間が使うネットワークアプリは、IPFS を用いたものとなっているでしょう。

そのためには IPFS は堅固で、セキュリティが確かめられ、高速で、簡単に使え、広く知られているべきです。IPFS は幅広いプラットフォームをサポートし、特別なローカルネットワークや惑星間の距離を超えるネットワークも動作すべきです。これらを達成すれば、IPFS は不動の地位を築けることでしょう。

💾 パケットスイッチング Web (D3 E2 I3)

IPFSプロトコルはパケットスイッチングを行い、ネットワークは様々なトラフィックを容易に中継できるようにします。

土台となるプロトコル（libp2p、IPFS等）及びアプリ側のプロトコルはパケットスイッチング層の上で動作するようになります。BitSwap、DHT、PubSub のようなプロトコルのパフォーマンスを向上します。Web アプリケーションやユーザが隔離された専用の仮想ネットワークを形成できるようにします。

📑 データ Web (D4 E3 I3)

大きなデータセットが、オープンで、容易にアクセスでき、容易に複製でき、バージョン管理され、セキュアで、恒久的になります。

私たちは、重要な情報へのアクセスを失い続けています。単に消滅してしまう場合もあれば、検閲だったり、接続が失われてしまったりといった仮想の障壁によってアクセスできなくなることもあります。

情報へのアクセスを容易にし、バージョン管理されるようにし、安全にし、容易に複製したり見つけたりできるようにすることで、この状況を大幅に改善します。

✉️ パッケージスイッチング Web (D4 E2 I2)

Web 上のデータはパッケージスイッチングネットワーク上で動かせるようになります。テラバイト・ペタバイト単位のデータを保存したドライブを相手に送るといったことが普通になります。

アプリや、アプリのアセット、ユーザの作成したデータ、それら全てをハードドライブ等に入れて移すことができるようになります。IPFS はリムーバブルメディア上のデータを自然に利用できるのです。

例えば、Aさんがリムーバブルドライブに大量のデータを保存し、Bさんに郵送します。Bさんがドライブを挿してアプリでそれを読み込めば、Aさんが見せたかった状態が再現できます。ファイルへの書き出し、ファイルシステムやOSの差異などに悩まされることはありません。IPFS は「このドライブに入っている、このデータが欲しい」というときに使われる標準的な方法になります。正しいスニーカーネット Web の誕生です。

⛓ 自己アーカイブ Web (D4 E4 I4)

Web は恒久的なものになります。もうリンク切れはありません。半年で消えていた Web ページが、書物のようにいつまでも残るようになります。

情報を格納し、複製し、「誰が何を所有するのか」といった関係を超えて分散化できるようになります。巨大な組織から地方の図書館まで、誰でもインターネット・アーカイブの1ノードを運営できるようになるのです。

🏷 バージョン管理されたデータセット (D4 E3 I3)

IPFS はデータセットをバージョン管理する定番の方法になります。VCS によるコード管理のように、データセットの配布や利便性の向上が起きます。

IPFS はデータセットのバージョン管理やパッケージ管理、データの配布といった問題の解決を目指して考案されました。小さなファイルをバージョン管理し、パッケージし、配布することのできるシステムでも、巨大なデータセットの前には無力でした。IPFS はそういった問題の解決を目標とし、そのための様々なアイデアを含んでいます。

🗃 Interplanetary DevOps (D4 E2 I2)

プログラム、コンテナ、OS、仮想マシンに対するバージョン管理、パッケージ化、配布、読み込みを IPFS 上で行うのが一般的になります。

IPFS は様々な媒体を介して、アセットのバージョン管理、重複除去、パッケージ化、配布を行う優れた方法になります。IPFS はコンピュータのインフラ管理に革命を起こせるかもしれません。データセンタやサーバのセットアップに使われる一般的な方法となる可能性を秘めています。

📖 世界中の知識が DWeb を通じてアクセス可能になる (D5 E2 I5)

人類には知識への平等なアクセスが必要です。Wikipedia、Coursera、Edx、Khan Academy、その他多くのプラットフォームは場所やネットワーク環境などによらず利用可能であるべきです。地域毎に別のデータセットから別の方法で提供されるのではなく、世界で共有される一つのデータセットから、一つのプロトコルによって提供されるべきです。

🌐 WebOS (D5 E2 I3)

Web プラットフォームと OS が一本化します。

Web と OS の間の断絶がついに修復されます。OS とその上で走るローカルのプログラム、そして Web アプリは一本化されます。区別できなくなるのではなく、同じものになるのです。「インストール」「保存」といった概念は、IPFS 上でデータをピンすることに置き換えられます。ブラウザと OS が区別できなくなります。データは IPFS 上で管理され、OSのファイルシステムは IPFS に置き換わります。OS の状態はIPFS 上で管理でき、スナップショットを取ってある状態に戻したりといったことが可能になります。「OS のハッシュ値」を指定してブートできれば、OS の改ざんのような心配もなくなります。

IPFS Project Roadmap