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:
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).
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
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:
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:
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).