Cloud Sync

Cloud sync is currently experimental for v1. The encrypted sync engine and sync server exist, but Notidian should not be described as fully shippable sync until the manual two-client QA pass in #647 is complete.

If you use sync now, keep an independent backup of your vault.

Current status

Notidian’s current sync path is the Notidian encrypted sync server, not Google Drive/iCloud/OneDrive direct sync.

Area	Current v1 status
Private vault sync	Implemented as encrypted single-account, multi-device sync
Encryption	Master key derived locally; server stores encrypted manifests and blobs
Manual sync	Available from Settings → Account / Sync engine → Sync now
Automatic triggers	Save/local-change events, auth unlock, and focus regain can request a sync pass
Conflict handling	Preserves conflicting remote content as name.conflict-<timestamp>.ext files
Polished conflict UI	Not implemented yet
Manual QA	Pending #647 before final v1 decision
Sharing/collaboration	Not part of this sync surface

How sync works

1. You sign in to a Notidian sync account.
2. The app unlocks your local encryption key material on this device.
3. A sync pass compares the local vault with the encrypted server manifest.
4. Changed files are encrypted locally and uploaded as ciphertext blobs.
5. Missing remote files are downloaded, decrypted locally, and written to the vault.
6. Deletes are tracked with tombstones so another device can remove the same file safely.

The server should not be able to read note contents or paths.

Conflict handling

When the same path is edited differently on two devices before sync catches up:

1. Notidian keeps the local file at its original path.
2. The remote version is downloaded and written beside it as a name.conflict-<timestamp>.ext file.
3. Settings shows a conflict count.
4. You must manually compare, merge, rename, or delete the conflict file.

There is no in-app diff/merge/resolve workflow yet. That is the biggest UX limitation before sync can be called stable.

What still needs manual QA

The v1 decision depends on #647 covering realistic app flows, especially:

• Sign-in, sign-out, expired session, and understandable auth failure states
• Two different accounts proving data isolation
• First sync from an existing local vault
• Fresh client download/rehydration from existing server data
• Two-client create/edit/delete/rename flows
• Attachments/blobs and larger vaults
• Offline edits followed by reconnect
• Same-note conflicts and delete-vs-edit conflicts
• Server outage or partial upload/download failures
• Recovery without duplicated or erased local data

Possible v1 decisions

After #647, sync should be explicitly labelled as one of:

• Experimental beta — if manual QA finds no release-blocking safety issues
• Hidden/opt-in — if core flows work but the UX/recovery story is not ready by default
• Deferred/post-v1 — if there are data-loss, account-isolation, auth, or unrecoverable failure concerns

See docs/V1-SYNC-DECISION.md in the repo for the release-note wording options and decision brief.