Storage

Object storage has two halves:

• Bytes live in the Cloud’s blob backend: a local directory, or an S3 bucket over HTTPS (the AWS deploy), or an S3-compatible store such as MinIO.
• The catalog — bucket, key, size, etag, content type, state — is Cloud metadata in the control store.

The etag is whatever the backend reports (SHA-256 of the bytes on the filesystem backend, the store’s ETag on S3). The Cloud computes no digest of its own over object bytes.

Native is not the blob authority. No object byte, name or digest enters a project’s Native directory, WAL or proofs; nothing about storage is Native-verified; a snapshot of the project does not include its objects, and restoring the project does not touch them.

Buckets and keys

Buckets are catalog namespaces inside a project (3–63 characters: lowercase letters, digits, dashes), not S3 buckets of your own. Keys are up to 1024 bytes and may contain /. Objects are capped by the daemon’s CLOUDD_STORAGE_MAX_BYTES (32 MiB by default).

Upload and download

An upload is a Cloud route with your credential: POST …/storage/uploads reserves a catalog row (state: pending) and returns an upload_url; PUT the bytes there and the row becomes stored. Downloads mirror it (POST …/storage/downloads, then GET). No presigned blob-store URLs are issued; the blob backend is never exposed.

Both the owner’s session and a live project key can upload, download, list and delete objects; only the session can create buckets. There is no bucket deletion, multipart or streaming upload, pending-upload cleanup or listing pagination in this version.