These are plain answers about moving files over HTTP, capability authorisation, agent handoffs, temporary secrets, versioning, and encryption. Each guide starts with the general answer and then shows where svc.nz fits. Reading and writing a box that already exists needs only its capability token, and creating a new box or account is invite-only for now.
Recovering an interrupted upload means establishing how much of it the server confirmed and continuing from there instead of starting again. This guide also covers what to do when the response goes missing entirely.
Moving a file between two machines over HTTPS needs little more than curl's binary upload mode, a named object, and a capability token in the Authorization header. The guide covers versions, expiry, and how this compares with S3 presigned URLs.
An API key establishes who is calling, whereas a capability establishes what one particular resource will allow. That difference changes how permissions are delegated, how they expire, and how they are revoked.
Two programs can coordinate through a small handoff message that points at one specific version of the bytes, which keeps the payload separate from the signal. Scoped capabilities, validation, and retries keep the workflow understandable.
Production credentials belong in a secret manager rather than in a chat window. A temporary handoff can still be made considerably safer through a narrow scope, a short expiry, client-side encryption, and delivering the key separately.
Keeping successive versions of a configuration file needs somewhere that records every write separately and lets you ask for either the latest version or a pinned one. The guide covers validating a config and rolling back without rewriting history.
Encryption in transit protects the network path, while encryption performed by the client before upload decides whether the storage provider can read anything at all. The guide covers ciphertext, keys, metadata, recovery, and the practical limits.