對等連線不是手機通訊錄聯絡人

主張：身份與加密是不同的工作

手機通訊錄回答的是「我怎麼聯絡這個人？」NT² 的聯絡人回答更難的一對問題：我在認可哪一座保管箱，以及用什麼金鑰把封包封給對方？

那不是同一件事。

保管箱金鑰 DID 是對方保管箱的公開身份。指紋、簽章與雲端證明都掛在它上面。它告訴你，在邀請、共用封包與可選的邊緣驗證裡，這座保管箱自稱是誰。

對等連線（peer connection） 是你的保管箱與對方保管箱之間的持久關係。在那段關係裡，Peer DID 材料才是保管箱對保管箱（Mode A）封包的加密端點。Mode A 的加密與解密使用 Peer 文件——而不是把保管箱金鑰 DID 當成萬能的 keyAgreement 表面。

主張只有一句：聯絡人列是對等連線——金鑰 DID 管「是誰」，Peer DID 管「怎麼加密」——不是你貼上就希望無誤的電話簿項目。

這道切分，是已用白話說過的故事的密碼學半邊：安全聯絡人是信任關係、單向邀請與雙向信任，以及可驗證信任是密碼學的。選擇性 SSI 拒絕把保管箱變成泛用 DIDComm 錢包——見選擇性 SSI，不是 DID 錢包——同時仍需要具體的對等交接才能做 Mode A。

限制：貼上識別碼會邀來錯誤收件人

工程師與產品常想要捷徑：輸入一個 DID、按儲存、開始共用。感覺像在郵件客戶端新增 email。

對保管箱對保管箱加密來說，捷徑會失敗。

若你加密到自己腦中發明的金鑰 DID 協定金鑰，你可能根本沒加密到產品之後會用的 peer。 身份與「每一段關係的加密」必須可分開。把它們混在一起，會誘出「好心」路徑：把封包封到錯誤文件，或把簽章身份當成加密端點。

若聯絡人能靠貼上識別碼、不經邀請就建立，錯送風險上升。 打錯的 DID、掃到錯誤畫面的 QR、被轉寄的字串，都會變成持久通訊錄列。Mode A 接著開心加密給那個字串指名的任何人。邀請優先的 OOB 讓對方以簽章交接出示保管箱金鑰 DID 與 Peer DID 材料，而不是讓你獨自發明自由文字欄位。

若單向接受就默默開啟出站 Mode A，你是在對半知半解的 peer 加密。 接受對方邀請，讓你能驗證對方送來的東西，並在收件匣暫存封包。要把加密的 Mode A 送回去，你這邊需要對方的 peer 加密材料——那要在互惠邀請閉合時才到齊。在對等連線完成前擋下傳送，UX 比「直接送」醜；但比封給不完整材料安全。

若「已驗證」是一顆按鈕，密碼學就變成扮家家酒。 信任狀態應隨證明事件移動——邀請完成、指紋確認、成功接受封包——而不是使用者因為顯示名稱看起來眼熟就手動升級一列。

因此限制同時是社交與密碼學的：不要發明收件人；完成對等連線。

設計：邀請優先的 OOB，再 Mode A 打到 peer

NT² 的聯絡人路徑是邀請形狀。

1. A 方分享邀請（QR、深層連結或其他 OOB 載體），帶上其保管箱金鑰 DID 與這段關係的 Peer DID 材料。
2. B 方接受。B 把 A 存成聯絡人，並持有 A 的 peer 加密端點，以便入站驗證，以及在互惠完成後加密給 A。
3. 若要雙向傳送，B 回傳含 B 的保管箱金鑰 DID 與 Peer DID 的互惠邀請。
4. A 在待處理聯絡人列上完成互惠掃描。雙方保管箱此時都持有彼此的身份與 peer 加密材料。

flowchart LR
  subgraph identity [身份]
    KD[保管箱金鑰 DID]
  end
  subgraph relationship [對等連線]
    PD[Peer DID 材料]
    Wrap[以保管箱金鑰包裝靜置]
    PD --> Wrap
  end
  KD -->|為對方命名| Contact[聯絡人列]
  Wrap --> Contact
  Contact -->|Mode A 加密| Pkg[保管箱對保管箱封包]

