mirror of
https://github.com/bulwarkmail/native.git
synced 2026-10-31 08:06:36 +00:00
docs: describe how contacts and calendars will sync with the device #34
Issue #34 asks for contacts and calendars that show up in Android's own apps and whose edits there reach the server. docs/device-sync.md is the design the implementation follows: Android's sync framework drives the runs, a thin Kotlin shell starts a headless JS task, and the engine is TypeScript on a detached JMAP client, so token refresh, mTLS and session discovery keep a single owner. A pure-Kotlin engine was rejected: it would have had to redeem rotating refresh tokens outside that owner and re-implement the client. It pins down what every provider column holds, the JSContact and JSCalendar mapping tables, how device edits are told apart from provider normalisation (a baseline per row), how rows are matched when an editor re-inserts them, the merge and conflict rules, uploads as patches with `ifInState`, the native API, the failure matrix and the limitations. The platform and server facts it relies on come from AOSP's providers and calendar/contacts apps, Fossify, Etar and Stalwart v0.16.23's source. These were checked on the local test server: - map keys written through JMAP survive patches; `uid` duplicates are refused; unknown and plural recurrence properties are rejected - a start or `until` in a DST gap or overlap is silently dropped (a daily rule came back unbounded); `Etc/GMT-2` keeps both - `ifInState` yields `stateMismatch`; `relatedTo/<key>: null` does not delete; result references to `/set` are refused An adversarial review of the first draft found 20 paths that could lose data, duplicate items or loop (own creates duplicated after a lost response, unsynced edits dropped on deselection or eviction, Fossify rewrites uploaded as edits, Etar moves turned into destroy + create, and more); the design was changed for each before any engine code.
This commit is contained in: