threat model

the honest version is more useful than the optimistic one. this says plainly what sync protects against, and what it does not.

what it protects against

the relay operator, including us. every op is sealed on your device before it leaves. a relay, ours or one you run yourself, holds ciphertext, sizes, hashes, and a document-grouping id derived from your own metadata key. none of that decrypts without your account's keys, which the relay never receives. see how sync is encrypted for the actual primitives.
a breach of the relay. if a relay database or blob store leaks, whoever has it holds the same sealed blobs the operator does: unreadable without your keys. this holds whether the relay is ours or self-hosted.
a network observer between your device and the relay. the connection is https, and the payload inside it is already sealed regardless, so an observer on the wire gets nothing beyond what any https request leaks: that a connection happened, to which host, roughly how much data moved.
a device you've revoked. once revoked, a device cannot decrypt anything synced after that point and cannot forge a valid authorship chain for it, because it never receives the new key epoch. see the revocation section on the encryption page.

what it does not protect against

a device that's already unlocked. sync protects data in transit and at rest on the relay. it does nothing for a device someone is holding, logged in, screen unlocked. that's an os-level and physical-security problem, outside what a sync protocol can solve.
losing the recovery phrase. nobody, including us, can recover an account without it. that's the direct cost of a relay that cannot read your keys either: there is no "reset password" path that doesn't also mean someone can read your writing.
metadata, to a point. a relay operator can see how many devices you have, roughly how often you sync, and roughly how much data moves, because those are properties of the network traffic itself, not the payload. it cannot see what changed, what document it belongs to in any readable sense, or its content, size aside.
what the relay logs at the http layer. by default the relay logs method, path, status, and latency, which is normal server operation — it does not log request bodies, blob hashes, or the document-grouping id. a reverse proxy in front of it (nginx, caddy) can still log the client ip in its own access log unless the operator configures that away; that's a proxy-configuration choice, not something the relay protocol controls.
a compromised device you're still using. if a device is compromised while it still holds valid keys, whatever it can read, so can whoever compromised it. sync has no way to distinguish that from you.

on the crypto itself

the primitives are named on the encryption page: bip-39, hkdf-sha256, xchacha20-poly1305, ed25519, x25519, blake3. no third-party audit of this code exists yet. the sync module is a few thousand lines (src-tauri/src/sync/), the relay's auth path is public alongside it, and an audit is a goal for 1.0, not something claimed now. security issues: hello@shizumu.app.

reproducible builds

a signature on a release proves the maintainer built it. it does not, by itself, prove the binary matches the published source. this is not yet solved here: it's planned, starting with the flathub build, which already builds from a pinned commit and vendored dependencies, the easiest starting point for verifying a binary against its tag. not done yet, said plainly rather than left unmentioned.