邀請優先。 通訊錄列來自邀請，而不是以貼上保管箱金鑰 DID 為主路徑的「新增聯絡人」表單。邀請者證明持有；受邀者選擇認可。

每個連線一組隨機 Peer DID。 每一段對等連線為該對方關係取得自己的 Peer DID 金鑰材料。私密 peer 金鑰以本機保管箱金鑰包裝靜置，只在保管箱解鎖時解開——與其他保管箱機密同一套工作階段誠實。

Mode A 對準對等連線。 保管箱對保管箱封包使用 ECDH → HKDF → AES-GCM，並帶保管箱對保管箱網域標籤，由寄件者的保管箱金鑰 DID 簽章。加密端點是連線列上的 Peer DID 文件。開啟封包需要收件人已解鎖的保管箱——不是可拋棄的共用密碼。這道邊界與共用密碼 ≠ 主密碼並列：Mode A 拒絕密碼模型，因為信任形狀是已知的保管箱關係。

單向與雙向。 接受邀請是對入站的真實信任。雙向 Mode A 傳送要等互惠 peer 材料。產品寧願有清楚的「關係未完成」狀態，也不要靜默錯送加密。

聯絡人留在本機。 你連線的對象是隱私敏感資料。聯絡人與 peer 列活在保管箱的本機儲存。Premium 同步可以把加密的聯絡人狀態複製到你的其他裝置；那仍不是邊緣上的公開社交圖譜。

取捨：關係摩擦，而不是錯送便利

邀請優先的對等連線要付出步驟。

兩人必須完成 OOB 交換，Mode A 才會像聊天一樣順。單向接受不是「我們都能送」。高風險關係仍需要指紋確認。工程師不能為了「簡化 schema」把保管箱金鑰 DID 與 Peer DID 塌成一份文件。

支援用語必須精確。聯絡人不是手機通訊錄。對等連線不是短暫的近距離工作階段。從不學習保管箱金鑰 DID 的臨時近距離傳輸是另一層；本文談的是 Mode A 所需、綁定身份的持久關係。

我們接受摩擦，因為爆炸半徑保持誠實。加密到已完成的對等連線，把能開啟封包的人限縮在持有對應 peer 材料的保管箱。用貼上字串發明收件人，優化的是速度，失敗形態卻是看起來成功的錯人密文。

當對方永遠不會安裝 NT²，Mode A 是錯工具。加密連結與 .nt2share 檔案改用共用密碼——見本系列稍後的 Mode B/C 加深，以及入門文共用密碼 ≠ 主密碼。

我們拒絕什麼

我們拒絕在沒有 peer 加密材料時對聯絡人做 Mode A 加密。 未完成的關係沒有「還是送出去」去封給猜測。

我們拒絕把保管箱金鑰 DID 身份與 Peer DID 加密端點混為一談。 簽章「他們是誰」不等於把封包封給他們。

我們拒絕以「貼上 DID 並儲存」作為主要產品建檔路徑。 邀請優先的 OOB 才是 peer 材料進來的方式。

我們拒絕跳過密碼學證明事件的手動「標記已驗證」。 已驗證狀態跟隨證明，不跟隨樂觀。

我們拒絕把手機通訊錄當成保管箱交接的信任清單。 電話與 email 無法加密 Mode A 封包。

結語：聯絡人就是對等連線

跨保管箱共用從你願意認可誰為保管箱開始。那種認可是對等連線：保管箱金鑰 DID 管身份，Peer DID 材料管加密，邀請優先的 OOB 綁定兩者，雙方都要傳送時再完成互惠。

收件匣仍會對入站封包要求接受——見中繼索引密文；收件匣留在本機。寄件匣追蹤你已送出的東西——本系列下一篇。解鎖絕不變成共用機密；peer 金鑰也絕不成你打錯的手機聯絡人。

若你要的是等真實 peer 材料到齊才做的保管箱對保管箱交接，探索 NT² Vault。