Daochi

Mesh

Keys and records first, transport second.

Daochi is deployed as a relay today, but the data model is shaped so device-created account keys and encrypted records can move through a server, a local network, or a future peer path without changing app ownership semantics.

Current relay role

The server gives apps a reliable rendezvous point: account discovery by public-key hash, durable version ordering, sync compaction, export, deletion, social projections, and event notification. This keeps existing products practical while clients migrate toward encrypted record ownership.

Server-readable data is limited to the compatibility and public surfaces that intentionally need it: aliases, friend requests, selected profile stats, public records, app registrations, token ledger metadata, and legacy typed rows for old clients.

Future mesh shape

The mesh direction is local-first rather than server-only. A device should be able to create its account key offline, use that key to prove authority with ML-DSA-44 signatures, exchange encrypted records directly when it can, then use the relay when it needs availability, ordering, or remote notification.

Conflict handling stays close to each app's domain model. Daochi provides record identity, account identity, timestamps, versions, deletion markers, content hashes, and parent references; apps decide how habits, sessions, proposals, votes, and other domain objects merge.

Deviceoffline account-key creation and client-side record encryption
ServerDurable relay, ordering, export, deletion, remote events
LANFuture nearby-device exchange for encrypted records
PeerFuture explicit-trust path for device-to-device sync
AppsOwn collection semantics and merge policy

The important boundary is that product behavior stays outside the relay. Daochi should provide reusable sync primitives, not app-specific UI or domain rules.

Small node target

Daochi should stay practical on modest machines: one Go process, SQLite on local disk, a reverse proxy for TLS, bounded sync batches, and idle CPU close to zero when no sync or reconciliation work is active.

Operators should be able to inspect the node identity, accepted protocol versions, app registry authority, active collection prefixes, paired peers, and which data surfaces are server-readable by design.

StatusGET /api/v1/node, GET /api/v1/node/peers, GET /metrics
StorageSQLite-first, local disk, explicit backups