Design: sealed Records for a group's sensitive data #428

Problem

Core doesn't encrypt, and the host can read everything. That's the right default: encryption everywhere brings the key-loss failures that cost people their history, and most data doesn't need it. But a group on a community host may hold a few Records it would rather the host couldn't read, before it's ready to self-host.

App-by-app encryption isn't a good answer: each app invents its own scheme, and if the app disappears its users can't decrypt their own data.

Direction

• Seal only what a group marks sensitive. Everything else stays plaintext, so key loss costs only the sealed Records, never the whole history.
• Core owns the format, specified in the spec, so any Haverstack client holding the key can decrypt.
• Custody through a callback, as the credential callback signs today, so core never holds the key.
• Recovery through shares held by members, from Design: key lifecycle (custody, recovery, rotation, and acting as a Group) #422.

Costs to state

• Sealed content can't be filtered, sorted or searched, and the server can't validate it.
• Metadata stays visible to the host: the Type, timestamps, associations, permissions and authorship.

Questions

• Is a Type sealed, or a single Record?
• What does schema validation mean for sealed content: validated by the client before sealing, or not at all?
• How does a member who joins later get the key, and what does removal do to it?

Order

Blocked by #422.