SDK とアプリの役割分担

wired が実装するのはプロトコルです。 TLS 1.3、QUIC、HTTP/3、WebTransport、MoQT を正しく話し、プロトコルのレベルでの悪用から自分を守ります。 一方で、誰に何を許すかを決めること、再起動をまたいで何かを残すこと、負荷を複数のマシンに分散することはしません。 これらはアプリケーションが決めることです。

wired が担うこと

• ワイヤープロトコル：ハンドシェイク、損失からの回復、フロー制御、HTTP/3 のフレーミング、WebTransport のセッションとストリーム、そして wired_moqt_hub による MoQT の制御メッセージと Object の中継です。
• プロトコルのレベルでの上限：内部の表はすべて大きさが固定です（現在の上限 を参照）。 上限を超えた相手は、メモリーを増やして受け入れるのではなく、ワイヤー上で拒否されます。 1 秒間に 100 回を超えてストリームをリセットしたコネクション（SRVRUN_MAX_RESETS_PER_WINDOW）は H3_EXCESSIVE_LOAD で閉じられ、1 つのコネクションが開ける WebTransport セッションは 1 秒あたり 10 個まで（SRVRUN_MAX_WT_SESSIONS_PER_WINDOW）です。
• 自己署名証明書：アプリが渡す識別情報から組み立てます（ブラウザーの要件 を参照）。
• ポリシーを差し込む場所：ハブは何かを許可する前に authorize_subscribe と authorize_namespace を呼び、サーバーは wt_resource_check と wt_origin_check を呼びます。

アプリケーションが担うこと

• 認証と認可：ハブは AUTHORIZATION TOKEN のバイト列をフックに渡し、その答えに従って許可または拒否します。 トークン（CAT、Privacy Pass のトークン、セッション Cookie など）の検証はアプリの仕事です。 フックの使い方は 購読者の認可 で示しています。
• Origin のポリシー：どのサイトにセッションを開かせるかを決めます（Origin ヘッダーの検査）。
• ユーザー単位のレート制限：SDK が制限するのはコネクションごとのプロトコルイベントで、ユーザーごとのメッセージ数やバイト数ではありません。 「参加者 1 人あたり毎秒 5 件までのチャット」のような制限は、アプリに置きます。
• 永続化：ハブは状態をメモリーにしか持ちません。 FETCH 用のキャッシュは、アプリが wired_moqt_cache_attach で渡すアリーナ（アプリ側でまとめて確保したメモリー領域）に置かれ、プロセスが終わると消えます。 再起動後も残す必要があるチャット履歴、録画、ルームのメンバー構成には、アプリ自身の保存先が必要です。
• スケール：1 つの wired_moqt_hub は 1 つのプロセスの中にあり、そのプロセスのセッション同士しか中継しません。 --workers を使うと、各ワーカープロセスが互いに見えない別々のハブを動かすことになるので、moqt_chat デモは単一プロセスで動いています。 1 つのルームを複数のプロセスやマシンに分けるにはハブ同士の中継が必要ですが、wired はそれを提供しません。 wired_moqt_goaway を使えば、クライアントを別のサーバーの URI に移せます。
• 本番での証明書：CA が発行した証明書チェーンを入手するか（アプリが id.chain として渡すとサーバーが送ります）、自己署名証明書をその有効期限である 14 日が切れる前に入れ替えます（証明書のホットリロード）。