中繼索引密文；收件匣留在本機

主張：傳遞不是收件匣的監管權

共用產品常把三件事壓進同一層雲端表面：傳輸、暫存、儲存。

傳輸把位元組從寄件人送到收件人。暫存承載「有東西到了；決定怎麼辦」。儲存則是接受後的材料成為持久保管箱狀態的地方。

NT² 刻意分開這些工作。

當保管箱對保管箱的共用（Share）用邊緣做傳遞時，中繼可以持有不透明密文區塊、簡短傳遞索引（誰寄給誰、到期、撤銷狀態、不透明識別碼），以及足以證明某個保管箱金鑰 DID 獲准上傳、列出、擷取或確認的驗證。它不持有可讀的保管箱信箱。它不解密欄位。它不會變成收件人在 PWA 裡開啟的收件匣（Inbox）。

保管箱收件匣是已解鎖裝置上的用戶端 SQLite 表。傳輸轉接器拉取候選——來自盲中繼、.nt2share 檔案、QR／帶內貼上，以及相關路徑——正規化後，在本機暫存加密的收件匣信封。列是待處理訊息，不是資產。**接受（Accept）**才是明確行為，把待處理共用變成收件人自己信封下的新項目。在此之前，封包是暫存密文加上非敏感預覽，不是靜默寫入保管箱的資產清單。

主張濃縮成一句：中繼為傳遞索引密文；要求「接受」的收件匣留在本機。

這與盲複本同步套用在交接上的誠實相同——同一套零知識邊界。同步中繼不透明複本框架，卻不變成可搜尋的雲端保管箱。共用中繼不透明封包，卻不變成伺服器端可讀郵件的收件匣。

限制：「待處理共用」API 是一種誘惑

打造多裝置共用的工程師通常想要一張叫 inbox_messages 之類的伺服器表。它很方便。支援可以查詢。每台裝置可以輪詢同一列。分析可以計算待處理共用。網頁主控台可以顯示「Alice 寄了什麼給 Bob」。

那種方便，正是我們拒絕當成必然的限制。

若伺服器擁有收件匣列，提供者就能讀暫存層。 即使酬載已加密，產品壓力仍會膨脹：儲存明文預覽、可搜尋標題、寄件人顯示名稱、類別標籤，以及「好用」的支援傾印。待處理封包往往比成品項目更敏感：那是收件人決定材料是否屬於自己紀錄之前的瞬間。把那個瞬間做成一級雲端文件，等於邀請日誌、索引與內部工具。

若「列出我的待處理共用」回傳欄位形狀的 JSON，中繼就不再盲。 傳遞索引若包含護照號碼、備註本文或憑證使用者名稱，那就不是索引——而是第二套保管箱綱要。HTTPS 與磁碟加密修不好一個會收到明文的應用程式。

若「接受」發生在伺服器上，監管關係就翻轉了。 接受是本機密碼與儲存決策：驗證、在收件人金鑰下解密、重新加密進每物件信封、寫入新資產。那份工作需要已解鎖的保管箱金鑰。已解鎖的保管箱金鑰不得住在邊緣。因此「接受」不能是雲端幫你「匯入」的程序。

若每種傳輸都倒進同一個伺服器信箱，離線與檔案路徑就變成二等公民。 共用也會以檔案、QR 酬載與帶內貼上到來。只懂「輪詢雲端收件匣」的產品，會為了正規化傳遞而發明彆扭上傳——或讓檔案收件人失去同樣的接受體驗。傳輸必須可插拔；本機收件匣才是正規化層。

命名碰撞是真實風險。 為收件人保管箱金鑰 DID 列出待處理中繼區塊的 API，在工程俚語裡誠實地可叫「inbox」。產品收件匣不同：那是人類審視暫存訊息的 UI 與本機儲存。把兩個詞搞混，會在熟悉標籤下重建錯誤架構。在 NT²，邊緣可以暴露中繼待處理索引。應用程式的收件匣是本機的。

因此限制是雙重的。傳遞可以用邊緣。暫存決策不得要求提供者可讀的信箱。

設計：兩套綱要、多種傳輸、一扇接受之門

NT² 在邊緣刻意維持兩套無趣綱要，在裝置上維持一套較豐富的綱要。

flowchart LR
  subgraph edge [邊緣中繼]
    Idx[傳遞索引]
    Blob[密文區塊]
    Idx --- Blob
  end
  subgraph device [已解鎖裝置]
    Adapters[傳輸轉接器]
    Inbox[保管箱收件匣 SQLite]
    Assets[接受後的資產]
    Adapters --> Inbox
    Inbox -->|接受| Assets
  end
  Blob -->|擷取不透明位元組| Adapters
  Idx -->|列出待處理參照| Adapters

中繼路徑（保管箱對保管箱）。 寄件人把共用封包加密到收件人的對等關係，以寄件人的保管箱金鑰 DID 簽署，並上傳密文。驗證是保管箱金鑰 DID 上的挑戰－回應——與可選雲端同步同一套身分模型，不是電子郵件持有者工作階段。邊緣儲存區塊，以及足以傳遞與到期的中繼資料列。收件人用戶端在解鎖期間輪詢待處理索引、擷取尚未攝入的區塊，並寫入本機收件匣列。確認與拒絕是對中繼談傳遞處置，不是改寫可讀訊息的伺服器信箱。

