Where in IPFS stack should content-decider be applied

[olizilla]

We need to consider the ramifications of where in the IPFS stack we check CIDs against the content-decider.

Checking with the content-decider at the BlockService level would be a good starting point. Ideally we'd block at the DHT provider record level as well, but we need to asses the impact on the network. By not providing a block you essentially abstain from hosting it. To not signpost others to a provider for a block you start to impose your choices on others for better or worse...

• There should be no way for a node to provide a a block via bitswap whose CID is on it's blocklist... perhaps the most essential feature of a denylist is that it guarantees you will not send the bytes that map to a CID to any other node.
• There should be no way for a node to request a CID via bitwswap if it is on a denylist.
• It should a non-trivial exercise to store a block with a CID on a denylist in your repo. It's worth noting that there are multiple repo backends, and by default we don't reverify the stored blocks as they are fetched from it (see the go-ipfs config for hashOnRead) so it would be difficult for us to prevent the user from forcing blocks that are on a denylist into there own repo.
• We need some data on the ramifications of applying the denylist at the DHT level. The DHT is the mechanism by which we signpost others to which peers in the network can provide a given CID. At present the libp2p implementaton of kademlia has you ask the 20 peers with peerIDs most similar to the CID of the block you want for "who can provide this CID". If any peer has announced they can provide that CID, then we expect 1 or more of those 20 Peers to be able to tell us which peer can provide it. If those 20 peers refuse to signpost others to a given CID, then the global signposting mechanism is broken for all. This will be seen as a desirable property or censorship depending on the context... regardless we need to be clear on what degradation of service would likely be experienced.

[lanzafame]

This will be seen as a desirable property or censorship depending on the context... regardless we need to be clear on what degradation of service would likely be experienced.

I think this specification should be caveated with the statement that if we stuff this up, the anti-censorship properties of IPFS are destroyed.

As such my take is that the ‘impact radius’ of a content-decider should be limited to the node that is running that content-decider and no further.

//cc @ianjdarrow