v4 transition
Clients can dual-write legacy typed rows and encrypted records. Released legacy encrypted collections remain valid so users do not need an immediate second backfill.
Protocol
Post-quantum proof of account authority.
The protocol keeps shipped compatibility clients working while moving new clients toward device-generated account keys, ML-DSA-44 account signatures, encrypted private records, app-owned collection namespaces, signed transaction envelopes, and transport-neutral record envelopes.
Identity and authentication
A client account starts with key material created and retained by the client. The ML-DSA-44 keypair is the root account authority. The account is identified by the hash of its public key, so a device can create the durable identity before it ever contacts the relay. First sync or login registers the public key. Later login starts with a single-use challenge for that account, then the client signs a canonical request body with ML-DSA-44. Daochi verifies the post-quantum proof of control and returns a bearer token for ordinary sync and social endpoints.
Bearer tokens are operational credentials, not the durable account identity. Clients should repeat the challenge and login flow when a token expires, receives a 401, or the server restarts with a new development token secret.
Key origingenerated client-side before relay registration
Challenge
GET /api/v1/sync/challenge?user_id=<hash>Login
POST /api/v1/sync/login with signed JSONSignatureML-DSA-44 account proof
TokenHMAC bearer credential scoped to the account hash
ClockResponses include server Unix time for client expiry skew handling
Sync surfaces
The legacy typed sync surface stores rows and JSON payloads that the server can read and compact. It remains available for clients that shipped before encrypted private records were primary.
Encrypted records are keyed by collection and id. The server validates names, versions the records, relays them to newer clients, exports them, and deletes them with the account, but does not need to inspect the ciphertext. Protocol v5 treats encrypted records as the primary private-data surface and returns legacy private rows only when clients explicitly request them. The relay stores opaque ciphertext; apps remain responsible for their record encryption scheme, nonce discipline, and key rotation.
New clients should follow the recommended encrypted record profile: bind account, app, collection, record ID, and schema as associated data; use fresh nonces; and rotate keys by writing new record versions with new key IDs.
v5 primary mode
Private app data moves through encrypted hierarchical collections such as private.app.v1.records while social projections stay readable by design.
v6 signed mode
Strict requests include a registered app_id, an app-owned collection prefix, and an X-Daochi-Tx envelope signed by both the account key and an active app key.
Signed transactions
Protocol v6 uses X-Daochi-Tx to bind the account, app, HTTP method, path, exact request body hash, nonce, and expiry into one replay-protected transaction. The account signature proves user authority. The app signature proves the request came from software holding an active key from the signed app manifest.
The envelope is JSON or base64url JSON. It is verified the same way for CLI, TUI, mobile, desktop, and browser clients because the signed material is protocol data, not a platform-specific package identifier. Transactions expire quickly and are stored by tx_id and nonce so replayed requests are rejected.
Header
X-Daochi-TxContext
daochi-tx-v1AccountML-DSA-44 signature over the canonical transaction
AppEd25519 signature from an active manifest key
Private key boundary
Normal login, sync, signed transactions, and account deletion do not upload the account private key. The website deletion helper can accept an exported account key file for recovery and support cases; it signs a fixed deletion proof, verifies that proof against the registered public key, deletes the account data, and does not store the uploaded key.
This distinction matters for the security claim: Daochi's account authority is post-quantum through ML-DSA-44 signatures, while encrypted record confidentiality is provided by client-side ciphertext that the relay is designed to move without reading.
Developer path
A new app should be able to create an account key, login, register a signed manifest, write one encrypted record, read it back, and inspect trust state without learning every legacy surface first.
Compatibility policy
Protocol v1 through v5 remain valid through 2027-09-01. After that, protocol retirement is staged: the current protocol remains valid, and the immediately previous protocol remains valid for at least 365 days after any deprecation decision. Compatibility warnings are recorded server-side without blocking those older clients.
Remote event stream
GET /api/v1/sync/ws upgrades to a small event stream that tells clients when newer sync data is available. Native clients authenticate with Authorization: Bearer <token>. Browser clients can use Sec-WebSocket-Protocol: daochi-sync-v1, bearer.<token> because browser WebSocket APIs cannot set arbitrary headers. Legacy Ksync and Inbe subprotocols remain accepted.
Daochi rejects ?token= WebSocket URLs so bearer tokens do not leak through request URLs, browser history, proxy logs, or crash reports.
challenge sign canonical body login sync remote-event sync again