本機靜態信封。 一旦暫存，收件匣以收件人保管箱 AES 金鑰加密信封。鎖定裝置不會把待處理共用明文留在隨意表裡。預覽欄位依設計非敏感：足以辨識到了什麼，不足以重建封包。

其他傳輸填入同一收件匣。 .nt2share 檔案、QR／深層連結酬載，或帶內貼上，可經不同轉接器產生同一類待處理列。UI 不在乎哪條管道送來位元組。它在乎有東西待處理、聲稱來自誰，以及使用者要接受、拒絕，或讓它到期。

動態形狀的中繼遵循同一套盲性。 凡 NT² 以動態式拉取做保管箱對保管箱風格更新，邊緣仍索引不透明物件與傳遞中繼資料。用戶端仍決定什麼成為收件匣狀態、什麼成為持久保管箱狀態。盲傳遞是一族設計，不是單一端點。

NT² Premium 同步把收件匣列當複本資料複製。 待處理訊息的跨裝置連續性不需要伺服器收件匣表。裝置同步密文信封與非敏感中繼資料，方式與其他本機保管箱事實相同。中繼仍是 Mode A 的傳遞輔助（以及連結共用的託管密文）；它不是「我的收件匣裡有什麼」的真實來源。

這套設計對上已對收件人說過的產品故事：有東西到了、停一下、再決定——見有東西進了我的收件匣與接收中心不是下載資料夾。架構文是那套 UX 底下的邊界。

取捨：工程師腦中有兩個收件匣

把中繼索引與保管箱收件匣分開，短期要付清晰度成本。

實作者必須記得：成功上傳 ≠ 成功接收。寄件人寄件匣可以顯示「已交給中繼」，而收件人收件匣在某台裝置輪詢並攝入之前仍是空的。那種延遲是誠實的。假裝雲端已「投遞進 Bob 的收件匣」，就等於要求 Bob 的收件匣是雲端物件。

用戶端必須去重。兩次輪詢待處理索引不得產生兩列待處理。傳輸參照與本機唯一鍵存在，是為了讓重新整理安全。那比「SELECT * FROM server_inbox」更多狀態。

支援無法開主控台讀待處理共用。那是產品成本，也正是重點。說明文字與自助撤銷／TTL 工具必須靠密文與中繼資料運作，不是明文封包傾印。

多裝置使用者要學會解鎖並重新整理很重要。等在中繼上的密封封包，在未解鎖複本拉取之前，還不是本機收件匣列。NT² Premium 同步接著幫其他已解鎖裝置得知暫存列——仍是複本密文，仍不發明提供者信箱。

我們接受雙模型，因為爆炸半徑保持窄。中繼外洩暴露不透明區塊、保管箱金鑰 DID 識別碼與傳遞中繼資料——不是一疊可讀的待處理機密。遺失已鎖定保管箱的筆電，不會暴露只有解鎖後才解密的收件匣信封。誤接受是裝置上的使用者行為，不是靜默伺服器匯入。而且共用密碼學留在共用形狀的邊界——不是主密碼——如共用密碼 ≠ 主密碼所述。

我們拒絕什麼

我們拒絕伺服器擁有的、可讀待處理郵件式保管箱收件匣。 允許傳遞索引與密文區塊。不允許暫存機密的提供者信箱。

我們拒絕中繼上的明文字段酬載。 標題、備註本文、憑證欄位與附件位元組離開寄件人時已加密。邊緣儲存不透明物件。

我們拒絕把「接受」做成雲端 API。 接受需要已解鎖保管箱。匯入在使用者選擇後於裝置上發生。

我們拒絕從輪詢靜默匯入。 擷取待處理區塊會建立或更新收件匣列。它不建立資產。

我們拒絕把「inbox」API 俚語當成產品收件匣。 針對保管箱金鑰 DID 的待處理區塊清單是中繼索引。收件匣 UI 讀本機 SQLite。

我們拒絕把電子郵件或簡訊當共用傳輸。 那些管道把身分、預覽與轉寄壓成提供者可讀表面。保管箱對保管箱傳遞留在保管箱金鑰 DID 驗證、盲區塊與本機暫存——或不需要邊緣時，走使用者攜帶的檔案與 QR。

我們拒絕上傳主密碼或共用密碼，好讓伺服器「幫忙開啟」封包。 解密留在用戶端。邊緣搬運盲位元組。

這些拒絕讓某些傳遞路徑比 Gmail 形狀的共用收件匣更慢或更明確。那份摩擦，是不把待處理交接變成另一座雲端保管箱的代價。

結語：傳遞輔助，本機之門

盲共用中繼與本機收件匣，是邊緣上的盲複本同步在交接上的雙生：網路可以搬運密封物件；詮釋留給持有金鑰的裝置。那些請求的身分是保管箱金鑰 DID 上的挑戰－回應，不是可重設的電子郵件登入。收件人面向的主張——「寄給我」對你來說是密文——是同一邊界的白話。

中繼索引密文。收件匣留在本機。接受仍是裝置上的一扇門。

若你要從不變成提供者信箱的共用傳遞，探索 NT² Vault。