Join GitHub today
Implement Allow Lists and Block Lists #284
Also known as whitelists, blacklists, blocklists, deny lists, etc.
For many reasons, it's important for people operating IPFS nodes to have the option of specifying which content they will, or won't, provide to the network. It's been requested and discussed many times since the inception of IPFS. This basic feature brings up a whole domain of important opportunities and risks, but the requirements for an initial implementation are relatively simple.
Related threads on discuss.ipfs.io:
I think that (how to share those lists) should be out of scope. The whole purpose of IPFS is to make it easy to pass around data. allow/block lists are just datasets. The missing piece is the ability to have your nodes automatically apply or respect those lists.
I agree that in the long run people will want/need a whole social and technical infrastructure for passing these datasets around, but I think it should be handled as a separate longer-term design exercise with many, many factors in the mix.
Is there a good place to discuss the larger vision, ethics, and mission, and how specific features contribute to, or detract from those? Is there a repo somewhere? This issue concerns me because it opens the door to censorship, whether voluntary, geographic, business, political, or governmental.
This is probably the best place to discuss it.
Unless otherwise specified, the nodes will still interact. It's just that some of them will not download certain content.
This is a concern but someone is probably going to archive it anyways (if it has some historical, cultural, or political significance), even if they don't distribute it.
Twitter is a centralized service so it's not really a good example when discussing IPFS. Any decentralized twitter replacement wouldn't be able to forbid mirrors. Really, "mirror" implies that there is a canonical "original". In a decentralized service, there are no "mirrors".
A hash list is a good place to start but you are correct, it won't stand up to a sufficiently motivated individual. Really, with encryption and steganography, nothing will. Over time, some governments/organizations will likely mandate filters that look at the content itself.
We already get DMCA takedown notices against our gateways. One can get "deniability" with, e.g., the freenet approach however, that will likely get IPFS banned in many places (and deniability may or may not be an effective legal argument). An alternative approach is to use IPFS with tor. While we don't currently support or recommend it (we haven't done an audit and there are probably innumerable ways to deanonymize nodes), there is a tor transport for IPFS.
For companies, they'll likely do what they do today: hire lawyers. In this respect, IPFS is no different than other internet technologies.
End users will also what they do today: obey the laws in their current legal jurisdiction or work around them using anonymizing/privacy/circumvention technologies.
The goal here isn't to achieve consensus. The goal is to provide users with a tool that allows them to deal with their current legal realities. Not blocking certain content in certain jurisdictions could get you fined, arrested, or killed.
Adding to an allow list would be more convenient if was recursive by default, as you probably don't mean "i shall allow just this specific block of metadata", and probably mean, this dataset / this directory, this whole file.
Adding a CID to a deny list would possibly need to be specific, and non-recursive by default, otherwise bad-bits could deny users the ability to host other legitmate content that happened to include an identical block somehere in the graph (you dont want to block jquery because a malicious site uses it), and to discover the full graph would require you to find all the bad-bits.
What this might look like:
# Allow bafyb123 and all blocks in the graph $ ipfs allow bafyb123 $ ipfs allow ls bafyb123 (recursive) # Do not host bafyb123 specifically. $ ipfs deny bafyb123 $ ipfs deny ls bafyb123
There will be occasions where you want to be very sure not to host any of the content, but that should be a list of directly named blocks. We could provide a recursive flag, but you'd probably want to ensure that we only check currently stored blocks rather than asking the network for them in order to block them.
Perhaps you should be able to create allow list entries when you add a file, and deny list entries as you delete blocks
WRT "allow lists", go-ipfs now has a