Mesh
Records first, transport second.
Daochi is deployed as a relay today, but the data model is shaped so 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, 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. Devices should eventually exchange encrypted records directly when they can, then use the relay when they need 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.
The important boundary is that product behavior stays outside the relay. Daochi should provide reusable sync primitives, not app-specific UI or domain rules.