Gateways and moderation
The protocol serves everything. A gateway chooses. Why those are different, and what it means for you.
ABX FS is two things, and conflating them produces wrong expectations in both directions.
The protocol is contracts on a public blockchain. Anyone can write bytes. Nothing is owned, reviewed, or removable — not by us, not by anyone, not with a court order. That is not a policy; it is what the contracts do.
A gateway is any service that reads the protocol and serves it over HTTP. fs.abx.io is one. It is operated by people, and it decides what it shows.
What this means for you
Your content cannot be taken down. Once published, it is addressable by its hash forever. Run your own gateway, or point someone at an RPC endpoint, and it resolves.
It can be declined. fs.abx.io will stop serving content that violates its
content policy — phishing, malware, CSAM, and a short list of
similar things. You would see 451 Unavailable For Legal Reasons, which is exactly what it
means: the content exists, and that gateway is choosing not to serve it. Where the browser supports it, that
response also tells it to drop its cached copy and any stored data for that project's address, so a
returning visitor does not keep seeing what was declined (best effort: it needs a secure context and a
browser that implements Clear-Site-Data).
It is not promoted. fs.abx.io lists only the orgs and projects of your connected wallet. There is no directory of everyone else's. Your project is reachable by link, by CID, and by anyone reading the chain — it is simply not something this website puts in front of strangers. An org page works by direct link only, and is not indexed.
Both of those are true at once. If durability matters to you, do not rely on any single gateway, including ours.
Reading it yourself
Nothing about a gateway is privileged. It is an HTTP wrapper around eth_call, and you can
skip it entirely:
abxfs read 0x<root> --path index.html -o index.htmlThat reads the bytes from contract storage (the contract checks every chunk against its record) and writes the
file.
No gateway is involved, and none can be: the chain does not know what a gateway is. The same
reads are available through @abxfs/sdk if you are building something
that serves them over HTTP.
If you disagree with what fs.abx.io serves, that is the answer — not a protocol change.
What gets declined
fs.abx.io can decline three things: a project (chain, org and token id), an org, and a root CID. A request is refused if any of the three it names is declined, so a project under a declined org is refused too, and so is a project that republishes a declined root. Each project is served from its own address on a separate content domain, so a declined project is declined at that address and nothing else on fs.abx.io is affected. Names are never a subject — an org's name is self-declared and copyable, so only its address counts.
Reporting content on fs.abx.io
Email legal@artblocks.io with the URL. Every project page has a Report link that opens a prefilled message. Copyright claims and legal process go to the same address.
Reports are about one website. They do not reach the chain, and nothing about the protocol changes as a result of one.