Back

Blog details

Content Moderation on IPFS: What a Takedown Can and Can't Do

AIOZ Network
5 min readSeptember 12, 2026
aioz-pin
AIOZ Pin header image with the headline Content Moderation on IPFS Explained

Content moderation on IPFS works per copy, not per address. A pinning service can unpin its copy and a gateway can refuse to serve a CID, but any other peer holding the file keeps it reachable. You can block access through your own infrastructure; you can't erase a CID network-wide.

TL;DR:

  • A pinning service or gateway operator can remove their own copy of a file and stop serving it through their own infrastructure. Neither of those actions removes the file from the IPFS network, since this series' content-addressing article already covers why the same CID can keep resolving through any other peer that still has it
  • The Bad Bits Denylist, maintained by Protocol Labs, is a real, concrete mechanism: a shared list of hashed CIDs that participating gateways can voluntarily check against and refuse to serve, opt-in, gateway-level, not network-level
  • This creates a documented, real-world problem: DMCA notices sent to gateway operators have targeted files that were never accessed through that gateway's traffic in the first place, since a notice sender often can't verify whether a specific gateway is even serving the content it's reporting
  • The IPFS Foundation and Protocol Labs' own Code of Conduct applies specifically to the public gateways they operate (ipfs.io, dweb.link), not to the IPFS network as a whole or to every gateway operator independently
  • On AIOZ Pin, the actionable lever a customer or the platform has is unpinning, covered in this series' garbage collection article, which removes AIOZ Pin's own commitment to host specific content; it does not, and structurally cannot, remove that content from every other peer that might also have it pinned

Why Does a Takedown Work Differently on IPFS?

A takedown notice against a normal web server works because the server is the address: remove the file from that one machine, and the URL stops resolving, full stop. This series' content-addressing article covers exactly why IPFS breaks that assumption: a CID is not a location, it's a description of content, and the same CID keeps working through any peer that independently has it. Removing one host's copy doesn't touch the address itself, only that one host's participation in serving it.

What Can a Pinning Service Do About a Takedown?

A pinning service, or any individual node operator, has real, concrete power over its own infrastructure: it can unpin a file, covered in this series' garbage collection article, and stop hosting it. It can also refuse to serve a request through its own gateway. Both of those are effective actions within that operator's own scope. Neither one reaches beyond it: unpinning removes one node's commitment to keep the content available, but has no effect on any other peer, anywhere, that independently pinned the same CID before or after.

The Bad Bits Denylist: A Real, Concrete Mechanism

This isn't a hypothetical gap papered over with vague claims about decentralization, there's a specific, documented tool built to address it at the layer where it can be addressed: the Bad Bits Denylist, maintained by Protocol Labs, a shared list of hashed CIDs flagged for reasons like copyright violation or malware. Gateway operators and pinning services can voluntarily check requests against this list and refuse to serve anything on it. It's explicitly opt-in and gateway-level: adopting the denylist blocks access through participating gateways, and does not remove the underlying content from the IPFS network, the same structural limit covered above, just formalized into a real, usable tool rather than left as an abstract problem.

The Real-World Problem This Creates

The gap between "block at the gateway" and "remove from the network" has caused documented, concrete friction. Gateway operators have reported receiving DMCA takedown notices covering thousands of URLs where the vast majority were never requested through that gateway's own traffic logs, meaning the notice sender had no real way to confirm the gateway was serving the content at all before demanding it stop. This is a direct consequence of content addressing's own design: a CID being valid and resolvable in principle says nothing about whether any specific gateway operator has ever served it, which makes a blanket, unverified takedown request structurally different, and structurally harder to act on precisely, than one aimed at a single web server hosting a known file.

Whose Rules Apply Where

It's worth being precise about scope here too: the IPFS Foundation and Protocol Labs' own Code of Conduct, and the Bad Bits process behind it, applies specifically to the public gateways they operate directly, ipfs.io and dweb.link. It does not automatically bind every gateway operator or pinning service on the network, each of those makes its own independent decision about whether to adopt a denylist, run their own moderation process, or do neither. There is no single governing body with the power to enforce a takedown across every participant in the network at once, which is a direct structural consequence of the same decentralized design this entire series has been describing.

Where This Fits AIOZ Pin

The lever AIOZ Pin, or any customer using it, has is the same one covered throughout this series: unpinning content removes AIOZ Pin's own hosting commitment to it. That's a real, effective action within AIOZ Pin's own infrastructure, consistent with how any pinning service's moderation capability works, not a special exception. What it does not do, and what no pinning service anywhere can honestly claim to do, is remove content from the broader IPFS network if other peers independently hold it. Anyone evaluating a pinning service's moderation posture is asking about that service's own policies for what it will and won't host, not about a network-wide removal capability that doesn't exist for any provider.

Frequently Asked Questions

Can a pinning service remove content from IPFS entirely? No. It can unpin content and stop hosting its own copy, and it can refuse to serve requests through its own gateway. Neither action removes the content from other peers that independently hold it.

What is the Bad Bits Denylist? A shared list of hashed CIDs maintained by Protocol Labs, flagged for reasons like copyright violation or malware, that gateway operators can voluntarily check requests against and refuse to serve. It's opt-in and gateway-level.

Does unpinning content on AIOZ Pin remove it from the whole network? No. It removes AIOZ Pin's own hosting commitment for that content. If any other peer has independently pinned the same CID, it remains available through them.

Why have gateway operators received DMCA notices for content they never served? Because a CID being technically valid doesn't mean a specific gateway has ever served it. Some takedown processes have targeted URLs without verifying they appeared in that gateway's own traffic logs first.

Does the IPFS Foundation's Code of Conduct apply to every IPFS gateway? No. It applies specifically to the public gateways Protocol Labs and the IPFS Foundation operate directly. Other gateway and pinning service operators set their own independent policies.

Is there a way to remove content from IPFS network-wide? Not through any single action. Content addressing means the same CID resolves through any peer that has it, and no central authority can unilaterally revoke that across every independent node on the network.

References

We only send updates when meaningful changes ship, and you can unsubscribe anytime

Related Content

blog thumbnail

IPFS Dedicated Gateway Free vs Paid Plans on AIOZ Pin

An IPFS dedicated gateway on AIOZ Pin is called a premium gateway. See what the free plan limits, what a paid plan adds, and what happens at zero balance.

6 min readOctober 28, 2026
blog thumbnail

Pin by CID on IPFS Without Re-Uploading Your Files

Pin by CID asks a pinning service to fetch content already on IPFS and keep it. Covers the AIOZ Pin pinByHash call, statuses, and why a pin stalls on Pinning.

6 min readOctober 26, 2026
blog thumbnail

IPFS Gateway Not Working? Diagnose It in This Order

IPFS gateway not working? Read the status code first, then check the CID, your request rate, and whether anyone is providing the content. Here is the order.

6 min readOctober 23, 2026
blog thumbnail

ERC-1155 Metadata on IPFS: The ID Substitution Rule

ERC-1155 metadata on IPFS breaks when filenames ignore the {id} rule. Here is the exact 64-character format, a working folder layout, and the per-token option.

6 min readOctober 21, 2026
blog thumbnail

AIOZ Pin Rate Limits: API, Public, and Premium Gateways

AIOZ Pin rate limits in one place: 180 requests per minute for the API, 15 per CID on the public gateway, and no predefined limit on premium gateways.

6 min readOctober 19, 2026
blog thumbnail

IPFS Pin Stuck on Pinning? What Each Pin Status Means

IPFS pin stuck on Pinning? Here is what Pinning, Pinned, and Failed mean on AIOZ Pin, why big directories can sit there, and how to read a pin's real state.

6 min readOctober 16, 2026