Linus Rath 96a6b38321 feat: sync the device's contacts and calendars with the server in the background #34
The sync adapters from ed2525e start a headless task for every sync, but
the task only reported "disabled". This adds the engine it runs
(`src/device-sync/engine`, `src/device-sync/jmap`): for one Android
account and authority it downloads the server's changes, uploads what
the device changed, and hands a report back to SyncManager.

- Downloads follow `/changes` from the state kept in the provider's
  SyncState. Rows and the state they reach are written in one batch, so
  a killed run resumes where it stopped. Without a state, after
  `cannotCalculateChanges` or after the user discarded deletions, a full
  reconcile compares ids instead.
- Uploads go in three phases across accounts (creates, updates,
  deletions), so moving an item to another account never destroys it
  before the copy exists. A create carries a uid written to the device
  first, and the server is asked for that uid before creating, so a lost
  response or a killed run never makes a duplicate. Updates are patches
  guarded by `ifInState`; nothing is replaced whole.
- More than 50 deletions that are also more than a fifth of the synced
  items hold every deletion back and report `tooManyDeletions`, so
  Android asks the user; "undo" restores the items from the server.
- An item the server refuses is marked and not sent again until it
  changes or its back-off (1 hour, doubling to a day) ends. Such
  refusals and planner errors stay with their item; the rest of the run
  goes on.
- Runs of one account and authority take a lock, stop at checkpoints
  when cancelled or close to the deadline, and never throw: every
  failure becomes an outcome, and a rejected sign-in posts one "Sign in
  again" notification.
- The JMAP side uses a client of its own per app account, never the
  UI's, since a run can share the JS runtime with the app.

Turning sync off or signing out runs the same upload first
(`teardownAuthority`) and deletes the rows only once nothing is waiting,
or when the user agreed to lose it.

The planners that map items to rows land in the next commits; until
then a run fails before it touches a row.

Checked: 94 engine tests against the fake provider and JMAP server
(sync flows, failures, crashes and retries, teardown), and `npm run
typecheck`, `npm test` and `npm run i18n:check` on this commit.
2026-09-27 04:19:21 +02:00
2026-09-27 00:34:53 +02:00

Bulwark Webmail

Bulwark Mobile

Beta - work in progress. Many features are unfinished or rough. Expect bugs, missing functionality, and breaking changes between releases. Do not rely on this for primary email yet.

React Native (Expo SDK 54) client for Bulwark Webmail - a JMAP-based mail, calendar, and contacts app.

What works today

  • Sign in to any JMAP server (e.g. Stalwart)
  • Multiple accounts
  • Email list, threads, compose
  • Calendar (basic)
  • Contacts (basic)
  • Push notifications via the Bulwark relay - FCM by default, or UnifiedPush (e.g. ntfy) for devices without Google Play services
  • In-app sideload updates from GitHub Releases

What's missing or rough

  • iOS builds, but push notifications and client certificates are Android-only so far
  • S/MIME, plugins, themes - UI stubs only (filters & rules, the vacation responder and file storage are real implementations)
  • Calendar editing is partial; contacts editing is basic
  • No Play Store distribution yet (sideload APK from Releases); iOS ships via TestFlight

Run locally

npm install
npx expo start

Then press a for Android, i for iOS, or scan the QR with Expo Go.

For release APK builds and signing see docs/android-release.md. For iOS builds and TestFlight distribution see docs/ios-release.md.

License

AGPL-3.0-only. See LICENSE.

S
Description
Bulwark Mobile: React Native client for iOS and Android. Mail, calendar and contacts over JMAP. Beta.
Readme AGPL-3.0
30 MiB
Languages
TypeScript 95.9%
Kotlin 2.1%
JavaScript 0.9%
Swift 0.4%
HTML 0.4%
Other 0.2%