The problem a small handoff creates
Sooner or later a script produces something that another machine, another script or another person needs. It might be a build output, a measurement file, a database export, a model checkpoint or the state an agent wants to find again after a restart. The usual answers are a shared drive, a cloud storage account, a message queue or an email attachment, and each one brings setup that is out of proportion to a single handoff: credentials to create, permissions to configure, a client library to install and a service to keep running.
What the sender and receiver want is smaller than any of those. They want to put some bytes somewhere under a name, let exactly the right party read them, and be sure the next reader gets the intended version rather than an older or half-written one. They also want to do this with tools already on the machine, which for most people means curl or a few lines in whatever language the script is written in.
What it looks like in use
The service treats anything you can express as bytes the same way, whether that is a text snippet, an archive or a binary blob. You choose a box, which is a named space, and a name for the payload inside it. A write is an HTTP PUT of the raw bytes, and a read is an HTTP GET. Both carry a secret in the Authorization header, so the data and the credential travel separately and no JSON wrapper or base64 encoding gets in the way.
curl -X PUT -H "Authorization: Capability <write-capability>" \
--data-binary @results.bin \
https://in.svc.nz/example-box/results.bin
curl https://out.svc.nz/example-box/results.bin/latest \
-H "Authorization: Capability <access-capability>" \
-o results.bin
Each write to the same name creates a new version instead of replacing the old one. A reader can ask for the latest version, which suits a consumer that always wants the newest data, or for a pinned version, which suits a run that has to be reproduced later with exactly the bytes it used the first time. The response to a write tells the sender what was stored, so the version a downstream job should use can be recorded rather than guessed.
| Step | Label in figure | What happens |
|---|---|---|
| 1 | Store: send bytes + write secret | The sender PUTs the payload under a name and a new version is recorded. |
| 2 | Hand over: pass a read secret | The sender gives the receiver a secret that can read, not the file. |
| 3 | Fetch: latest or pinned version | The receiver GETs the bytes with the read secret in a header. |
Why a secret rather than an account
The precise term for the access model is a capability. A capability is a piece of unguessable authority that names a resource and says what its holder may do with it, so presenting it is enough and the server does not need to look up who you are first. That is why a receiver with a read secret can fetch a file without registering anywhere, and why the same sender can hand a different party a secret that allows writing to one name but not reading anything else.
The trade-off is the same one a physical key carries. Anyone who copies the secret can use whatever it allows, so the sensible habits are to issue the narrowest secret the job needs, to send it through a different channel from the data and to keep it out of URLs, chat transcripts and log files. Headers are the standard place for credentials, and the bearer token specification warns about the leakage that comes from putting them in query strings. A copied secret stays usable wherever it lands, yet a header removes several of the easiest ways for one to escape.
What it is not, and what is still unknown
It is not a shared drive. There is no folder browser, no comment thread and no search across other people's files, and it does not try to be the only copy of anything important. The design targets the moment two programs or two devices need to exchange bytes, and for the small team that would rather run something private for that purpose than adopt a collaboration platform.
Three limits are worth knowing before you rely on it. Expiry ends normal access to an object but does not promise that the underlying bytes have been physically erased. Transport encryption protects the connection while the operator can still read what is stored, so only encrypting the bytes yourself before upload keeps the plaintext from the operator. And the service is currently an invite-only private trial: reading and writing an existing box needs only its secret, while creating a new box needs an invitation, and the hosted service does not yet carry the guarantees a public multi-tenant product would.
If your handoff is one file between two machines, the guide to sending a file with curl and no account walks through the commands in full. If the question is how the secret differs from an API key, read the capabilities guide next, and keep your original data until you have confirmed that the receiver fetched the right version.
FAQ
Is it a file sharing site with accounts and folders?
It stores named payloads of bytes and returns them over HTTP, with no folder browser, no inbox and no recipient account. It suits a handoff between programs or devices better than a shared drive for people.
Does the person fetching a file need an account?
Fetching from an existing box needs only the access secret and any HTTP client that can send a header. Creating a new box is by invitation while the private trial runs.
What happens if someone copies the access secret?
Whoever holds it can use exactly the authority it grants, so keep it out of URLs, tickets and logs, share a read-only secret where a read is all that is needed, and replace it if it leaks.
Can the operator read what I store?
Without client-side encryption the operator can read stored bytes. If you encrypt before upload and keep the key elsewhere, the service holds only ciphertext.
Sources
HTTP Semantics, the standard reference; Bearer token usage; curl man page; OWASP, information exposure through query strings.