Problem
encryptedDynamoDB (@cipherstash/stack/dynamodb) is built on the EQL v2 schema surface: columns are declared with encryptedColumn("email").equality() / encryptedField, and searchable lookups use the v2 envelope's HMAC term (email__hmac attributes for key-condition queries via encryptQuery).
It has no support for the EQL v3 typed schema (types.* concrete-domain columns from @cipherstash/stack/eql/v3, EncryptionV3): a v3 table can't be passed to encryptedDynamoDB, and none of the v3 term shapes are consumed.
Why now
The docs are moving to EQL v3 as the sole documented approach for 1.0 (Drizzle, Supabase, and the core client are already there; prisma-next is in review at #655). DynamoDB is the deliberate exception — its skill keeps teaching the v2 schema until this lands, which leaves it the only integration on the old authoring surface.
Shape of the work (sketch)
- Accept v3 tables (
encryptedTable + types.TextEq / types.Text etc. from eql/v3); equality-searchable attributes come from the v3 equality (hm) term — same HMAC concept, new envelope shape (v: 3).
- Map the v3 storage envelope into the item-attribute layout (
<attr> ciphertext + <attr>__hmac term), mirroring what the v2 path does with c/hm.
encryptQuery(value, { table, column }) on a v3 equality column already mints the bare HMAC term — the DynamoDB key-condition path should consume that directly.- Skill (
skills/stash-dynamodb) moves to the v3 authoring surface once shipped; note that only equality (*Eq domains) is meaningful on DynamoDB (no range/free-text index engagement outside Postgres).
References
https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w
Problem
encryptedDynamoDB(@cipherstash/stack/dynamodb) is built on the EQL v2 schema surface: columns are declared withencryptedColumn("email").equality()/encryptedField, and searchable lookups use the v2 envelope's HMAC term (email__hmacattributes for key-condition queries viaencryptQuery).It has no support for the EQL v3 typed schema (
types.*concrete-domain columns from@cipherstash/stack/eql/v3,EncryptionV3): a v3 table can't be passed toencryptedDynamoDB, and none of the v3 term shapes are consumed.Why now
The docs are moving to EQL v3 as the sole documented approach for 1.0 (Drizzle, Supabase, and the core client are already there; prisma-next is in review at #655). DynamoDB is the deliberate exception — its skill keeps teaching the v2 schema until this lands, which leaves it the only integration on the old authoring surface.
Shape of the work (sketch)
encryptedTable+types.TextEq/types.Textetc. fromeql/v3); equality-searchable attributes come from the v3 equality (hm) term — same HMAC concept, new envelope shape (v: 3).<attr>ciphertext +<attr>__hmacterm), mirroring what the v2 path does withc/hm.encryptQuery(value, { table, column })on a v3 equality column already mints the bare HMAC term — the DynamoDB key-condition path should consume that directly.skills/stash-dynamodb) moves to the v3 authoring surface once shipped; note that only equality (*Eqdomains) is meaningful on DynamoDB (no range/free-text index engagement outside Postgres).References
packages/stack/src/eql/v3/columns.ts(typescatalog, capabilities)packages/protect-dynamodb/https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w