@orbinum/sdk 2.1.0 → 3.0.0

package/README.md

@@ -259,30 +259,27 @@ same `selfEphCounter` derive the same ephemeral index and publish the same
 ephemeral point, which publicly links the two notes. That is a privacy leak, not
 a lost update.
 
-### Moving notes between clients
+### Backing notes up
 
-`orbinum://notes/v1/` is the format for handing notes from one Orbinum client to
-another — desktop to mobile, as scannable pages. Both halves ship here so the
-encoder and decoder cannot drift apart:
+A backup is **JSON**, and it is closed: each entry carries the note's
+commitment and its encrypted memo, never a spending key. Ownership is proved on
+import by decrypting the memo, so a backup file that leaks reveals nothing an
+observer could not already read off the chain.
 
 ```ts
-import {
-    encodeNoteTransferPages,
-    decodeNoteTransferPage,
-    assembleNoteTransfer,
-} from '@orbinum/sdk';
+import { encodeNoteBackup, decodeNoteBackup, importNotesFromBackup } from '@orbinum/sdk';
 
-const pages = encodeNoteTransferPages(notes); // render each as a QR
-const entries = assembleNoteTransfer(scanned.map(decodeNoteTransferPage));
+const file = JSON.stringify(encodeNoteBackup(notes));
+const mine = importNotesFromBackup(decodeNoteBackup(file), {
+    viewingSecretKey,
+    spendingKey,
+    ownerPk,
+});
 ```
 
-`assembleNoteTransfer` refuses an incomplete or mixed batch rather than importing
-what it has — a partial import looks like a successful one, and the user would
-never learn which notes never arrived.
-
-The payload carries **spending keys**: anyone who scans these codes can spend the
-notes. It is for an in-person transfer between two devices the same person owns,
-and a host must say so before showing one.
+`importNotesFromBackup` silently skips entries that do not decrypt — they belong
+to someone else. A malformed entry is rejected by `decodeNoteBackup` before that,
+so a hand-edited file cannot plant a note with a broken commitment.
 
 ### Porting to another platform
 

package/dist/adapters/indexeddb/index.d.mts

@@ -1,4 +1,4 @@
-import { V as VaultStorage, a as VaultConfigRecord, E as EncryptedNoteRecord, b as EncryptedTxRecord, C as CachedNullifier, N as NullifierSyncMeta, S as SpendDetails, D as DeviceKeyStore, c as SecretStore } from '../../secretStore-CF6Nse__.mjs';
+import { V as VaultStorage, a as VaultConfigRecord, E as EncryptedNoteRecord, b as EncryptedTxRecord, C as CachedNullifier, N as NullifierSyncMeta, S as SpendDetails, D as DeviceKeyStore, c as SecretStore } from '../../secretStore-CCYo4hna.mjs';
 
 /**
  * `VaultStorage` over IndexedDB — the browser's copy of a wallet's notes.
@@ -112,9 +112,9 @@ declare class IndexedDbVaultStorage implements VaultStorage {
  * A `DeviceKeyStore` backed by a tiny dedicated IndexedDB.
  *
  * IndexedDB rather than localStorage because it stores a `CryptoKey` HANDLE via
- * structured clone. The key is generated non-extractable, so its material never
- * becomes visible to JavaScript — a storage dump yields an opaque handle, not
- * bytes. localStorage can only hold strings, which would mean exporting the key.
+ * structured clone, so the material never becomes visible to JavaScript and a
+ * storage dump yields an opaque handle. localStorage holds only strings, which
+ * would mean exporting the key to store it at all.
  *
  * Its own database, separate from the vault: the device key outlives any single
  * vault and must survive one being dropped.
@@ -136,16 +136,16 @@ declare const getOrCreateIndexedDbDeviceKey: () => Promise<CryptoKey>;
  * No IndexedDB involved — it ships from this entry point because a consumer
  * reaching for browser persistence wants both adapters together, and splitting
  * them across two subpaths would buy nothing.
+ *
+ * Values arrive already encrypted; see `sessionCache`.
  */
 
 /**
- * A `SecretStore` over Web Storage.
- *
- * Reads fall back to `sessionStorage` so a value written by an older build, or
- * by a deliberately session-scoped flow, is still found. Writes always go to the
- * durable store and clear the session copy, so one key never lives in both.
+ * Durable by default, with `sessionStorage` as a READ fallback so a value left
+ * by an older build or a session-scoped flow is still found.
  *
- * Values are encrypted before they arrive here — see `sessionCache`.
+ * Every write goes to the durable area and drops the session copy, so one key
+ * never lives in both and a stale session value cannot shadow a fresh one.
  */
 declare function createWebStorageSecretStore(storage?: Storage, sessionStorageArea?: Storage | null): SecretStore;
 

package/dist/adapters/indexeddb/index.d.ts

@@ -1,4 +1,4 @@
-import { V as VaultStorage, a as VaultConfigRecord, E as EncryptedNoteRecord, b as EncryptedTxRecord, C as CachedNullifier, N as NullifierSyncMeta, S as SpendDetails, D as DeviceKeyStore, c as SecretStore } from '../../secretStore-CF6Nse__.js';
+import { V as VaultStorage, a as VaultConfigRecord, E as EncryptedNoteRecord, b as EncryptedTxRecord, C as CachedNullifier, N as NullifierSyncMeta, S as SpendDetails, D as DeviceKeyStore, c as SecretStore } from '../../secretStore-CCYo4hna.js';
 
 /**
  * `VaultStorage` over IndexedDB — the browser's copy of a wallet's notes.
@@ -112,9 +112,9 @@ declare class IndexedDbVaultStorage implements VaultStorage {
  * A `DeviceKeyStore` backed by a tiny dedicated IndexedDB.
  *
  * IndexedDB rather than localStorage because it stores a `CryptoKey` HANDLE via
- * structured clone. The key is generated non-extractable, so its material never
- * becomes visible to JavaScript — a storage dump yields an opaque handle, not
- * bytes. localStorage can only hold strings, which would mean exporting the key.
+ * structured clone, so the material never becomes visible to JavaScript and a
+ * storage dump yields an opaque handle. localStorage holds only strings, which
+ * would mean exporting the key to store it at all.
  *
  * Its own database, separate from the vault: the device key outlives any single
  * vault and must survive one being dropped.
@@ -136,16 +136,16 @@ declare const getOrCreateIndexedDbDeviceKey: () => Promise<CryptoKey>;
  * No IndexedDB involved — it ships from this entry point because a consumer
  * reaching for browser persistence wants both adapters together, and splitting
  * them across two subpaths would buy nothing.
+ *
+ * Values arrive already encrypted; see `sessionCache`.
  */
 
 /**
- * A `SecretStore` over Web Storage.
- *
- * Reads fall back to `sessionStorage` so a value written by an older build, or
- * by a deliberately session-scoped flow, is still found. Writes always go to the
- * durable store and clear the session copy, so one key never lives in both.
+ * Durable by default, with `sessionStorage` as a READ fallback so a value left
+ * by an older build or a session-scoped flow is still found.
  *
- * Values are encrypted before they arrive here — see `sessionCache`.
+ * Every write goes to the durable area and drops the session copy, so one key
+ * never lives in both and a stale session value cannot shadow a fresh one.
  */
 declare function createWebStorageSecretStore(storage?: Storage, sessionStorageArea?: Storage | null): SecretStore;