本記事について

以下はEthResearchに投稿したものの日本語訳です（機械翻訳を使ったため、誤訳が含まれる可能性があります）。

Comparison of Web Paradigms: Privacy, User Rights, and Monopoly|690x353, 100%

既存のウェブでは、ユーザは自分のデータを管理することが難しく、サービスにロックインされています。「ポータブルウェブ」は既存のウェブと並行して存在し、ユーザーにデータに対するより大きなコントロールを提供し選択の幅を広げることを目指しています。ポータブルウェブ上のアプリケーションは、主に公共インフラとしての役割を果たすものを想定しています。

本記事では、ポータブルウェブの核心的なアイデアを紹介します。その実現可能性に直接関係のない詳細な仕様は含まれていません。

要約

Cluster Architecture Overview|690x389

An Example of Incentive Mechanisms in the Portable Web|690x359

  • ハッカブル：ユーザーがウェブアプリケーションをカスタマイズできる
    • クラスターは単一のアプリケーション単位を表します。
    • 誰でもクラスターを作成でき、クラスター内では、クラスター作成者以外の主体が自分のクライアントを作成したり、サーバーを提供したり、APIスキーマを定義したり、マイグレーションスクリプトを書けます。
    • クライアントとサーバーは疎結合で、APIスキーマを通じて接続され、異なる開発者が独立して作成できます。
    • 例えば、ユーザーは自分のニーズに合わせたカスタムUIを作成し、アプリケーションを使いやすくすることができます。また、自分でAPIスキーマを開発し、特定の機能を拡張するためのサーバーをホスティングすることも可能です。このように、ポータブルウェブでは、開発者だけでなく一般ユーザーもアプリケーションの進化に積極的に貢献できます。
  • データロックインなし：ユーザーが自分のデータをコントロールできる
    • クライアントはユーザーのデータをキャッシュします。
    • APIスキーマに準拠したサーバーを使用することで、クライアントは異なるサーバー間でキャッシュされたデータを共有できます。
    • クライアント上のキャッシュデータは、マイグレーションスクリプトを使用して移行することも可能です。
    • クライアントはユーザーが送受信するデータをキャッシュしますが、このデータをユーザーが選択したサーバーに送信することで、分散的に管理されます。必要に応じて、ユーザーは自分のデータを他のサーバーに移行でき、特定の組織にデータがロックインされることを防ぎます。
  • クリプトネイティブ：インセンティブメカニズムとしてのクリプトエコノミクス
    • ポータブルウェブでは、クラスター提供者がトークンを発行し、そのトークンへの実需を生むクラスターを提供することでインセンティブを得ます。
    • クラスター内のすべての支払いは、発行されたトークンで行われます。
    • 新しい参加者の存在はクラスターの成長に貢献するため、元のクラスター提供者は彼らを排除しません。
    • Web2が独占や勝者総取りのゲームとして機能する一方で、ポータブルウェブは協調的で包摂的なアプローチを促進します。

背景

Web2

Web3コミュニティでは、Web2の問題点について広く議論されていますので、ここでは深く掘り下げません。しかし、強調しておきたいのは、Web2の問題の根本はそのアーキテクチャにあるということです。具体的には、ブラウザがターゲットのURLに直接アクセスする方式です。

Web2のアーキテクチャでは、ユーザーは自分が生成したコンテンツを所有権やローカルコピーを保持せずにサービスに直接投稿します。ユーザーのアカウントやコンテンツはサービス内に存在し、そのサービスがデータを蓄積します。この蓄積は新しいデータの生成を加速させます。ユーザーが別のサービスに移行して同じレベルの利便性を得ることは非常に困難です。そのためには、ユーザー自身がコンテンツを移行する必要があり、他のユーザーも大規模に移行する必要があります。

既存のウェブアーキテクチャは、コンテンツのロックインやアカウントのロックインを引き起こし、それが権力の集中や勝者総取りのダイナミクスを助長します。

