ローカルのプロファイル所有者をまたぐホスト型ルーム

ホスト型ルームの実行には、正規のセッション権限（session authority）を使います。各プロファイルはそれぞれ通常の gateway プロセスを動かし、自分の状態データベースだけを所有します。送り元のルームドライバーは、宛先の所有者に、OS で認証された非公開のコントロールソケットを通じて連絡します。旧来のセッションワーカーを起動したり、宛先のデータベースを開いたりすることはありません。

ルームには、その gateway が受け持つプロファイルを着席させられます。gateway 自身のプロファイルと、 gateway.multiplex_profiles のもとでマルチプレクサーがいま受け持っているすべてのプロファイルです（マルチプレクサーでは、受け持つプロファイルごとに専用の権限とデータベースを持ちます）。ホスト単位の接続（Desktop の共有ソケットやダッシュボード）では、これらに設定は要りません。Desktop の「New Group Chat」はこの経路を通ります。1つのプロファイルに紐付いた接続では、従来どおり、そのプロファイルと hosted_rooms.profiles の項目に書いたプロファイルが着席します。受け持ち中のプロファイルを書いた項目は、受け持ち側のホーム（home）を指していなければなりません。別のローカル gateway が所有するプロファイルは、送り元プロファイルの設定に明示した宛先としてだけ参加できます。

hosted_rooms:
  profiles:
    helper: /absolute/path/to/profiles/helper

名前は宛先プロファイルの名前と一致させる必要があり、宛先には稼働中の所有者が必要です。宛先専用の gateway（gateway.standalone のプロファイル）か、そのプロファイルを受け持つ別のローカルのマルチプレクサーです。1つのホームが応じる名前は1つだけです。ホスト単位の接続では、受け持ち中のプロファイルは、項目に何と書いてあっても受け持ち側のホームのままです。すでに別の名前で着席しているホームを指す項目や、形式が壊れた項目は、ログに1行残して無視されます。拒否されるのは、その項目を指名する新しいメンバーだけです。そうした別名をすでに着席させているルームは、ほかのメンバーで動き続けます。ディレクトリが存在するだけでは実行は認められないので、インストール済みでもここで受け持っていないプロファイル（待機中のものや、この gateway が項目を持たない gateway が所有するもの）は、ルーム作成時に拒否され、拒否の理由にそのメンバー名が示されます。profiles/<name> ディレクトリがリンクになっている受け持ち中のプロファイルも拒否されます。メンバー間の通信が、まだその名前でたどり着けないためです。設定の各項目は、宛先の設定やセッションを読まずに、名簿（roster）のメタデータとして公開されます。

同じマルチプレクサーが受け持つ2つのプロファイル間の実行は、実際の非公開コントロールソケットを動かすプロセス内テストで確かめています。複数プロファイルを入れた実環境での動作確認はまだ終えておらず、プロファイルのディレクトリがリンクになっているメンバーはターンを実行できません。

宛先は、投入時と、キューから取り出す前の2回、現在のルームの所有関係、メンバー構成、永続化されたタスクの正確な識別、ホスト世代（hosted generation）、凍結済みのプロンプトを、送り元に問い合わせて照合します。宛先は、送り元の名前空間で区切った紐付けを自分のデータベースに保持します。送り元か宛先が使えないときは、安全側に倒して失敗します。保持した作業を、黙って別経路へ回すことはありません。この非公開の producer インターフェースは、公開 WebSocket クライアントからは使えません。コントロールソケットには、同じ OS ユーザーであれば信頼するというローカルの信頼関係が適用されます。

起動時には、ホスト型の復旧より先にアダプターを公開します。正規の監督処理が旧来のルームドライバーに置き換わるので、リースの奪い合いは起きません。完了済みの再試行は、新たな推論をせずに同じ受領記録を復元します。所有者のクラッシュ後に残った開始済みの作業は「不明（unknown）」となり、後続を一時停止させます。再試行で不明な作業を再実行することはできません。所有ユーザーが、ルーム・メンバー・タスク・ホスト世代を正確に指定して破棄（Discard）を行う必要があります。正規の不明状態の解決は、送り元ドライバーのキャンセル受領記録より先に確定します。同じ破棄をそのまま繰り返せば、失われた確認応答を取り戻せます。

Desktop は正規のグループを見つけ、操作を記録済みの接続・プロファイル・ルームへ送ります。不明な作業には、確認付きの破棄（Discard）だけを示し、再試行（Retry）は示しません。レンダラー側にしかない既存のグループは、正規のルームを明示的に新しく作る必要があります。履歴が新しい作業として自動で再実行されることはありません。正規のワークスペースが現在扱うのはテキストと実行の操作です。添付ファイルの公開は、ルームの別の機能として残っています。