Proposal: Content Addressed Package Management #83
Conversation
andrew
changed the title
| Describe any choices and uncertainty in this scope estimate. (E.g. Uncertainty in the scope until design work is complete, low uncertainty in execution thereafter.) | ||
| --> | ||
|
|
||
| - Large, 6-10 weeks |
There was a problem hiding this comment.
Do you have a clear enough picture of the steps involved in this to be able to give a rough indication of the relative sizes of what's listed in Brief plan of attack?
It also might be worth considering if there are 2 or 3 discrete sub-projects this could be split up into such that just doing one would provide value in itself while also serving as a way to justify further investigation.
mikeal
added
ease:low
| - Initial draft of data model and formats for spec | ||
| - Refactor core data model of https://github.com/forestpm/forest to implement draft spec | ||
| - Deploy analytics service for monitoring DHT for package usage | ||
| - Build and deploy marketing website for https://github.com/forestpm/forest and onboard early adopters |
There was a problem hiding this comment.
I agree this will be important. I foresee this project being 1/3 reference implementation, 1/3 creating the canonical interface/spec, and 1/3 knowledge sharing and prosthelytizing this amongst package managers users and developers to gain additional compatible implementations
|
|
||
| <!-- | ||
| Provide success criteria. These might include particular metrics, desired changes in the types of bug reports being filed, desired changes in qualitative user feedback (measured via surveys, etc), etc. | ||
| --> |
There was a problem hiding this comment.
I’d put the core “success metric” to be # of end users of content addressed package managers (ideally built on IPFS/libp2p/Filecoin using this spec)
There was a problem hiding this comment.
So as you say, number of users/stars/mentions of Forest and the content addressed package mgmt spec - and number of compatible implementations/tools/etc
|
|
||
| A documented set of basic standards for how to implement a content address package management system will enable new languages/communities to quickly produce reliable and secure implementations. | ||
|
|
||
| To enable this a specification for a protocol for content addressed package management would be written, along with a [working implementation](https://github.com/forestpm/forest), that outlines a standardized way for consumers, publishers and maintainers to share package management data that allows people to opt-in to various levels of decentralization without sacrificing existing usability, performance and security. |
There was a problem hiding this comment.
Can we rename Forest please? I honestly love the name, but it’s just too common (Ex, there’s already a Filecoin implementation named Forest by Chainsafe, and many other projects w the same name). Maybe “foraoise” (Forest in Gaelic? Or another translation?)
| A standardized package metadata format can enable the development of: | ||
| - a content addressable, public transparency log for all package managers, similar to the ]certificate transparency project](https://certificate.transparency.dev/) | ||
| - package maintainers could publish signed nfts of each release of their packages, enabling alternative sources of funding for open source | ||
|
|
There was a problem hiding this comment.
There is a concept forming around “public collections” that would likely apply both to public data like NFTs and Packages. Would love to see this work align with storing public record content addressed data in a fully resilient manner
| #### Dependencies/prerequisites | ||
| <!--List any other projects that are dependencies/prerequisites for this project that is being pitched.--> | ||
|
|
||
| - Whilst not directly dependent on, https://github.com/protocol/beyond-bitswap/pull/29 can help ease onboarding |
There was a problem hiding this comment.
I would love for us to push on this, I think it'll make the process of integrating with existing ecosystems substantially easier as well as help us in a variety of other use cases.
Rendered