Replica 批次內部——封包形狀

先前的文章用白話畫過界線：Premium 同步是盲目中繼，每個保管箱身份各自有一個專屬邊緣樞紐，協調 replica 卻打不開它們。這篇再往下一層——replica 批次在線路上長什麼樣——但不會把部落格寫成內部模組導覽。

主張可以收成一句話：

對邊緣而言，replica 批次是一包不透明 frame，外加足以儲存、排序與傳遞的外層事實。項目欄位、搜尋索引與解密金鑰，留在授權裝置上。

只要心裡有這張圖，多數「伺服器看不看得見 X？」的問題會自己有答案。

限制：可讀的同步 JSON 是錯誤的封包

誘人的同步封包長得像應用程式 JSON。

客戶端送出一串物件，裡面有標題、類別、使用者名稱、筆記本文與附件檔名。伺服器驗證欄位、寫入資料欄、建立索引，再把同一形狀回傳給其他裝置。衝突處理變成伺服器端合併可讀紀錄。客服可以打開一列。產品可以搜尋整個語料。分析可以統計有多少護照形狀的項目。

對雲端擁有的資料庫來說，這種封包很有效率。對盲目保管箱中繼來說，它是致命的。

一旦線上格式變成「服務看得懂的項目欄位」，服務就已經變成第二個保管箱——不論行銷頁是否寫著零知識。傳輸加密幫不上忙：TLS 保護路徑，不保護終止連線的應用。提供者磁碟加密也幫不上忙：應用解析本文時仍看見明文。「我們用自己的金鑰做靜態加密」同樣不夠：金鑰與資料並存，並不是你與營運者之間的界線。

客戶端加密只有在封包本身不再夾帶可讀機密時，才修得了模型。若加密 blob 旁邊還放著明文標題、預覽、決定性搜尋 token，或營運者可過濾的類別標籤，中繼就只是半盲目。真正敏感的欄位，早已洩漏進邊緣被允許理解的 schema。

因此設計問題不是「在傳統同步 API 上加一個加密函式庫」，而是拒絕傳統封包。同步單位必須是邊緣能路由、卻不必解讀保管箱意義的東西。

設計：外層信封對內層閣樓

NT² 把跨裝置變更封裝成 replica 批次。把它想成密封的快遞袋，而不是資產試算表。

在已解鎖保管箱的裝置上：

1. 本機變更寫入一般保管箱資料庫——結構化列、本機索引、附件密文與中繼資料並存。
2. 任何內容要進入 Premium 同步之前，敏感資料先在該裝置上加密。
3. 客戶端組出一批有意義 payload 為不透明 frame 的資料：邊緣能儲存並回傳的位元組序列，卻無法當成項目欄位來解析。
4. 批次也帶外層協調事實——足夠的排序與進度中繼資料，讓另一份 replica 能問「我還缺什麼？」，而不必問「英文裡改了什麼？」。

在邊緣：

• 以保管箱公開密碼學身份（保管箱金鑰 DID）為名的 Durable Object，擔任每保管箱同步樞紐：授權工作階段、接受或回傳批次、推進協調狀態，並通知已連線的 replica 有更新進度。
• Cloudflare R2 物件儲存保存較大的密文 blob——不透明 frame 與附件位元組——識別碼不從可讀標題衍生。
• 帳號資料庫保存計費與權益事實、公開驗證材料與服務旗標。它不保存筆記本文的第二份副本。

在接收裝置上：

1. 以同一身份驗證。
2. 從上次已知進度點之後拉取批次。
3. 在本機驗證並解密。
4. 用每台授權客戶端共用的規則合併進本機 replica。
5. 從已解密資料重建或更新本機搜尋索引——絕不上傳提供者可讀的搜尋語料。

一張表就夠把層次分清楚：

flowchart LR
  A[裝置 A<br/>本機加密] -->|推送不透明批次| H[邊緣樞紐]
  H --> R[(物件儲存<br/>密文 blob)]
  H -->|進度通知| B[裝置 B]
  B -->|拉取不透明批次| H
  B --> B2[本機解密與合併]

圖刻意很無聊。無聊才是重點。沒有一步是樞紐「打開項目」、「索引標題」或「為客服渲染預覽」。

