D-20260710-05｜入房密碼挑戰-應答與成員端 match-start 校驗

背景與驅動力

star 拓撲等待房（D-20260710-04）落地後的首測前碼複審，共識安全路撈出兩個信任面問題：其一、入房密碼若隨 join-request 明文上行，中繼節點即可截取；繼任房主重掛時若要求成員重送密碼，假繼任者更可藉此騙取。其二、成員端對 host 廣播的 match-start 全信——host 偷改 roster 即可把成員拖進造假名單的比賽。

考慮過的選項

• 密碼明文隨 join-request 上行：中繼可截、繼任情境可騙；否。
• 挑戰-應答（採納）：密碼明文永不離開本機。
• host 廣播全信：host 不可信是既定威脅模型；否，成員端自行校驗（採納）。

決定

• 入房驗證改挑戰-應答：join-request 不帶密碼 → host 回 join-challenge{nonce} → joiner 回 join-auth{proof = sha256(nonce ‖ password ‖ joinerPeerId)}；proof 綁 joiner 身分、擋中繼重用，明文永不上行。
• 繼任房主免密：繼任者以 seededMembers 直接補收既有成員、不重問密碼——假繼任者因此無從擷取任何密碼材料。
• 成員端 match-start 校驗：matchId 必須與 match-start 所附名單自洽、且名單須等於成員先前觀察值；host 偷改 roster＝ 忽略該廣播、不進 preloading。

後果與影響

房主保住入房裁決權，但拿不到密碼明文、也失去單方面改名單的空間；matchId 綁 roster 的自洽檢查與 deriveMatchId 定式（D-20260710-02）同構，成員端成為獨立於 host 的第二道驗證線。現況權威：room-runtime.md、matchmaking.md。