Apps

Data belongs to apps, not to a hard-coded client.

The registry lets Daochi understand which app owns which collection prefixes, which app keys can sign transactions, what visibility class records use, and which capabilities the app expects from the relay.

Registry

GET /api/v1/apps lists registered apps. Admin registration can add or update apps when KSYNC_ADMIN_TOKEN is configured and the request supplies X-Ksync-Admin. New clients should prefer POST /api/v1/apps/register-signed, which accepts a signed manifest plus a node registry approval signature.

Registrations describe protocol ownership only. Product UI, business rules, and app-specific behavior stay outside the relay. App records should declare private, shared, friends, and public hierarchy prefixes according to the data they own.

Private

Account-owned encrypted data that should not be shared by the server without explicit client behavior.

Shared

User-grantable collections that can be exposed to another registered app through an account grant.

Friends

Records designed for friend-visible projections and social surfaces.

Public

Records intended to be readable outside the private account sync path.

Signed manifests

A signed manifest contains manifest_version, app_id, display metadata, active Ed25519 app keys, collection prefixes, capabilities, and optional token policies. The manifest is signed by one of its active app keys, then approved by the node registry key configured on that Daochi node.

Registration is per node. A node operator chooses which registry approval public key to trust, so a self-hosted node can accept a local registry while a public node can use a stricter review process. The same manifest format works across command-line, terminal UI, browser, mobile, and desktop clients.

RegisterPOST /api/v1/apps/register-signed

Manifestdaochi-app-manifest-v1 app-key signature

Approvaldaochi-app-approval-v1 node-registry signature

Rotationpublish a new manifest with replacement active keys

App grants

App grants let an account allow a target app to read a selected shared collection prefix from a source app. Daochi validates the source app, target app, collection prefix, and permission before creating the grant.

GET /api/v1/account/app-records returns authorized records for the account when the grant exists. Revocation deletes the grant without deleting the underlying app records. New clients can use the signed grant endpoint so the account and app identity are both bound to the grant request.

CreatePOST /api/v1/account/app-grants

SignedPOST /api/v1/account/app-grants/signed

ListGET /api/v1/account/app-grants

ReadGET /api/v1/account/app-records

RevokeDELETE /api/v1/account/app-grants/{id}