Skip to content

Commit d989466

Browse files
authored
Merge pull request #62 from protocol/alanshaw/nft-storage-for-nfthack
Proposal: nft.storage for NFTHack
2 parents 0c48561 + ed8e7b7 commit d989466

File tree

1 file changed

+187
-0
lines changed

1 file changed

+187
-0
lines changed
Lines changed: 187 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,187 @@
1+
# `nft.storage` for [NFTHack](https://nfthack.ethglobal.co/)
2+
3+
Authors: [@alanshaw](https://github.com/alanshaw)
4+
5+
Initial PR: https://github.com/protocol/web3-dev-team/pull/62
6+
7+
<!--
8+
This template is for a proposal/brief/pitch for a significant project to be undertaken by a Web3 Dev project team.
9+
The goal of project proposals is to help us decide which work to take on, which things are more valuable than other things.
10+
-->
11+
<!--
12+
A proposal should contain enough detail for others to understand how this project contributes to our team’s mission of product-market fit
13+
for our unified stack of protocols, what is included in scope of the project, where to get started if a project team were to take this on,
14+
and any other information relevant for prioritizing this project against others.
15+
It does not need to describe the work in much detail. Most technical design and planning would take place after a proposal is adopted.
16+
Good project scope aims for ~3-5 engineers for 1-3 months (though feel free to suggest larger-scoped projects anyway).
17+
Projects do not include regular day-to-day maintenance and improvement work, e.g. on testing, tooling, validation, code clarity, refactors for future capability, etc.
18+
-->
19+
<!--
20+
For ease of discussion in PRs, consider breaking lines after every sentence or long phrase.
21+
-->
22+
23+
This is a proposal for time limited storage of NFT data on IPFS, backed by Filecoin and provided **free** to NFTHack participants during the hackathon (March 19 2021).
24+
25+
* Register `nft.storage` (or other cool domain name) and expose a [pinning service API](https://blog.ipfs.io/2021-02-19-go-ipfs-0-8-0/#remote-pinning-services).
26+
27+
This will either be a proxy to [Pinata](https://pinata.cloud/) (or other pinning service) or use PL's own [pinbot](https://twitter.com/ipfspin).
28+
29+
This gives us space to experiment. Data storage and retrieval is de-risked by the service we pin the data to. It affords us a playground with "_real_" data that we can store on Filecoin.
30+
31+
Here's some of the AWESOME things we could build and deploy in this space:
32+
33+
* Create a library that automatically makes deals on Filecoin for the pinned data (use/adapt the dealbot?). This is mentioned in the [AWS Facade proposal](https://github.com/protocol/web3-dev-team/pull/34) and could be re-used there.
34+
35+
* Implement a [deal batching service](https://github.com/protocol/web3-dev-team/pull/60) prototype for increased successful deal probability.
36+
37+
* Run a "[Free Retrieval via IPFS](https://github.com/protocol/web3-dev-team/pull/52) Lotus node" that `nft.storage` can make deals with and that will expose the NFT data to IPFS.
38+
39+
* Build and run a "[Retrieval from Filecoin](https://github.com/protocol/web3-dev-team/pull/57) IPFS node" that will allow NFT data we store in deals to be pulled directly from Filecoin and available via IPFS.
40+
41+
* Create a single page website at `nft.storage` explaining how to use the service with registration for API keys.
42+
43+
* Implement the [remote pinning service in js-ipfs](https://github.com/protocol/web3-dev-team/pull/58) so that it can be used in web based NFT hacks.
44+
45+
If this is not ready on time, folks can always use the Pinata API directly. Obviously, for non-web based hacks users can run a go-ipfs node, configured to use `nft.storage` as their remote pinning service.
46+
47+
Essentially, everything after building a simple pinning service API and website is a bonus and won't effect QoS for NFTHack participants negatively.
48+
49+
It gives us purpose, a (albeit soft) deadline and a safe area for building out and deploying project proposals _in production_ that directly address PMF issues like deal flow and Filecoin ↔️ IPFS interop.
50+
51+
As an added bonus, we'll be dogfooding our own tech and ideas for greater understanding and appreciation of any difficulties. It also will help to validate assumptions made in our project proposals.
52+
53+
## Purpose &amp; impact
54+
#### Background &amp; intent
55+
_Describe the desired state of the world after this project? Why does that matter?_
56+
<!--
57+
Outline the status quo, including any relevant context on the problem you’re seeing that this project should solve. Wherever possible, include pains or problems that you’ve seen users experience to help motivate why solving this problem works towards top-line objectives.
58+
-->
59+
60+
A remote pinning service API and a simple website for information and registration will exist for use by NFTHack participants to store NFT data for free for a limited time.
61+
62+
This will cement IPFS as the primary means of off-chain NFT storage and will raise awareness of Filecoin as a storage provider.
63+
64+
Currently a lot of NFT data is stored on IPFS with no clear story for permenance. Leveraging the remote pinning service API and providing guarantees of availability for the duration of the hack will prompt developers building NFT related software to think about permenance and who provides it. It will present Filecoin as an option for consideration and will likely drive some traffic to pinning services like Pinata.
65+
66+
#### Assumptions &amp; hypotheses
67+
_What must be true for this project to matter?_
68+
<!--(bullet list)-->
69+
70+
* NFT users want to store NFT data on IPFS.
71+
* NFT users want guarantees of data availability.
72+
* NFT platforms care about their end users being able to take control of their data.
73+
* e.g. An artist would be able to retrieve their data even if X app went away tomorrow.
74+
75+
#### User workflow example
76+
_How would a developer or user use this new capability?_
77+
<!--(short paragraph)-->
78+
79+
* Register an API token on `nft.storage`.
80+
* Run IPFS with remote pinning service configured as `nft.storage`.
81+
* Pin data to IPFS node: it is stored for e.g. 1 year on `nft.storage`.
82+
83+
#### Impact
84+
_How would this directly contribute to web3 dev stack product-market fit?_
85+
86+
<!--
87+
Explain how this addresses known challenges or opportunities.
88+
What awesome potential impact/outcomes/results will we see if we nail this project?
89+
-->
90+
91+
* This primarily exposes and builds on the status quo of using IPFS to store NFT data. It roughly equates to advertising for IPFS and Filecoin
92+
* Secondarily, it gives us purpose, a (albeit soft) deadline and a safe area for building out and deploying project proposals _in production_ that directly address PMF issues like deal flow and Filecoin ↔️ IPFS interop.
93+
94+
#### Leverage
95+
_How much would nailing this project improve our knowledge and ability to execute future projects?_
96+
97+
<!--
98+
Explain the opportunity or leverage point for our subsequent velocity/impact (e.g. by speeding up development, enabling more contributors, etc)
99+
-->
100+
101+
We may see an uptick in the number of developers working with NFTs that use IPFS for storage.
102+
103+
The component part of actually storing the NFT data on Filecoin has invaluable potential to inform us on real world usage of the API's involved with making a deal. It should enable us to more confidently build solutions knowing they are the right thing to build.
104+
105+
One other potential future for this project is to extend its lifetime so that we continue to receive NFT data for storage, this would allow us to measure our ability to make deals on the Filecoin network over time and make optimizations for the size and structure of NFT data.
106+
107+
#### Confidence
108+
_How sure are we that this impact would be realized? Label from [this scale](https://medium.com/@nimay/inside-product-introduction-to-feature-priority-using-ice-impact-confidence-ease-and-gist-5180434e5b15)_.
109+
110+
<!--Explain why this rating-->
111+
112+
Med-Low
113+
114+
We do not know if any NFTHack participants will even use the service.
115+
116+
## Project definition
117+
#### Brief plan of attack
118+
119+
<!--Briefly describe the milestones/steps/work needed for this project-->
120+
121+
See overview at top of page.
122+
123+
#### What does done look like?
124+
_What specific deliverables should completed to consider this project done?_
125+
126+
* A remote pinning API is available at `nft.storage` that pins to the chosen pinning service.
127+
* It exposes a feed of pinned CIDs (to be used for persisting NFT data to Filecoin).
128+
* A service runs that consumes the pinned CIDs and attempts to store them on Filecoin.
129+
* A beautiful and engaging website exists.
130+
* Has information on how to configure go-ipfs/js-ipfs to use `nft.storage` as the remote pinning service.
131+
* Has functionality for registration, login and API key generation.
132+
* Draws attention to data being backed by Filecoin.
133+
* Explicitly outlines period for free storage and other rules.
134+
135+
#### What does success look like?
136+
_Success means impact. How will we know we did the right thing?_
137+
138+
<!--
139+
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.
140+
-->
141+
142+
* \>25% of NFTHack participants use the service for persisting their NFT data.
143+
* \>50% of NFT data submitted during the hackathon is also stored on Filecoin.
144+
* Increased adoption of the remote pinning API in developer applications.
145+
146+
#### Counterpoints &amp; pre-mortem
147+
_Why might this project be lower impact than expected? How could this project fail to complete, or fail to be successful?_
148+
149+
There is not a lot of time before the hackathon 😬.
150+
151+
#### Alternatives
152+
_How might this project’s intent be realized in other ways (other than this project proposal)? What other potential solutions can address the same need?_
153+
154+
#### Dependencies/prerequisites
155+
<!--List any other projects that are dependencies/prerequisites for this project that is being pitched.-->
156+
157+
#### Future opportunities
158+
<!--What future projects/opportunities could this project enable?-->
159+
160+
* Extend it as a paid for service and gift it to a pinning service to run/maintain?
161+
* Add community funding to keep a CID alive. Any member of the community can chose to contribute to the hosting cost for a given CID, and you can see how many years it has on clock.
162+
163+
## Required resources
164+
165+
#### Effort estimate
166+
<!--T-shirt size rating of the size of the project. If the project might require external collaborators/teams, please note in the roles/skills section below).
167+
For a team of 3-5 people with the appropriate skills:
168+
- Small, 1-2 weeks
169+
- Medium, 3-5 weeks
170+
- Large, 6-10 weeks
171+
- XLarge, >10 weeks
172+
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.)
173+
-->
174+
175+
Medium
176+
177+
#### Roles / skills needed
178+
<!--Describe the knowledge/skill-sets and team that are needed for this project (e.g. PM, docs, protocol or library expertise, design expertise, etc.). If this project could be externalized to the community or a team outside PL's direct employment, please note that here.-->
179+
180+
* Frontend Engineer
181+
* Go Engineer x2
182+
* Web Designer
183+
184+
Resource from other w3dt teams to implement project proposals described above:
185+
186+
* Sudo
187+
* Datasystems

0 commit comments

Comments
 (0)