Card types and custom fields

Memories knowledge cards support ordered, typed fields as well as their existing title, document body, tags and links. The built-in types are note, contact, link, snippet, checklist, event and credential. A type supplies starting fields, not a restriction on which additional fields a card may contain.

Schema

Content.card_type is an optional string: a built-in name or a custom template ID. Content.fields is an ordered array:

{"id":"work-email","name":"Work email","kind":"email","value":"name@example.com"}

Field IDs stay stable across renames and reordering. Supported kinds:

null means empty (or masked for a sensitive field). Select kinds require a non-empty, unique options array; other kinds must omit options. A card has at most 64 fields, with unique IDs, bounded names and bounded values.

Encryption and authorization

Every revision encrypts the complete Content with the existing vault encryption. Ordinary-card sensitive values are removed from fields and stored in the internal field_body, a base64url structured body inside that encrypted revision, analogous to credential bodies. Base64url itself is not encryption. field_body is never returned by normal read/list/show operations, and sensitive field values appear as null. Document bodies remain unchanged and searchable; sensitive values are not placed in the document body or retrieval cache. Diffs show descriptors and non-sensitive fields only.

Deliberate card_fields with reveal: true requires verified CLI/mobile elevation, or an MCP allow_all capability. Delivery intent is audited and committed before plaintext is returned. MCP capabilities never inherit terminal elevation. Mobile typed-field reveal additionally requires a successful system biometric/PIN check, even when optional quick unlock is disabled; canceled or unavailable checks do not fetch sensitive values. The desktop browser editor deliberately has no secret-reveal or password endpoint; use the verified native app or CLI for sensitive values.

Reusable templates

Templates are private, encrypted, signed card revisions carrying type_template: {id, name, fields}. They use existing revision history, vault authorization, conflict handling and encrypted device/cloud sync, rather than an unsigned side database. They are omitted from ordinary card lists/retrieval. Built-ins cannot be modified or deleted. A custom template may be created from an existing card; sensitive defaults are always masked. Creating a template directly with a non-null sensitive default is rejected.

Updating or deleting a template does not rewrite existing cards. Cards keep their own fields and can still be edited after their template is deleted.

CLI

Start the daemon with the same dedicated home used by clients:

memories daemon
memories type list VAULT
memories type create VAULT Project --from-card CARD
memories type show VAULT TYPE
memories type update VAULT TYPE Project --fields template-fields.json
memories type delete VAULT TYPE
memories card create VAULT --title Ada --type contact
memories card put VAULT --title Notes --type note --input notes.md
memories card field add VAULT CARD Team --id team --kind text --value Core
memories card field add VAULT CARD Status --kind single_select --option Open --option Done
memories card field set VAULT CARD team Platform
memories card field rename VAULT CARD team "Working team"
memories card field mv VAULT CARD team 0
memories card field rm VAULT CARD team
memories card field list VAULT CARD
memories sudo
memories card field add VAULT CARD Key --kind sensitive
memories card field list VAULT CARD --reveal

Sensitive values use hidden terminal prompts, never command-line values. Numbers, checkboxes and multi-select values use JSON syntax. Use the short IDs returned by CLI list/show, including custom type IDs. --fields accepts a JSON field array.

Daemon, FFI and MCP

The shared JSON/C ABI supports type_list, type_show, type_create, type_update, type_delete, card_create, card_fields, and card_field. card_field.operation uses action: add|remove|reorder|rename|set with the field, ID, zero-based index, new name or value respectively. Native form saves also use replace to atomically save an ordered field array while preserving masked existing sensitive values. These operations append signed revisions and retain the original asset kind.

MCP tools use the same names for templates, card_fields for masked inspection, and card_field_add|remove|reorder|rename|set for mutations. card_field_reveal requires a single field ID, intent: "reveal_plaintext", a short reason, and allow_all scope. MCP cannot request whole-card secret delivery. Normal writes require write scope; type deletion requires delete scope. Sensitive mutations require an independently verified allow_all MCP capability; this does not create a terminal elevation session or expose private ordinary cards.

Flutter uses the existing memories_call JSON ABI: no ABI symbol change is needed. Its generic editor includes the type picker, per-kind inputs, field renaming/removal and drag reordering. Hosted entry uses the same form and retains the server-readable warning.

Hosted and device-sealed cards

Hosted SaaS RPC exposes these operations within the bearer’s vault and scope. Server-readable hosted cards still use vault encryption at rest. An e2e card cannot contain non-null sensitive fields or an internal field_body; both raw put and field mutations reject plaintext sensitive values. Plain descriptors can be edited without sending sensitive values to Center.

The paired-device mobile sealing form sends only an encrypted envelope. Generic cards use this envelope plaintext, constructed on the client:

{"memories.card":1,"meta":{"card_type":"contact","fields":[
  {"id":"key","name":"Key","kind":"sensitive","value":null}
]},"body":{"text":"notes","sensitive":{"key":"value"}}}

Center receives the envelope, not that plaintext. memories device sealed-get --vault V --card C --field key --reveal reads one field on a trusted paired device. Legacy raw-secret and structured-credential envelopes remain supported.

Compatibility

Missing type and field members deserialize with defaults. Existing untyped cards are treated as note without rewriting their bodies. Legacy credentials are treated as credential; plain metadata maps to plain fields and secret body values map to sensitive fields on read. Credential field edits retain the existing structured credential body so copy, OTP and injection consumers keep working. Binary legacy credentials reject generic text-field migration rather than discarding their bytes. Previous signed revisions remain in history.

Upgrade all devices before exchanging the new schema: older executables that reject unknown JSON members do not understand new typed-card revisions.