03 Storage

This chapter defines persona storage, logical portability, encrypted-at-rest behavior, and optional encrypted-vault portability.

Purpose

Encrypted Storage defines how personal data is protected and made portable across implementations.

Protocol Requirements

A Dina-compatible storage system MUST provide:

Persona Model

The protocol persona tiers are:

These tiers are already present in the reference implementation.

Expected semantics:

Physical Storage Profile

A Dina-compatible Home Node SHOULD use an encrypted SQL store per persona.

The reference implementation uses SQLCipher-backed SQLite databases, one per persona, with encrypted-at-rest FTS and embedding storage.

Logical Vault Schema

A Dina-compatible vault item model MUST be able to express:

The reference implementation's persona schema currently includes logical fields such as:

The protocol SHOULD freeze the logical schema, not the exact SQL DDL.

Search and Semantic Hydration

The protocol SHOULD support:

The reference implementation currently provides:

Important storage rule:

Backup and Export

Base Dina storage interoperability is logical, not file-format-level.

At minimum, conforming implementations MUST support:

Implementations MUST NOT create silent plaintext backups as a side effect of normal backup or migration.

Safe profiles therefore separate:

Encrypted Vault Portability Profile

The current implementation has more than one active DEK derivation style:

This matters only if the protocol wants to guarantee one of the following:

Those guarantees are useful, but they are not required for base Dina interoperability.

Therefore Protocol 1.0 MAY defer canonical DEK derivation at the core layer, provided it freezes:

If an encrypted vault portability profile is later standardized, it SHOULD define: