Content Moderation on IPFS: What Actually Happens

Content moderation on IPFS runs into the same structural fact every article in this series has already established: content addressing decouples an address from any single host, which is exactly what makes IPFS resistant to link rot, and exactly what makes a takedown request behave completely differently than it does against a normal web server. This closes out the practical side of this series by covering, precisely, what a takedown actually accomplishes on IPFS, and what it structurally cannot.

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 actually 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 a Takedown Behaves Differently Here

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 a Pinning Service Can Actually Do

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 genuine, 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's actually addressable: 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 actually 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 actually 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, actually 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 actually 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 really 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 actually 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.

Related Reading

• Content Addressing vs. Location Addressing: Why IPFS Needs Pinning - the exact structural reason a takedown behaves differently here than against a normal server
• IPFS Garbage Collection: What Unpinning Actually Does - the real, scoped mechanism behind the one lever a pinning service actually has
• IPFS Private Networks: Swarm Keys Explained - the deployment model built for cases that need actual access control, a different problem than moderating public content
• How IPFS Finds and Retrieves Your Files: DHT Provider Records and Bitswap Explained - why any remaining host is enough to keep a CID discoverable

References

• Bad Bits Denylist
• Techdirt: Copyright As Harassment, the DMCA Attack On IPFS Gateways