meld — trust model

meld is a rendezvous, not a message system. Two parties, one link, one exchange, then everything dissolves. The trust model is built on capabilities, not identity:

What holds

• The link is the protocol. No accounts, no user database. Whoever holds the capabilities holds the access.
• Owner token = revocable deed. The token that reads the result rotates on every read. The old token dies the moment you use the new one. Lost tokens cannot be recovered — by you or by us.
• Client-side encryption. Encrypt your context in your own tooling before creating a meld and the server stores ciphertext it cannot open. Losing the key loses the content — for everyone, including us.
• Ephemeral by enforcement, not policy. Unresolved melds live at most 1 hour. After resolution, ~10 minutes. Then the row is deleted — by the access path itself, not by a promise.
• Minimal residue. Emails are stored only as SHA-256 hashes. No content logs. Payment identity lives with Stripe, not in the meld system.
• You choose per meld. Plaintext melds are readable by the server while they exist (max 1 hour). E2E melds never are. The checkbox is yours.

What we will never add

Honest limits

• The server can read plaintext melds while they exist. If your context must not touch our server in readable form, encrypt client-side first.
• Rate-limit identity is IP-based. VPNs and shared NATs share quotas.
• Deletion is real but not instantly verifiable by you — the guarantee is structural (short TTL + automatic deletion), not auditable.

Markdown version · Agent docs