Web3

Web3 as a marketing word|690x322

Web3は既存の権力構造に挑戦し、ユーザーの権利を最大化するとしばしば主張されますが、実際には現在のところ、Web2の上にブロックチェーン層を追加しているに過ぎません。

ブロックチェーンは分散型ですが、既存のWeb3アプリケーションが現在のウェブアーキテクチャの上に構築されているという事実は、そのポテンシャルを損なっています。

ポータブルウェブのアーキテクチャ

Portable Web Architecture|690x443

上記の問題を解決し、ユーザーの権利を最大化しながら分散型のウェブを実現するためには、新しいアーキテクチャを構築する必要があります。その提案された解決策がポータブルウェブです。この新しいウェブアーキテクチャは、ユーザーが自分のデータとアイデンティティを完全にコントロールでき、開発者やサービス提供者が協力して単一のアプリケーションを進化させることを可能にします。

ポータブルウェブの構成要素

ポータブルウェブブラウザ

ブラウザは、ポータブルウェブを実現するためにいくつかの重要な役割を果たします。

  1. 制御されたサーバー通信：クライアントが通信できるサーバーを制限します。ユーザーが明示的に意図しない限り、クライアントはサーバーとやり取りできません。
  2. 通貨の制限：アプリケーション内での支払いに使用される通貨を制限します。ブラウザにはウォレットが含まれており、支払いはクラスターで最初に設定された通貨でのみ行われます。デフォルトでは、ブラウザは内部の取引所（DEXまたはCEX）と連携しているため、ユーザーは使用されている通貨を意識しません。
  3. アイデンティティ管理：ユーザーのアイデンティティを自己主権型アイデンティティ（SSI）として管理し、サーバーやクライアントがユーザーのアイデンティティをロックインすることを防ぎます。
  4. ブートストラップのためのビルトインサポート：インデックスクラスター用のクライアントとサーバーの情報が内蔵されており、ブートストラップをサポートします。ユーザーは後で他のクライアントやサーバーに接続できます。
  5. データ移行と更新：クライアントで指定されたマイグレーションスクリプトを実行してデータを転送し、クライアントの更新を管理します。

クラスター

クラスターは、その目的ドキュメントによって識別される単一のアプリケーションを表します。

クラスターを構成する要素は次のとおりです：

  • 目的ドキュメント
  • APIスキーマ
  • マイグレーションスクリプト
  • クライアント
  • サーバー

誰でも目的ドキュメント以外のコンポーネントを提供して、クラスターの開発と進化に貢献できます。

インデックスクラスター

インデックスクラスターは、ポータブルウェブ内のApp Storeのような機能を果たします（誰でも提供可能です）。

クラスターのコンポーネントの提供者は、自分のデータをインデックスクラスターに登録します。インデックスクラスターはこの登録されたデータをホスティングし、ユーザーに情報やソフトウェアを提供します。また、その情報にはバージョンや互換性などの情報も含まれます。

インデックスクラスターは、どのコンポーネントがどのクラスターに属しているかを知っており、サーバーとAPIスキーマ、クライアントとAPIスキーマ、クライアントとマイグレーションスクリプトの関係を理解しています。

クラスターの構成要素

The relationships between components|690x378

目的ドキュメント

目的ドキュメントは、コミュニティ主導の開発を可能にし、促進するためのものです。これには以下が定義されています：

  1. 究極の目標：クラスターが達成しようとする包括的な目標。
  2. 使用されるトークン：クラスター内で利用される特定のトークン。

このドキュメントはクラスターの作成時に公開され、その後は不変のままです。目的ドキュメントに記載された究極の目標はシステム的な機能を持ちませんが、コミュニティはこのドキュメントを基に機能の改善や追加を行います。

APIスキーマ

