Encrypted sync
Sync keeps a vault current across devices by reconciling it against a shared folder that you pick — and for a team vault, only ciphertext is written into that folder.
There is no Altretta sync server. Sync is a three-way folder reconciliation: your vault, the shared folder, and a record of what was last in agreement between them. You choose the shared folder — an iCloud or Dropbox folder, a Syncthing directory, a network share, even a USB drive. Whatever you point it at is the only thing in the path, and for a team vault it only ever sees sealed note contents.
What sync does
- Cross-device — open the same vault on your laptop, desktop, or another machine and pick up where you left off.
- Encrypted note contents for a team vault — bodies are sealed on the device before they are written into the shared folder, and unsealed only by members holding the vault key.
- You review the plan before it runs — sync shows what it will push, pull, delete on each side, and where the two have diverged, before anything moves.
Filenames and folder structure are not encrypted in a team vault, so the shared folder still exposes the vault's shape and every note's name. See The encryption model.
Conflicts keep both sides
When the same note changed on both sides since the last agreement, sync does not pick a winner for you. It marks a conflict and offers three resolutions: keep the local version, take the remote one, or keep both — the last of which writes the other side out beside your note rather than discarding it.
The same instinct runs through the whole engine: when sync cannot tell "changed" from "damaged" — for example when the shared folder comes back looking implausibly empty — it refuses to plan at all rather than proposing a wave of deletions.
How the Reader lock is enforced
A Reader's client won't offer editing in the first place. Beyond that, the enforcement is real but worth stating precisely: a Reader's device can write into the shared folder, and every other member's device refuses to accept it. Each change carries the author's signature, and on the way in it is checked against the signed roster — a change authored by someone who isn't authorised to write is rejected and never lands in your vault.
So "read-only" means a Reader's edits never converge into anybody else's vault. It does not mean they are physically prevented from touching their own working copy, which is plain files on their own disk. Rejected changes are reported to you by name and reason rather than being silently dropped.
The rejection reasons you may see: not a member, not authorised to write, revoked at the epoch the change was signed under, a replayed stale change, a bad signature, or an untrusted roster. See Roles & permissions.
A typical sync flow
Point the vault at a shared folder
Pick the folder once — an iCloud or Dropbox folder, a Syncthing directory, a network share.
Review the plan
Sync lists what it will push, pull and delete on each side, and any conflicts, before it touches anything.
Apply
Changes move. For a team vault, only sealed contents are written into the shared folder; teammates' devices unwrap the vault key locally and check each change against the signed roster before accepting it.
What does not travel
Sync moves your notes and attachments. It does not move your app settings, theme, layout, keyboard shortcuts, the semantic graph, or your note version history — those are held per device. See Vaults & workspace for where each thing actually lives.
Next
Understand how many synced folders each plan allows, what unlocks the team brain, and how seats work → Plans, seats & Enterprise SSO.
Related
Team brain overview
The section this page belongs to.
The encryption model
The sealing and unsealing that sync relies on — and what it doesn't cover.
Roles & permissions
Where the Reader lock comes from, and how rejection is reported.
Your vaults
What lives inside the vault folder and what stays on the device.
Signed history
The signed record every change is added to.