What is this
Meet the ecosystem-raised need for a denylist standard and turn-key support to enable services to deal with DMCA, abuse like phishing, and other takedown requests.
What we need to do
This requires golden path work across the stack:
- âś…Â finishing spec work on denylist format (IPIP-383)
- âś…Â upstreaming reference implementation, making it turn-key, to unblock ecosystem to start building lists in userland
- porting nopfs plugin to boxo/kubo
- minimal UX support in kubo that allows gateway operators to implement mechanism responsible for updating denylist in userland (details)
- documentation – an artifact to be a go-to resource we can send to people interesting in content filtering
Why?
- Cloudflare rolled an in-house blocking solution, including Kubo patches for denylists. They also proposed a JSON-based format for sharing lists, which went over various iterations
- IPIP 298: (allow|deny)lists for IPFS Nodes and Gateways (superseded byIPIP-383)
- kubo: IPFS filtering to allow node operators to decide on content they are willing to serve
- Unconf workshop during IPFS Camp 2022 (Cloudflare, IPFS Search)
- Lacking a list format that ecosystem can standardize around
- Public lists won’t appear without ubiquitous support is the most common implementations
- Public Gateways run by third parties struggle
- Receiving DMCA takedowns (including fake ones) which requires special handling due to the lack of standard solution.
- Phishing campaigns require fast response and would benefit from ability to subscribe to denylist. Gateways risk not only being overloaded by report / takedown requetss, but also risk reputation and may get blocked by browsers like Google Chrome.
- Bifrost Team
- Proposed IPIP-383: compact denylist format to supersede IPIP-298
- https://badbits.dwebops.pub switched to the format from IPIP-383
- Blogpost and Kubo plugin NOpfs
- Bedrock(?) raised the need too 2023-05-02 Content Routing WG #10 - Content Blocking in IPFS Gateways