APIスキーマは、クライアントとサーバー間の通信方法を定義するプロトコルです。これは開発者が読める形式である必要があります。このスキーマに従うことで、異なる開発者が作成したクライアントとサーバーが相互に通信できます。

APIスキーマ間の互換性がある場合、サーバーとクライアントは複数のWeb APIスキーマをサポートできます。

マイグレーションスクリプト

マイグレーションスクリプトは、クライアントが特定のデータモデルを持つことを前提としています。これにより、同じマイグレーションスクリプトを参照するクライアント間でのデータ移行と同期が可能になります。

クライアント

クライアントは、HTMLやJavaScriptなどの静的コンテンツで構成されており、特定のインターネット接続や特定のサーバーに依存せずに独立して動作できます。クライアントは、ユーザーが指定した宛先としか通信できません。特定のサーバーに依存するように実装してはいけません。

クライアントは、ユーザーがサーバーに送信またはサーバーから受信するデータをキャッシュできます。特定のマイグレーションスクリプトを指定し、そのスクリプトを実行することでデータ移行が可能なデータ構造でデータをキャッシュしなければなりません。

サーバー

サーバーは、APIスキーマに準拠したAPIを提供します。APIスキーマで定義できるあらゆる機能を提供できます。

バージョン管理

ポータブルウェブでは、クラスターは単一のアプリケーション単位ですが、使用するコンポーネントによって異なる動作をします。誰でもマイグレーションスクリプト、APIスキーマ、クライアント、サーバーなどのコンポーネントを作成できるため、クラスター内にさまざまなバージョンが共存します。

マイグレーションスクリプト

Version control of Migration Script|690x251

マイグレーションスクリプトのバージョン管理は、有向非巡回グラフ（DAG）を使用して表され、誰でも更新できます。新しいマイグレーションスクリプトを作成する際には、後方互換性のあるマイグレーションスクリプトを指定しなければなりません。新しいマイグレーションスクリプトは、指定された後方互換性のあるマイグレーションスクリプトをサポートするクライアントから実行されても、データ構造を変換してデータを移行できなければなりません。誰でもマイグレーションスクリプトを作成できるため、ブランチすることもあれば、マージすることもあります。

適切な数のマイグレーションスクリプトを実行することで、古いクライアントから最新のマイグレーションスクリプトをサポートするクライアントにデータを移行できます。例えば、マイグレーションスクリプト「a」をサポートするクライアントは、3回のマイグレーションスクリプトを実行する（b→c→eまたはb→d→e）ことで、マイグレーションスクリプト「e」をサポートするクライアントにデータを移行できます。

APIスキーマ

新しいAPIスキーマは、後方互換性など、他のAPIスキーマとの関係に関する情報を持ちません。クライアントとサーバーは複数のAPIスキーマをサポートできるため、互換性の管理はクライアントとサーバーが個別に行います。互換性が損なわれない限り、追加のAPIスキーマをサポートできます。

クライアント

クライアントの更新は主に3つのタイプに分けられます。すべてのタイプの更新で、ユーザーは更新を受け入れるかどうかを選択できます。

  1. タイプ1：マイグレーションスクリプトやAPIスキーマを変更しない更新。
  2. タイプ2：APIスキーマを変更する更新。
  3. タイプ3：マイグレーションスクリプトを変更する更新。

タイプ1は他のコンポーネントに影響を与えません。

タイプ2の場合、サーバーが対応するAPIスキーマを更新しない限り、ユーザーが通常使用しているサーバーとの互換性が失われる可能性があります。

タイプ3の場合、クライアントは現在のマイグレーションスクリプトを後方互換性として指定した新しいマイグレーションスクリプトに更新できます。更新前のマイグレーションスクリプトをサポートするクライアントからデータを移行することができます。

しかし、あくまで後方互換性であって完全なる互換性ではないため、マイグレーションスクリプトを更新したクライアントにキャッシュされたデータは、以前のマイグレーションスクリプトをサポートする他のクライアントに移行できません。その場合、以下図のように他のクライアントがそのマイグレーションスクリプトに対応するか新しいマイグレーションスクリプトを作成することで対応できます。 Resolve Migration Script Compatibility

