What a remote sees when you sync

When you push to a relay or a Forge, the server stores your objects. The design claim is that it is untrusted for confidentiality: it can serve your repository without being able to read the protected parts of it. That claim is real, and it has edges worth knowing.

What the server cannot do

• Read protected plaintext. It holds ciphertext and wrapped keys. It never holds a recipient secret or a content key.
• Grant itself read access to protected content. For protected object content there is no server-side read check to subvert — granting read means adding a wrapped key, which requires a key the server does not have, so a fully compromised server does not become a reader. This is specifically about protected content: a Forge does run ordinary server-side authorization over its collaboration surfaces, and that authorization is enforced by the server rather than by cryptography.
• Tamper with your read/decrypt audit chain. Not because it is protected from the server, but because the server does not hold it: that chain does not replicate today and exists only on the machine that wrote it. Treat it as a local tamper-evident log rather than as replicated evidence — it detects an altered or removed entry, but not a reset of the chain head, and a server can refuse to serve newer collaboration entries it does hold.

What the server does see

This is the part a confidentiality claim usually skips.

• Every unprotected object, in full. If a path is not covered by a policy, its contents are readable by the host. Encryption is per-path and opt-in, not blanket.
• The shape of your history — the commit graph, refs, and object sizes.
• The policy manifests, in clear. This is by design: policy expressions must be public so any client can evaluate them offline and deterministically. So the server can see that a path is protected and by which expression, even though it cannot read the contents.
• At the team tier, who may read. The set of identities a protected object is wrapped for is metadata the server can observe.

The accepted limitation

Object sizes, graph shape, policy expressions, and recipient sets are not encrypted, so traffic analysis over them is possible. This is recorded as an accepted limitation rather than a solved problem. The enterprise attribute-based tier reduces recipient-set leakage by moving the policy into the ciphertext, but the existence and size of a protected object stay observable even then.

Write access is enforced by the server, not by mathematics

Read access is cryptographic. Write access to a gated path is enforced server-side: the server verifies a proof before accepting the write. That means a fully compromised server could in principle accept a write it should have refused — the mitigation is that every object is re-hashed and every signature re-verified by clients on receipt, so a forged write is detectable rather than invisible.

Nothing syncs to a remote you did not configure

A repository with no remote contacts nothing. Once a remote exists, automatic pull is on by default, and under the default push mode the first publication of a lane stays a manual act. The settings that change that, and the one that removes the protection, are covered in Does TOVIO connect to a remote on its own?