未分類

本記事について 以下はEthResearchに投稿したものの日本語訳です（機械翻訳を使ったため、誤訳が含まれる可能性があります）。 既存のウェブでは、ユーザは自分のデータを管理することが難しく、サービスにロックインされています。「ポータブルウェブ」は既存のウェブと並行して存在し、ユーザーにデータに対するより大きなコントロールを提供し選択の幅を広げることを目指しています。ポータブルウェブ上のアプリケーションは、主に公共インフラとしての役割を果たすものを想定しています。 本記事では、ポータブルウェブの核心的なアイデアを紹介します。その実現可能性に直接関係のない詳細な仕様は含まれていません。 要約 ハッカブル：ユーザーがウェブアプリケーションをカスタマイズできる クラスターは単一のアプリケーション単位を表します。 誰でもクラスターを作成でき、クラスター内では、クラスター作成者以外の主体が自分のクライアントを作成したり、サーバーを提供したり、APIスキーマを定義したり、マイグレーションスクリプトを書けます。 クライアントとサーバーは疎結合で、APIスキーマを通じて接続され、異なる開発者が独立して作成できます。 例えば、ユーザーは自分のニーズに合わせたカスタムUIを作成し、アプリケーションを使いやすくすることができます。また、自分でAPIスキーマを開発し、特定の機能を拡張するためのサーバーをホスティングすることも可能です。このように、ポータブルウェブでは、開発者だけでなく一般ユーザーもアプリケーションの進化に積極的に貢献できます。 データロックインなし：ユーザーが自分のデータをコントロールできる クライアントはユーザーのデータをキャッシュします。 APIスキーマに準拠したサーバーを使用することで、クライアントは異なるサーバー間でキャッシュされたデータを共有できます。 クライアント上のキャッシュデータは、マイグレーションスクリプトを使用して移行することも可能です。 クライアントはユーザーが送受信するデータをキャッシュしますが、このデータをユーザーが選択したサーバーに送信することで、分散的に管理されます。必要に応じて、ユーザーは自分のデータを他のサーバーに移行でき、特定の組織にデータがロックインされることを防ぎます。 クリプトネイティブ：インセンティブメカニズムとしてのクリプトエコノミクス ポータブルウェブでは、クラスター提供者がトークンを発行し、そのトークンへの実需を生むクラスターを提供することでインセンティブを得ます。 クラスター内のすべての支払いは、発行されたトークンで行われます。 新しい参加者の存在はクラスターの成長に貢献するため、元のクラスター提供者は彼らを排除しません。 Web2が独占や勝者総取りのゲームとして機能する一方で、ポータブルウェブは協調的で包摂的なアプローチを促進します。 背景 Web2 Web3コミュニティでは、Web2の問題点について広く議論されていますので、ここでは深く掘り下げません。しかし、強調しておきたいのは、Web2の問題の根本はそのアーキテクチャにあるということです。具体的には、ブラウザがターゲットのURLに直接アクセスする方式です。 Web2のアーキテクチャでは、ユーザーは自分が生成したコンテンツを所有権やローカルコピーを保持せずにサービスに直接投稿します。ユーザーのアカウントやコンテンツはサービス内に存在し、そのサービスがデータを蓄積します。この蓄積は新しいデータの生成を加速させます。ユーザーが別のサービスに移行して同じレベルの利便性を得ることは非常に困難です。そのためには、ユーザー自身がコンテンツを移行する必要があり、他のユーザーも大規模に移行する必要があります。 既存のウェブアーキテクチャは、コンテンツのロックインやアカウントのロックインを引き起こし、それが権力の集中や勝者総取りのダイナミクスを助長します。 Web3 Web3は既存の権力構造に挑戦し、ユーザーの権利を最大化するとしばしば主張されますが、実際には現在のところ、Web2の上にブロックチェーン層を追加しているに過ぎません。 ブロックチェーンは分散型ですが、既存のWeb3アプリケーションが現在のウェブアーキテクチャの上に構築されているという事実は、そのポテンシャルを損なっています。 ポータブルウェブのアーキテクチャ 上記の問題を解決し、ユーザーの権利を最大化しながら分散型のウェブを実現するためには、新しいアーキテクチャを構築する必要があります。その提案された解決策がポータブルウェブです。この新しいウェブアーキテクチャは、ユーザーが自分のデータとアイデンティティを完全にコントロールでき、開発者やサービス提供者が協力して単一のアプリケーションを進化させることを可能にします。 ポータブルウェブの構成要素 ポータブルウェブブラウザ ブラウザは、ポータブルウェブを実現するためにいくつかの重要な役割を果たします。 制御されたサーバー通信：クライアントが通信できるサーバーを制限します。ユーザーが明示的に意図しない限り、クライアントはサーバーとやり取りできません。 通貨の制限：アプリケーション内での支払いに使用される通貨を制限します。ブラウザにはウォレットが含まれており、支払いはクラスターで最初に設定された通貨でのみ行われます。デフォルトでは、ブラウザは内部の取引所（DEXまたはCEX）と連携しているため、ユーザーは使用されている通貨を意識しません。 アイデンティティ管理：ユーザーのアイデンティティを自己主権型アイデンティティ（SSI）として管理し、サーバーやクライアントがユーザーのアイデンティティをロックインすることを防ぎます。 ブートストラップのためのビルトインサポート：インデックスクラスター用のクライアントとサーバーの情報が内蔵されており、ブートストラップをサポートします。ユーザーは後で他のクライアントやサーバーに接続できます。 データ移行と更新：クライアントで指定されたマイグレーションスクリプトを実行してデータを転送し、クライアントの更新を管理します。 クラスター クラスターは、その目的ドキュメントによって識別される単一のアプリケーションを表します。 クラスターを構成する要素は次のとおりです： 目的ドキュメント APIスキーマ マイグレーションスクリプト クライアント サーバー 誰でも目的ドキュメント以外のコンポーネントを提供して、クラスターの開発と進化に貢献できます。 インデックスクラスター インデックスクラスターは、ポータブルウェブ内のApp Storeのような機能を果たします（誰でも提供可能です）。 クラスターのコンポーネントの提供者は、自分のデータをインデックスクラスターに登録します。インデックスクラスターはこの登録されたデータをホスティングし、ユーザーに情報やソフトウェアを提供します。また、その情報にはバージョンや互換性などの情報も含まれます。 インデックスクラスターは、どのコンポーネントがどのクラスターに属しているかを知っており、サーバーとAPIスキーマ、クライアントとAPIスキーマ、クライアントとマイグレーションスクリプトの関係を理解しています。 クラスターの構成要素 目的ドキュメント 目的ドキュメントは、コミュニティ主導の開発を可能にし、促進するためのものです。これには以下が定義されています： 究極の目標：クラスターが達成しようとする包括的な目標。 使用されるトークン：クラスター内で利用される特定のトークン。 このドキュメントはクラスターの作成時に公開され、その後は不変のままです。目的ドキュメントに記載された究極の目標はシステム的な機能を持ちませんが、コミュニティはこのドキュメントを基に機能の改善や追加を行います。 APIスキーマ APIスキーマは、クライアントとサーバー間の通信方法を定義するプロトコルです。これは開発者が読める形式である必要があります。このスキーマに従うことで、異なる開発者が作成したクライアントとサーバーが相互に通信できます。 APIスキーマ間の互換性がある場合、サーバーとクライアントは複数のWeb APIスキーマをサポートできます。 マイグレーションスクリプト マイグレーションスクリプトは、クライアントが特定のデータモデルを持つことを前提としています。これにより、同じマイグレーションスクリプトを参照するクライアント間でのデータ移行と同期が可能になります。 クライアント クライアントは、HTMLやJavaScriptなどの静的コンテンツで構成されており、特定のインターネット接続や特定のサーバーに依存せずに独立して動作できます。クライアントは、ユーザーが指定した宛先としか通信できません。特定のサーバーに依存するように実装してはいけません。 クライアントは、ユーザーがサーバーに送信またはサーバーから受信するデータをキャッシュできます。特定のマイグレーションスクリプトを指定し、そのスクリプトを実行することでデータ移行が可能なデータ構造でデータをキャッシュしなければなりません。 サーバー サーバーは、APIスキーマに準拠したAPIを提供します。APIスキーマで定義できるあらゆる機能を提供できます。 バージョン管理 ポータブルウェブでは、クラスターは単一のアプリケーション単位ですが、使用するコンポーネントによって異なる動作をします。誰でもマイグレーションスクリプト、APIスキーマ、クライアント、サーバーなどのコンポーネントを作成できるため、クラスター内にさまざまなバージョンが共存します。...