サーバー

サーバーの更新は、対応するAPIスキーマを変更または追加することを意味します。更新されたAPIスキーマ情報をインデックスクラスターに登録することで更新できます。

ポータブルウェブの経済

ポータブルウェブが持続的に機能し、開発者やサービス提供者が積極的に参加するためには、経済的なインセンティブが不可欠です。このセクションでは、このアーキテクチャを支える経済システムについて説明します。

参加者へのインセンティブ

クラスター作成者

クラスタークリエイターは、ポータブルウェブのエコシステム内で新しいアプリケーションを立ち上げます。彼らはクラスター固有のトークンを発行することができ、そのトークンはクラスター経済の基盤となります。アプリケーションが広く普及するようなトークンを設計することで、クラスタークリエイターはシニョリッジ（トークン発行による利益）を通じて収益を得ることができます。

クラスターが人気を集め、より多くのユーザーが参加するにつれて、これらのトークンの需要が増加します。この需要の高まりによりトークンの価値が上昇し、クラスタークリエイターがアプリケーションを継続的に開発し改善するための経済的インセンティブが提供されます。クラスターの成功はトークンの価値と直接的に関連しており、クラスタークリエイターの利益はユーザーや他の参加者の利益と一致します。

サーバープロバイダ

ポータブルウェブ内のサーバーは、データをホスティングし、クラスターのAPIスキーマに準拠したAPIを提供します。サーバープロバイダーは、サブスクリプション料金、従量課金制、またはプレミアム機能の提供など、さまざまな課金モデルを通じてサービスを収益化できます。ユーザーは自分のデータを管理し、どのサーバーとやり取りするかを選択できるため、サービスプロバイダーはユーザーを惹きつけ、保持するために高品質で信頼性のあるサービスを提供するよう促されます。

サービスプロバイダーがクラスターのトークンで支払いを受け入れることで、彼らもクラスターの経済に参加することになります。トークンの価値が上昇すれば、サービスプロバイダーの潜在的な収益も増加します。このように、サービスプロバイダーはクラスターの成長に貢献しながら、その成功から利益を得るという共生関係が形成されます。

クライアント開発者

クライアント開発者は、クラスターのUIを提供し、サーバーとデータを送受信するキャッシュするためのソフトウェアを開発します。彼らは、プレミアムなクライアントを有料で販売したり、追加機能を提供して収益化できます。これらはすべてクラスターのトークンで行われます。

クライアントは誰でも提供可能であり、クラスターのエコシステム内で相互運用性があるため、開発者は革新を奨励され、より価値のあるユーザー体験を提供します。開発者は提供する製品を継続的に改善するモチベーションを持ちます。

ユーザー

ユーザーはポータブルウェブを利用することで、自分のデータをより自由に管理でき、アプリケーションの利用体験をカスタマイズする能力を享受します。彼らは、トークンを使ってプレミアム機能を利用するなどしてクラスターの経済に参加します。さらに、トークンを保持しているユーザーは、クラスターが成長するにつれてトークンの価値が上昇する可能性があり、その結果、クラスターを支援・推進するインセンティブを得ることができます。

クラスターの経済に関与することで、ユーザーはより積極的に参加し、フィードバックを提供し、コミュニティに貢献する機会が多くなり、その参加によってエコシステムの発展に寄与することが期待されます。

議論

ここでは、懸念点と今後の課題を簡単にまとめます。

バージョニング

現在のバージョン管理方法では、マイグレーションスクリプトやAPIスキーマが制御不能に増殖し、ユーザーエクスペリエンスやデータポータビリティに悪影響を及ぼすリスクがあります。

現時点では、誰でもカスタマイズできる一方で、初期のクラスター作成者が仕様に関する主導権を持つことが望ましいかもしれません。

