[2021 Theme Proposal] Content Permissioning

[obo20]

Note, this is part of the 2021 IPFS project planning process - feel free to add other potential 2021 themes for the IPFS project by opening a new issue or discuss this proposed theme in the comments, especially other example workstreams that could fit under this theme for 2021. Please also review others’ proposed themes and leave feedback here!

Theme description

Right now IPFS nodes serve any content they have to any node in the network that asks. This creates privacy concerns, but also liability concerns. There needs to be a clean way for IPFS nodes to restrict who they provide content to at a granular level. Providing this type of capability bring IPFS much more in line with modern file storage solutions and increase attractiveness for both individual and enterprise users.

This is something that Pinata is asked about more than anything else (by a substantial margin)

Hypothesis

• Currently IPFS is restricted to usage by people who either:
  • Can have all of their data publicly accessible
  • Are using IPFS private networks where every participant can see all data within the private network
• The majority of people don't want their data to be available to everybody.
• Implementing content permissioning abilities would vastly increase the usefulness and adoption of IPFS in many key areas that previously would have avoided IPFS due to the lack of content permissioning.

Vision statement

In order for this theme to be successful, IPFS nodes need a way to determine whether or not to serve a piece of content based on a parameter provided with the initial content request. Given the broad scope of needs surrounding functionality like this, a generic extendable solution would likely be the best approach to provide this feature.

Why focus this year

More and more projects in the web3 space are recognizing the importance of privacy / permissioning and are building solutions to provide this. IPFS is such a crucial building block of the web3 ecosystem and I believe that having content permissioning as something IPFS can provide will be crucial to its adoption from both individual users and enterprise alike.

Example workstreams

A potential implementation example could be: Providing the ability to point to an API endpoint in the IPFS config that IPFS calls before serving any CID. IPFS would pass the endpoint two things:

• the CID being requested to serve
• any headers that were provided with the content request. These headers would need to be relayed from the original requesting node to the host node with the content (see https://www.npmjs.com/package/ipfs-http-client#custom-headers for an example of how these headers could be passed in initially).

It would be up to the node owner to figure out how to return "true" or "false" to this request. Such examples of how this would be decided:

• Were auth keys provided along with the request the give the requesting node the permission to retrieve this content?
• Do I as a node provider break any laws by serving this content? ([2021 Theme Proposal] Tools for node operators to configure what content they want to store/retrieve/provide #64)

There could potentially be "standardized" ways to respond to this that could even be baked into IPFS, but I do believe the ability to customize this logic is vital. This is why I suggested using an API endpoint (this is incredibly easy to implement and could be run either locally on the node's machine or externally).

The example above is a quick idea of how something like this could work, and is not intended to be represented as the "perfect solution" (I'm hoping others have ideas as well).

Other content

I believe that this theme proposal relates to #64 and #65 but wanted to separate it out into its own theme as I believe that it's more beneficial to think about these problems in a more generic manner (content permisisoning as a whole instead of privacy, security, or filtering).

[atopal]

Thanks for submitting this Matt! Do you think the Strong content filtering proposal covers the same issue, or do you think this should be a separate theme?

[jacobheun]

Thanks for submitting this Matt! Do you think the Strong content filtering proposal covers the same issue, or do you think this should be a separate theme?

I think this is more related to the OCAP/ACL discussion at #65 (comment). There is overlap of these 3 issues, but I agree with @obo20 that there's a benefit in this more concrete theme, and I think this can easily stand on its own. Permission to get/have content is much different than the desire/need to deny content (#64). #65 is a pretty wide scope and I think this and #64 are kind of sub themes under that.

[obo20]

@atopal , @jacobheun nailed it. I think all of these issues are related but could be solved with a holistic approach vs trying to tackle things individually.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.