撤銷你已經送出的共用

主張：寄件者需要本機寄件匣

中繼索引密文；收件匣留在本機 畫出收件邊界：傳遞不是待處理「接受」決策的監管。

寄件者有對稱的問題。

在你把銀行項目共用給會計師、或把憑證共用給共同創辦人之後，兩個問題會回來：那個封包是否仍可觸達，以及後來發生了什麼？已檢視？已接受？已拒絕？已過期？已撤銷？

那些答案屬於寄件匣（outbox）——你建立過的共用之本機讀模型——而不是塞滿欄位形狀 JSON 的伺服器端「寄件備份」。

主張是：寄件匣追蹤離開保管箱的東西；在傳輸允許時，撤銷打在託管密文上；邊緣絕不變成可讀的寄件封存。

限制：送完就忘，是共用糾纏你的方式

加密交接常停在「傳送成功」。產品跳出 toast。位元組離開。擁有者只剩記憶與希望。

那道缺口會製造壞壓力。

若只有收件人的收件匣存在，寄件者無法閉環。 支援工單變成「對方收到了嗎？」工程發明依 email 列出待處理共用的雲端查詢。於是提供者能讀到很像郵件標頭的暫存中繼資料——產品壓力接著要求存標題、預覽與「好用」的傾印。

若每種傳輸的撤銷都是假的，使用者會學到錯誤一課。 已複製到 USB 的 .nt2share 不能靠對 API 許願就遠端抹除。誠實的產品會說哪些共用仍殺得掉（託管連結密文、政策內仍未送達或仍可控的 Mode A 中繼 blob），哪些殺不掉。假裝每次傳送都能遠端抹除，比清楚說「檔案已離開你的監管」更糟。

若處置狀態只活在伺服器，離線與多裝置同步會打架。 建立共用的保管箱可能離線。同一擁有者的另一份副本也需要同一組寄件匣列。權威的寄件儀表板應是 Premium 同步可複製的本機 SQLite 保管箱狀態——不是變成「我送了什麼」真相來源的提供者信箱。

若寄件匣為了「提醒收件人」而存放共用密碼，監管關係就翻轉了。 寄件匣是狀態表面，不是可拋棄交接機密的密碼管理器。提醒某人共用密碼是人類的 OOB 行為；不是從伺服器重建封包金鑰的功能。

限制是：要閉環，不要監管。 寄件者值得有狀態。提供者不該因此賺到人人揭露內容的可讀封存。

設計：本機列、不透明的中繼處置

NT² 的共用寄件匣坐在寄件裝置上。

當你建立 Mode A、B 或 C 共用時，保管箱寫入本機寄件匣列：共用種類、建立時間、過期時間、與中繼對帳所需的不透明識別碼，以及會隨時間演化的處置欄位——待處理、已檢視、已接受、已拒絕、已撤銷、已過期，以及產品會呈現的相關狀態。

flowchart LR
  Create[建立共用] --> Outbox[本機共用寄件匣]
  Create --> Cipher[密文封包]
  Cipher -->|Mode B 託管 / Mode A 中繼| Edge[盲目中繼索引]
  Edge -->|不透明處置| Sync[狀態同步]
  Sync --> Outbox
  Outbox -->|可撤銷時撤銷| Edge
  Outbox -->|UI 儀表板| Owner[寄件者保管箱]

本機讀模型。 你在已解鎖保管箱開啟的儀表板讀的是 SQLite，不是長得像 email 的提供者收件 API。Mode A 收件人的顯示名稱來自本機聯絡人——不是雲端社交圖譜。

中繼同步處置，不是明文。 對雲端託管連結與中繼傳遞的 Mode A 封包，邊緣可能知道足以回答：仍在清單？已撤銷？已過期？已確認？它不需要項目欄位、共用密碼或主密碼才能做到。狀態同步用不透明中繼資料更新本機寄件匣列。

撤銷對傳輸誠實。 對託管密文的一鍵撤銷，在仍有意義時於中繼移除或標記 blob 不可達。已離開裝置的檔案共用會標給擁有者理解；產品不宣稱能魔法遠端抹除每一份 USB 複本。

收件匣與寄件匣保持不同工作。 收件匣是收件人的待處理接受表面（中繼／收件匣）。寄件匣是寄件者的閉環表面。混淆這兩個詞，會在共用品牌下重建郵件伺服器。

安全紀錄不是寄件匣。 只追加的安全活動可記錄共用已建立或已撤銷以供稽核。寄件匣是人類儀表板——「會計師開了嗎？」——並帶撤銷控制。兩者可以並存；不該塌成一張可讀事件的雲端表。

取捨：誠實面對撤銷做不到的事

本機寄件匣要付出 UI 與同步成本。處置狀態變多。檔案與 QR 路徑不總是提供送達後的殺開關。行銷不能承諾「隨時取消任何傳送」。

我們接受那份誠實，因為替代方案是假的雲端寄件備份夾。可讀寄件郵件，是零知識共用變成揭露封存、只是換了加密詞彙的方式。

當信任該結束——封鎖聯絡人、停止 Mode A、讓連結過期——寄件匣是你看到什麼仍活著的地方。故事半邊在何時該結束信任；本文是那一刻背後的寄件機械。

我們拒絕什麼

我們拒絕伺服器端可讀的共用寄件備份夾。 處置中繼資料可以不透明；欄位明文不得變成邊緣郵件。

我們拒絕透過寄件匣做「忘記共用密碼」復原。 弄丟共用密碼就結束那次 Mode B/C 交接——與共用密碼 ≠ 主密碼同一套失敗即關閉誠實。

我們拒絕假裝每種傳輸都支援送達後抹除。 在密文仍受中繼政策約束處撤銷；當檔案已離開監管時說真話。

我們拒絕在邊緣存放共用密碼「好讓寄件者提醒收件人」。 OOB 提醒是人類的事；封包金鑰留在客戶端。

我們拒絕讓「接受」變成改寫伺服器信箱的雲端程序。 接受留在收件人本機；寄件匣只學習傳輸能回報的不透明結果。

結語：送出，然後擁有後續

跨保管箱共用不在位元組離開時結束。寄件者需要能回答狀態、又不鑄造提供者封存的寄件匣。收件者需要要求接受的本機收件匣。邊緣索引密文與處置——僅此而已。

對等連線決定 Mode A 能對準誰——見對等連線不是手機通訊錄聯絡人。寄件匣決定你按共用之後還存在什麼。本系列下一篇的延遲遺產釋放，把這個想法拉長到時間軸：一個在不活躍之前不得開啟的封包。

若你要的是對撤銷保持誠實的寄件儀表板共用，探索 NT² Vault。