就近控制平面，WebRTC 大量平面

主張：一個工作階段，兩個平面

就近會面在不上網的引導之後，給你就緒的加密工作階段。下一個工程問題既無聊又決定性：什麼放得進那個工作階段的應用層 frame？

聯絡人邀請很小。Mode A 共用清單——欄位、簽章、中繼資料——可以很小。附件快照不然。帶掃描與檔案的保管箱項目，若把每個位元組都嵌進控制路徑，經常超過緊的每方向工作階段預算。

主張是：把工作切開。 把近距離工作階段當控制平面，承載邀請、收件匣清單、WebRTC 信令與就緒訊號。偏好以 WebRTC data channel 作為附件密文區塊的大量平面。維持單一 Mode A 共用封包故事，以及單一收件匣「接受」路徑。

限制：把附件塞進去會弄破模型

面對就近共用的團隊，常挑三種壞捷徑之一。

把一切塞進工作階段 frame。 你會撞上大小上限、笨拙分片，或在錯誤層面拉長工作階段壽命，讓手機面對面傳百萬位元組。

發明第二套「就近封包」格式。 Mode A 密碼學、收件匣暫存與寄件匣處置就此分叉。審查者分不清哪條路徑是權威。中繼與檔案交接不再像兄弟。

略過收件匣，區塊一到就寫入資產。 部分傳輸變成半匯入的機密。竄改或掉線讓保管箱不一致。「接受」不再是同意邊界。

限制是預算加上產品誠實：工作階段 frame 負責協調；大量位元組需要大量平面；匯入保持明確。

設計：控制訊息，再分塊大量傳輸

flowchart TB
  subgraph control [控制平面 — 近距離工作階段]
    Invite[聯絡人邀請]
    Manifest[收件匣清單 stub]
    SDP[WebRTC SDP 交換]
    Ready[大量就緒訊號]
  end
  subgraph bulk [大量平面 — WebRTC data channel]
    Chunks[加密附件區塊]
  end
  Invite --> Manifest
  Manifest --> SDP
  SDP --> Ready
  Ready --> Chunks
  Manifest --> Inbox[收件匣待處理列]
  Chunks --> Gate[完成後才啟用接受]
  Inbox --> Gate
  Gate --> Accept[接受至保管箱]

控制平面（工作階段 DATA）。 連線之後（需要時含信任），加密的應用層承載可以包含：

• 聯絡人邀請／互惠邀請物件——與深層連結邀請相同的驗證。
• Mode A 收件匣候選／清單 stub：足夠讓收件人暫存待處理共用並顯示檢視介面。
• 附件需要大量平面時的 WebRTC SDP offer/answer（以及相關信令）。
• 大量就緒訊號：區塊傳輸可開始，或接收端組裝完成時。

大量平面（偏好：WebRTC data channel）。 附件密文以帶完整性檢查的區塊移動。區塊密碼學仍是 Mode A 設計下的內容層保護——不是「工作階段金鑰已經做過的事」。工作階段包裝保護信令；大量區塊仍為這次共用封裝。

收件匣暫存，接受受閘門控制。 清單驗證通過後，待處理收件匣列可以先出現，而接受至保管箱在必要區塊到達並驗證前保持停用。收件人絕不能把部分或截斷的附件集合當成完整來接受。與中繼或 .nt2share 攝入相同的接受／拒絕／稍後處理用語適用——見中繼索引密文；收件匣留在本機。

後備保持可插拔。 若 WebRTC 無法完成，產品可以升級到家族裡既有的其他 Mode A 載體（中繼、檔案匯出）——不必重寫共用語意。就近是加速器，不是監獄。

近距離工作階段本身的 BLE 與雲端中繼轉接器，在目前切片仍是未來傳輸。本文不依賴它們。大量平面故事是：已建立的就近控制工作階段之後，走 WebRTC。

取捨：編排複雜度，換單一密碼學故事

兩個平面意味著更多狀態：SDP 失敗、區塊重試、接受仍停用、「換一種方式」。UX 必須敘述進度，而不能把協定列舉堆給使用者。工程師必須對齊控制與大量時鐘，讓收件匣從不提早宣稱完成。

我們接受複雜度，因為替代方案更糟：要嘛第二套共用格式，要嘛控制平面假裝自己是檔案管線。單一 Mode A 封包、單一收件匣、單一接受——由這次會面組得起來的平面傳遞——讓威脅審查可處理。

它也保持接近離線的誠實。就近會面本身不要求 Premium。經 WebRTC 的大量傳輸，在本機信令之後仍是裝置對裝置。雲端中繼仍是就近大量無法完成時的可選兄弟路徑——不是「我們連上了」的靜默依賴。

我們拒絕什麼

我們拒絕把完整附件快照嵌進每個就近控制 frame 當主設計。 預算存在是有原因的。

我們拒絕只為就近發明平行的 SharePackage。 Mode A 仍是 Mode A。

我們拒絕在部分大量傳輸上啟用接受。 經驗證的完整性才閘住匯入同意。

我們拒絕把大量完成當成保管箱匯入。 傳遞 ≠ 接受。

我們拒絕把工作階段流量金鑰與 Mode A 內容金鑰混為一談。 層級保持分層。

收束：加速 Mode A，而不重寫它

本系列從一道邊界開始：近距離工作階段 ≠ 對等連線。接著是載體規則：引導不上網。最後一塊是機械的：控制平面上的小真相、WebRTC 大量平面上的重密文、中間是收件匣、結尾是接受。

編目裡其他跨保管箱共用文章涵蓋對等 OOB、寄件匣撤銷、遺產釋放與密碼交接。就近會面不取代那些文章——它是兩座已解鎖保管箱在同一房間裡重用它們、而不靠 email 的方式。

Parent-frame 數據機長文刻意不進本系列。架構主張關乎工作階段身份、引導持有，以及平面分離——不是位元組如何越過最後一公尺空氣。

若你希望當面的保管箱對保管箱傳遞從頭到尾保持 Mode A，歡迎探索 NT² Vault。