Cloud sync for user data is not just upload and download. It has to protect private content in transit, keep storage cheap, serialize writes from multiple devices, understand different data shapes, ask for confirmation before dangerous deletes, and preserve a way back when a decision turns out wrong.
Orkas treats cloud sync as a product boundary, not a background utility. Conversations, agents, skills, task state, knowledge files, and settings all need to move across devices while keeping a clear chain of responsibility: the device prepares content, object storage holds bytes, and the server owns the authoritative index.
The framework below is the one we use to reason about the system: encrypted content flow, content-addressed storage, account-level sync lock, server-owned commit, deterministic sync rules, model-assisted conflict handling, delete confirmation, recycle bin, and recovery markers.
The sync contract
Each sync pass answers four product questions: what content is eligible to move, how is it protected, who is allowed to publish a new cloud index, and how can the user recover if sync made the wrong call?
Encrypted content path
User data is prepared on the device before it reaches storage. The sync engine normalizes the candidate set, computes content identity, encrypts payloads, uploads through short-lived credentials, and verifies downloaded bytes before writing them back to the device.
Storage and index
Orkas separates stored bytes from the cloud index. Content objects hold the encrypted data. The index records which logical data items should exist, their content identity, version counters, stored size, cloud revision, and tombstone state. The device also keeps a baseline from the last successful pass so it can tell old state from new edits.
One sync pass
A pass starts cheap and becomes strict only when there is real work. Orkas first checks whether anything changed, then obtains the account sync lock, recomputes changes while that lock is held, moves content, asks the server to commit index operations, and finally updates the device baseline.
Sync lock and commit
The sync lock and the commit check solve different problems. The sync lock reduces wasted concurrent work across devices. The server-side lock serializes index writes. The expected cloud revision check prevents an older read from becoming the next truth. Quota and schema checks run in the same server-owned commit path.
Rules before conflicts
Most sync decisions are not conflicts. The device compares the baseline, current device data, and cloud index. If only the cloud changed, pull. If only the device changed, push. If both changed, route by content type. If something disappeared, enter the delete-safety path instead of immediately removing data.
Conflict handling
When both sides really changed, Orkas does not collapse everything into last-writer-wins. Append-style logs can merge by missing records. Lists can merge by stable record identity. Structured JSON can use version counters and timestamps. Markdown and binary files are conservative: if the system cannot prove a lossless merge, it keeps a full copy of the losing version.
For ambiguous text or structured-content conflicts, the product can package the relevant versions for model-assisted handling. The model can explain the conflict, draft a merged version, or help the user choose. It is not the only guardrail: deterministic validation, archived originals, and user-visible recovery remain part of the path.
Delete confirmation
Deletes are treated as state transitions. A remote delete becomes a tombstone. A device-side delete becomes a candidate operation. Orkas checks recent writes, watches for large delete waves, and pauses the pass for confirmation when the amount of disappearing user data looks risky.
Recycle bin and recovery
Before a valid delete removes a device copy, Orkas moves it into the sync recycle bin. Conflict losers are archived for review. Pending uploads survive a failed commit so the next pass can reuse bytes. If a user deliberately clears cloud data, other devices see a cleanup marker and stop re-uploading stale content.
What this buys us
The result is a sync system with clear boundaries. Devices prepare and verify content. Object storage holds encrypted bytes. The server publishes the index. The account sync lock and server lock keep passes orderly. Rules handle the common cases. Model assistance helps with ambiguous conflicts. Delete confirmation and the recycle bin protect users from the most expensive mistakes.
That is the standard Orkas needs for cloud sync: not magic, not a blind mirror, but a careful mechanism that lets user data move between devices and still feel consistent.