完整與增量，但不把邊緣變成編輯器

首次啟用往往推送完整批次，讓雲端樞紐成為其他裝置的完整加密會合點。日常工作偏好增量批次：只送出自上次確認進度以來的變更。無論哪一種，邊緣看見的仍是封包與進度——不是可變的機密試算表。

即時通知刻意保持精簡。已連線的 replica 可能得知進度已超過某個水位。通知不包含機密。裝置再經授權同步路徑去取不透明批次。漏掉一次 ping 只是不便；下一次拉取仍可從持久進度狀態追上。離線仍然有效：睡過所有通知的裝置，下次驗證並同步時仍會收斂。

附件位元組遵循同一誠實原則。大段密文不必塞進每個批次本文。命名不透明 blob 的中繼資料可以隨 replica 走；blob 本身住在物件儲存。儲存對授權請求回傳位元組。它不需要一個意思是「護照掃描，第 2 頁」的內容類型。

取捨：邊緣不能當你的第二大腦

選擇不透明封包，等於放棄雲端優先產品常當成基本配備的便利。

提供者無法在你的筆電闔上時搜尋你的機密。沒有誠實的伺服器端全文索引能涵蓋標題與筆記，因為要建那種索引，就得上傳可讀文字或提供者可讀的 token 流。衝突意義與 schema 演進必須是授權客戶端能套用的事。客服不能打開一筆紀錄告訴你為什麼筆記「看起來不對」。產品分析無法從同步平面回答「平均保管箱有多少銀行項目？」。

中繼資料仍然存在。邊緣可以觀察某個身份在某時刻同步、傳輸了多少位元組，或有多份作用中的 replica。流量分析與端點淪陷，仍是與「營運者能不能讀筆記」不同的問題。零知識縮小的是同步服務用途；它並不取消系統安全或網路物理。

使用者直接感受到的產品取捨是：同步是選用的 Premium，不是擁有保管箱的定義。離線建立／讀取／更新／刪除仍是快樂路徑。同一套密封批次想法也出現在可攜備份：你可以在裝置之間搬運加密 replica，卻從未啟用雲端樞紐。線路形狀是傳輸問題；雲端是一個會合點，不是真相的主人。

我們拒絕什麼

架構在拒絕說清楚時最清晰。

沒有伺服器端明文搜尋。 搜尋屬於已解鎖、已擁有閣樓的裝置。上傳標題、筆記摘錄或提供者可讀的搜尋索引，會讓雲端搜尋框更好做——也正好造出盲目中繼該避開的語料。

沒有營運者「檢視保管箱」主控台。 營運需要健康訊號：權益失敗、傳輸錯誤、物件數量、傳遞延遲。他們不需要能解密客戶 frame 的按鈕。若那種按鈕能存在，提供者就握有金鑰或通往金鑰的路徑，「不透明封包」就只是表演。

不把同步 frame 當成可讀的 JSON 項目欄位。 批次不是本文為 { title, username, password, notes } 的 REST 資源。邊緣上的解析器驗證外層信封與授權。它們不會長出「只放類別」或「只放列表預覽」的資料欄。每一個這類欄位，都是服務被允許知道之事的永久擴張。

這些拒絕不是待辦清單。它們就是封包契約。

讓封包保持無聊

當你能在不提到機密的情況下描述封包，盲目同步就不再只是口號。

裝置先加密。批次攜帶不透明 frame 與進度。邊緣樞紐——每個保管箱金鑰 DID 一個 Durable Object——協調傳遞。物件儲存保存密文 blob。帳號表保存身份與計費事實。解密、合併與搜尋，只在已取得金鑰的裝置上再次發生。

若要回看這篇加深的第一輪界線文章，從在邊緣進行盲目 replica 同步與一個保管箱身份，一個同步中樞開始。解鎖與雲端登入的分界見解鎖本機保管箱，不等於登入雲端。帳號表為何沒有值得偷來做離線解鎖的東西，見帳號資料庫不能成為密碼神諭。更廣的 Workers 表面見Workers 被允許看見什麼。離線作為預設路徑仍是離線可用不是「有網路再碰運氣同步」。

若這種封包形狀符合你希望敏感紀錄旅行的方式——若它們真的要旅行——請開啟 NT² Vault。