Every storage provider will tell you what they promise not to do. That is a policy, and policies change with a board meeting, an acquisition or a court order. This page is the other list — the things we are structurally unable to do, and the reason for each. It is shorter to verify than a trust statement, and it does not depend on us keeping our word.
Six things, and why
Encryption happens on the gateway you run, before a byte leaves your building. The key material is derived on your host from your own secret. Why not: we never receive the key. There is no XNS-side copy, no escrow, no recovery path we could be compelled to use. If you lose your key material, we cannot help you either — that is the same fact stated from the other direction, and it is the honest cost of this design. Buckets, keys, sizes, folder structure, versions, tags and access times live in the gateway's own database, on your host. They are never replicated to us. Why not: the XNS-side service that handles contracting and settlement — the only system that ever talks to your Relayer about money — contains zero occurrences of the word “bucket.” It has no field for one. A system cannot report what it has no concept of. The complete list of what does reach us is published on the metadata page. No XNS coordinator sits in the request path. Your Relayer talks to storage operators directly; retrievals do not route through us. Why not: there is nowhere for an access log to accumulate on our side. Who read what, when, and from where — the record that is frequently worth more than the files — is written on your host and stays there. Objects are erasure-coded 80+40 and dispersed across independent operators you selected. Each holds a fraction, and each fraction is already encrypted. Why not: no single operator holds enough shards to rebuild an object even in principle, and none of them holds a key in any case. Two independent barriers, not one. A legal order compels a party to produce what it has. What we have is an installation identifier, aggregate byte counts and performance measurements. Why not: this is not a claim that we would refuse — refusing is a policy and policies lose in court. It is that the response to a demand for your object contents or your file names would be the same either way, because the material does not exist on our side to produce. The interface is the S3 API. Your data comes out with rclone, the AWS CLI, or whatever you already use, and egress costs nothing. Why not: there is no proprietary protocol to strand you and no retrieval fee to make leaving expensive. A provider that charges for reads has a financial interest in you never testing the exit; we do not have that lever, which is why we can invite you to test it.We cannot read your objects
We cannot see your bucket names or object keys
We cannot watch your reads
Storage operators cannot reconstruct your data
We cannot hand over what we do not hold
We cannot lock you in
The other direction
A page listing only the flattering half of an architecture is marketing. Every item above has a consequence, and a buyer who finds them later rather than here will reasonably wonder what else was left out.
You operate the endpoint. The Relayer is a container on your infrastructure. That is what makes the list above true, and it is also a thing you have to run, patch and monitor. Production readiness sets out exactly which pieces are yours and which are ours.
Lost keys are lost data. There is no reset link for storage nobody else can read. Key custody is a real operational responsibility and it belongs to you.
We are not the AWS API in full. We publish every conformance test we run, including the ones we fail, on the compatibility matrix. Check the operations your software actually calls before you decide.
Every claim on this page points at something you can read or run. The telemetry list, the conformance matrix, the durability arithmetic and the responsibility split are all published, and none of them require a call with us first.