データロックインへのインセンティブ

初期のクラスター作成者は、データロックインを実装することに対して抑制的なインセンティブがあります。これは、彼らの目的がデータロックインから利益を得ることではなく、トークンのシニョリッジから利益を得ることだからです（もしデータロックインから利益を得ることを目指すなら、ポータブルウェブのアーキテクチャを選ばないでしょう）。トークンのシニョリッジから利益を得るためには、トークンの実需を増やし、その価格を上昇させる必要があります。この需要を増やすために、クラスター作成者はユーザーにとってより魅力的なアプリケーションを提供しなければなりません。ユーザーにとって魅力的なアプリケーションは、

  • データロックインがない
  • 誰でもカスタマイズでき、多様かつスピードのある発展

を備えます。クラスター作成者はデータロックインを実装するよりもオープンであることが得だと考えるでしょう。

つまり、クラスター内では、少なくとも1つのコンポーネントセット（サーバー、APIスキーマ、クライアント、マイグレーションスクリプト）がデータポータビリティをサポートしているはずです。

後から参加し、トークンの利害関係者でないサービス提供者は、従来のウェブ環境と同様に、データロックインに対して正のインセンティブを持っています。しかし、ユーザーはクラスターからコンポーネントを選択できるため、最もユーザーに好まれるコンポーネントが利用されます。データロックインのない環境で、ユーザーがロックインされたコンポーネントを選ぶのであれば、それはユーザー自身の選択の結果です。これはポータブルウェブが提供する価値の一部でもあり、この選択を否定することはできません。

経済

支払いがブラウザの標準で提供される方法以外で行われる場合、システムの経済が崩壊し、このアーキテクチャが成り立たなくなる可能性があります。

クラスターの目的が変わる場合

クラスターのコンポーネントは、クラスタの目的と一致していなければなりません。クラスターの目的に沿わない機能が実装されると、クラスターは他のクラスターと区別する独自のアイデンティティ—シンボル—を失います。これは、異なる目的を持つFacebookとLinkedInが境界を失い、不便なアプリケーションになるようなものです。さらに、ユーザーの目的に合わない機能は、ユーザーの支持を得られないでしょう。

Q&A

ポータブルウェブは実現可能ですか？

私はプロトタイプを作成し、ある程度実現可能であることを確認しました。

クリプトエコノミクスモデルの機能、大規模なユーザーテスト、APIスキーマとマイグレーションスクリプトの複雑なバージョン管理など、課題は残っていますが、これらは今後対処していく必要があります。

Fediverseとの違いは何ですか？

一見すると、クラスターはFediverse形式（例：Mastodon）で提供されるウェブアプリケーションのように見えるかもしれませんが、いくつか重要な違いがあります：

  1. 経済的インセンティブ：Fediverseでは、インスタンス提供者に組み込みの経済的インセンティブがありませんが、ポータブルウェブではそのようなインセンティブが設計されています。これにより、より大きな持続可能性と成長の可能性が生まれます。
  2. データポータビリティの範囲：Fediverseでは、データポータビリティの範囲は事前に（W3Cによって）決められており、ActivityPubで概説されているように限定されています。これに対して、ポータブルウェブでは、クラスター提供者がデータマイグレーションスクリプトを修正することで、データポータビリティの範囲を柔軟に拡大できます。
  3. ユーザーデータの主権：Fediverseでは、ユーザーの意図に関係なく、データがサーバー間で共有される場合があります。ポータブルウェブでは、ユーザーが自分のサーバーを選択できるため、データに対するより大きな主権が与えられます。

この投稿は最終版ですか？

この投稿は始まりであり、コミュニティからのフィードバックと関心に基づいて洗練していく予定です。

ポータブルウェブのコンセプトをさらに発展・洗練させるために、皆様のフィードバックとご協力をお待ちしております。