可能な限りシンプルなお願い

App Store のバイナリは FairPlay で暗号化されており、復号には適切な iOS バージョンの脱獄済み端末が必要です。クリーンな IPA がなければ、AltStore や Sideloadly のようなサイドロードツールも役に立ちません。コミュニティだけでは、クリーンな iOS バイナリを手に入れる方法がありません。

FairPlay を外してエクスポートした最後のビルドを、長く残る場所（Bethesda の保存ページ、コミュニティのパートナー、アーカイブのリンク1つなど）に置いてもらえれば、App Store から消えた後も iOS 版を生かし続けられます。

名前付きのエンドポイント（auth、game、matchmaking など）の短い一覧を用意し、それぞれをホスト名または IP に対応させます。初期値は Bethesda の現在の本番ホストとして出荷し、コミュニティの再署名者が再署名時に差し替えます。

副作用:複数の独立したコミュニティが互いに調整することなく自分たちのサーバーを運用でき、1つのクライアントを入れたまま、時期に応じて別のサーバーに向けることもできます。

Android では:コミュニティはすでに、これを実現する改造 APK を作っています。この機能を備えた公式の Android ビルドは、法的なグレーさを減らしユーザーの信頼を高めるための好意的な対応であって、必須ではありません。Android の保存はそれなしでも成り立ちます。このお願いが最も重要なのは iOS です。

iOS:保存用ビルドから NSPinnedDomains（または独自の証明書ピンニング）を取り除きます。ピンニングがなければアプリは標準のシステムの信頼ストアを使い、iOS ではそこにユーザーがインストールした構成プロファイルも含まれます。

Android:本番のマニフェストに、ユーザー CA を信頼する network_security_config を含めます。これがないと、Android 7 以降はユーザーがインストールした CA を標準で拒否します。

このお願いが満たされないと、お願い2の設定可能なエンドポイントは役に立ちません。通信が始まる前に、クライアントがコミュニティサーバーの TLS 証明書を拒否してしまうためです。

• 認証とセッショントークン。形式、有効期間、クライアント側のものが不透明なセッション ID 以上の意味を持つかどうか、サーバーが前提としているクライアント組み込みのシークレットの有無。
• セーブ状態の権威。どのサブシステムがサーバー側を正とし（町、インベントリ、キャラクターのステータス）、どれがクライアント側を正とするか。整合ルールと競合の解決方法。
• アリーナ UDP 暗号化。鍵の導出、libsodium AEAD のパラメータの選択、シーケンス番号、パケットのフレーミング。コミュニティは現在、実行時に Frida のフックで鍵を抜き出しています。文書があれば、それをクリーンな再実装に置き換えられます。
• 改ざん防止署名。リクエスト本文に対する HMAC やリクエスト署名の方式と、そこで使われるシークレット。
• IAP レシート検証。Bethesda のサーバーが Apple/Google のレシートを検証する流れと、購入の復元に対してコミュニティサーバーがどう対応すべきか。
• その他、サーバー側を再実装する人が見落としそうだと Bethesda のエンジニアが考える点。