VirMesh Protocol

Appearance

サーバー権限型ワールド ​

本草案では、ワールドの公開鍵ではなく、サーバーのオリジン（配信元）を信頼の基点とする、代替的なワールド権限モデルについて説明します。

バージョン1（v1）で推奨されるパスは「鍵権限型」です。サーバー権限型が草案に留まっているのは、実装は容易であるものの、移行やミラーリング、第三者による検証の面で脆弱であり、鍵権限型に劣るためです。

ステータス ​

このドキュメントは、v1で必須とされるプロトコルの範囲には含まれません。

各実装においてサーバー権限型ワールドを試験的に導入することは可能ですが、クライアントやエクスプローラーは、鍵権限型の検証に失敗した際の代替手段として、署名のないサーバー権限型のレスポンスを暗黙的に受け入れてはなりません。

識別子の形式 ​

サーバー権限型ワールドには、鍵権限型ワールドとは異なる形式の識別子が必要です。

text
medi:world:web:<ホスト名>/<ワールドのスラッグ>

例：

text
medi:world:web:worlds.example.com/example

この識別子は、ワールドを配信するHTTPSオリジンに紐付けられます。将来的に移行メカニズムが定義されない限り、ワールドが別のホストに移動した場合は、別のサーバー権限型ワールドとして扱われます。

最小構成のマニフェスト ​

サーバーは、ワールドキーによる署名を含まないマニフェストを返します。

json
{
  "payload": {
    "worldId": "medi:world:web:worlds.example.com/example",
    "authority": {
      "type": "server",
      "origin": "https://worlds.example.com"
    },
    "schema": "obj+me.virmesh.world.manifest",
    "versionId": "2026-04-26T00:00:00Z",
    "name": "Example World",
    "endpoint": "https://worlds.example.com/",
    "worldProtocols": [
      {
        "name": "me.virmesh.world.websocket",
        "version": "1.0.0"
      }
    ],
    "updated_at": 1770000100
  }
}

クライアントは、レスポンスが宣言されたHTTPSオリジンから取得されたものであることを検証します。ライブセッションの接続先や URI などの information は、鍵権限型 world と同じく instance 解決結果の worldProtocols[].information で扱います。

信頼ルール ​

サーバー権限とは、以下のことを意味します。

  • HTTPSオリジンがそのワールドの権限者である。
  • 別のオリジンにコピーされた場合、そのワールドを検証することはできない。
  • ミラーや第三者のキャッシュは転送を便利にするためのものであり、権限を持つわけではない。
  • エクスプローラーは、そのワールドを「オリジン固定（origin-bound）」としてラベル付けする必要がある。
  • クライアントは、別途署名された移行記録が存在しない限り、そのワールドにポータビリティ（移植性）があるとは見なすべきではない。

これは、マニフェストがワールドキーで検証可能である限り、ホストをまたいでもワールドIDが不変である「鍵権限型」とは意図的に異なる仕様になっています。

ユースケース ​

サーバー権限型は、以下のようなケースで許容される可能性があります。

  • ローカル開発用のワールド
  • 一時的なイベントスペース
  • 非公開、または小規模な個人用ワールド
  • 長期的なアイデンティティの保持や第三者キャッシュを、現時点では必要としないサーバー

長期的なアイデンティティ、移行機能、独立したエクスプローラー、あるいは検証可能なアセットミラーが必要なワールドでは、鍵権限型を使用すべきです。

ダウングレード防止ルール ​

クライアントは、これら2つの権限モデルを厳格に区別しなければなりません。

クライアントが medi:world:ed25519:<公開鍵> 形式を期待しており、署名の検証に失敗した場合は、そのマニフェストを拒絶しなければなりません。同じレスポンスを medi:world:web:<ホスト>/<スラッグ> として再解釈してはなりません。

同様に、サーバー権限型のワールドは、authority.type: "server" を宣言するか、サーバー権限型専用の識別子形式を使用しなければなりません。署名がないという理由だけで、サーバー権限型であると推論してはなりません。

未解決の課題 ​

  • サーバー権限型のワールドIDには、URLパス、正規化されたホスト＋スラッグ、あるいはDIDのようなオリジンレコードのどれを含めるべきか？
  • プロトコルのエンドポイントは同一オリジン上にあることを必須とするべきか、それともオリジンがサブドメインに委任することを許可すべきか？
  • 署名付きの移行記録によって、medi:world:web:<旧> から medi:world:web:<新> への転送を許可すべきか？
  • エクスプローラーによるサーバー権限型マニフェストのキャッシュを許可すべきか。許可する場合、その期間はどの程度か？

次のステップ ​

  • v1の鍵権限型フローについては、ワールドの権限とハンドシェイクを参照してください。
  • この草案は、オリジン固定のアイデンティティで問題ない試験的なケースにのみ使用してください。