Cloud version and local cache

Data, sync & account

Cloud version and local cache

Which copy is authoritative, the order of saving and uploading, how images go up, and what is left when you are signed out.

Which copy is authoritative

Projects on ordinary free accounts stay on this device; signing in does not upload them. Active subscription or recorded legacy Global access lets you enable sync for selected projects, with an account-scoped cloud version and a complete local copy. Browser uses IndexedDB in the current browser; Desktop uses a local project folder and SQLite store.

Opening a linked project runs this check:

  • Compare against the summary in the project list first: unchanged cloud and nothing pending locally means no full pull—start writing.
  • If the cloud is newer and your local copy is clean, pull it and overwrite the cache; desktop then rewrites the design file and derived memory.
  • If you have pending local edits (including the 350 ms debounce) and the cloud moved on too, that is a conflict, and both copies are kept.

The order of saving and uploading

Every edit saves locally first. Only a project with sync enabled and valid account access queues an upload after that save. Network failure never undoes a local save; with valid access, reconnecting retries the latest draft. Expiry or a failed access check pauses cloud uploads while local writing continues.

  • The top bar distinguishes Saved locally from Synced and shows syncing, offline, paused, failed and conflict states. Cloud failure does not undo a successful local save.
  • An open linked project reconciles on window refocus and on a 60-second summary heartbeat; background tabs run no timer, and switching away or closing the project stops it. Heartbeats never swap your draft while you are typing.
  • Before a cloud AI task, the client drains the sync queue and checks the version; a mismatch blocks the task openly instead of running on stale data.

How images go up

On the way up, long data-URL images in the draft and in records are split into content-addressed blobs: the same image shares a stored asset within each project, and the project JSON keeps only a light reference. Opening and reconciling restore images from those references before handing the draft to the local cache. First upload takes the same path—if the images have not finished, the cloud project just created goes to the trash and no local link is made, so no half-finished project is left behind.

  • A reference whose image cannot be fetched stays in the draft as it is, with a sync error attached; it is not quietly deleted.
  • A single image over 20 MB of raw bytes, or a draft still over 32 MB after dehydrating images, is marked as an error and the same content is not re-uploaded in a loop. Split or shrink such images.

Signed out, or offline

Signed-out and ordinary free projects do not upload automatically. Browser projects depend on the current browser's storage; clearing site data removes local-only projects and un-uploaded edits. Export a project pack before changing browser or device. Desktop uses a local project folder you can copy for backup.

Offline writing saves locally and uploads on reconnect while cloud access remains valid. Expiry does not delete existing work: local editing, saving and export continue, and existing cloud projects remain available to read, export or delete. Renewal checks both versions before resuming sync. If the cloud project is deleted, its local link is removed while the work itself stays on the device.

Limits and troubleshooting

  • Sync reconciles whole content versions, not field-level three-way merges—which is exactly why a conflict keeps both sides instead of auto-merging.
  • On a sync error keep the page and the local project; never clear site data. A repeated failure stays visible as “Sync failed” with a reason.
  • The first step in changing devices is exporting a .quill.json pack, not copying browser storage.

Recovering after a conflict: Conflict copies; backup and migration: Exporting and importing a project pack.