Interface: IdbEngineOptions
Interface: IdbEngineOptions
Section titled “Interface: IdbEngineOptions”Defined in: client/src/engine.ts:27
Properties
Section titled “Properties”schema
Section titled “schema”
readonlyschema:Schema<Record<string,AnyTable>>
Defined in: client/src/engine.ts:28
dbName
Section titled “dbName”
readonlydbName:string
Defined in: client/src/engine.ts:29
version?
Section titled “version?”
readonlyoptionalversion?:number
Defined in: client/src/engine.ts:30
readonlyoptionaldb?:Promise<IDBPDatabase<unknown>>
Defined in: client/src/engine.ts:36
Reuse a previously opened IDB handle. createPlasmaClient uses this
so its sync-side meta / outbox writes happen against the same physical
database as the engine’s user-table writes.
encryption?
Section titled “encryption?”
readonlyoptionalencryption?: {dek:Uint8Array;keyId:string; }
Defined in: client/src/engine.ts:64
Data-encryption key material for .encrypted() columns. Phase 4
automates the at-rest side of encryption on the client:
runInsert / runUpdate transparently wrap each .encrypted()
cell in an Envelope via encryptField before it hits IDB, so a
device stolen mid-flight (SQLite scrape of Chrome’s IDB dir)
never reveals plaintext values on-disk. Pull-side auto-decrypt
runs through decryptPatch in sync/client.ts.
NOT full end-to-end encryption vs. the operator. The mutation
outbox (and therefore the push wire) still carries the caller’s
args as declared in the mutator — plasma doesn’t know which
args field maps to which .encrypted() column, so it can’t
envelope them at the outbox boundary. A schema that requires the
server to never see plaintext must call encryptField(...) on
the value inside the mutator body before passing it to
db.insert().values({...}); both the client’s optimistic run
and the server’s canonical run then observe the same envelope.
A future Phase 4.1 (queued for v1.1) is the schema-driven
args-boundary wrapper that would close this gap without asking
the mutator to opt in.
Omit to keep the historic behaviour of storing raw plaintext (the
DEK is optional because the schema DSL treats .encrypted() as
“declared eligible”, not “always active” — a caller who hasn’t
plumbed key material yet still gets a working client).
readonlydek:Uint8Array
readonlykeyId:string