排程中
閱讀時間 7 分鐘 作者 NT²
來自一萬筆項目 OPFS 保管箱的基準測試
技術文章
大型本機保管箱不是靠一句口號證明的。它靠的是量測人們實際使用的路徑—— 解鎖後的第一頁、防抖搜尋、FTS 與篩選查詢——並誠實說明這些數字不代表什麼。
標籤: opfs
8 篇文章
排程中
閱讀時間 7 分鐘 作者 NT²
同一套保管箱 UI：瀏覽器、PWA 與桌面／行動殼層
技術文章
解鎖、列表、搜尋與設定不該裂成三個產品。NT² Vault 維持一套保管箱 UI， 讓每個殼層只負責平台必須擁有的事：耐用檔案如何落在該裝置上。
排程中
閱讀時間 7 分鐘 作者 NT²
結構描述 v60 與漸進式遷移
技術文章
本機保管箱是裝置上的真正 SQLite 資料庫。當產品推出結構描述 v60 時，上線時期的保管箱必須就地升級——不能因為原始碼裡的 CREATE 語句變了，就強迫清除重建。
排程中
閱讀時間 7 分鐘 作者 NT²
SQLite 放在 Web Worker 裡，不是選配
技術文章
本機優先保管箱需要裝置上真正的關聯式引擎。若把引擎放在 UI 執行緒， 每一次分頁查詢都會與繪製、輸入搶資源。NT² Vault 在 Web Worker 中執行 SQLite，外層是型別化訊息與單一鎖鏈，讓列表在資料庫保持誠實的同時仍能回應。
排程中
閱讀時間 6 分鐘 作者 NT²
中繼資料在 SQLite，密文在 BlobStore
技術文章
保管箱需要知道哪些檔案屬於哪些項目、它們有多大、以及如何解開金鑰。 它不需要把那些加密位元組塞進負責回答這些問題的關聯式資料庫裡。
排程中
閱讀時間 8 分鐘 作者 NT²
為什麼我們將保管箱的 SQLite 資料庫放在 OPFS，而非 IndexedDB
技術文章
SQLite 需要的是檔案。隱私保管箱需要耐用的關聯式儲存，而且隨著項目、索引與加密附件增加， 效能仍須保持穩定。以 IndexedDB 承載 SQLite 虛擬檔案系統，確實能連接這兩個世界， 但這座橋也會介入每一次資料庫操作。對 NT² Vault 而言，瀏覽器中的保管箱檔案應該放在 Origin Private File System。
閱讀時間 8 分鐘 作者 NT²
每個物件一把金鑰：NT² Vault 內的信封加密
技術文章
保管箱可以用一把金鑰加密所有資料，並且仍然宣稱資料經過加密。但我們希望採用更實用的邊界：每個項目與附件都有自己的內容加密金鑰，再由保管箱金鑰保護這些金鑰。
閱讀時間 5 分鐘 作者 NT²
為什麼選擇 PWA 本地優先、零伺服器的 Vault
技術文章
在雲端優先應用當道的時代，我們往往忽略了一個強大的替代方案：漸進式網頁應用（PWA）。當現代瀏覽器已經能在使用者裝置上完整執行高效、安全、高效能的應用時，為什麼還要維運一套沉重、昂貴且可能成為攻擊面的伺服器基礎設施？