From f330bb63800210c5b20969309849626ff3e1d0f0 Mon Sep 17 00:00:00 2001 From: Alan Shaw Date: Mon, 28 Jun 2021 09:56:56 +0100 Subject: [PATCH 1/3] mpp: nft.storage client side content addressing --- ....storage-client-side-content-addressing.md | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 proposals/nft.storage-client-side-content-addressing.md diff --git a/proposals/nft.storage-client-side-content-addressing.md b/proposals/nft.storage-client-side-content-addressing.md new file mode 100644 index 00000000..934dfe8e --- /dev/null +++ b/proposals/nft.storage-client-side-content-addressing.md @@ -0,0 +1,52 @@ +# NFT.storage - client side content addressing + +Authors: @olizilla @vasco + + + + + +## What is the problem this project solves? +_Describe the status quo, including any relevant context on the problem you're seeing that this project should solve. Who is the user you're solving for, and why do they care about this problem? Wherever possible, include pain points or problems that you've seen users experience to help motivate why solving this problem works towards top-line objectives._ + +Concurrent upload of NFT content and on-chain minting. In order to mint an NFT, creators typically need to link the token to the content by some URI. The URI must include a CID but currently NFT.storage only provides a CID _after_ content has been uploaded. This change will allow creators to generate a CID prior to uploading their content, enabling them to perform the upload and minting of their NFT concurrently. + +The CID can also be used with the NFT.storage "check API" to see if it is necessary to upload the data at all. + +Generating CIDs on the client side is also beneficial in a decentralized future where the client does not need to trust the service is generating a _correct_ CID for their content. + +## Impact +_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_ + +## The idea +_Describe the proposed project solution, at a very high level. Stay at the level of the high-level requirements. Diagrams and interface descriptions can be useful, if you have any that help clarify and explain the idea._ + +- 📡 **Update API and clients to allow a user to upload CARs.** CAR creation will be handled a separate tool... either [ipfs-car](https://github.com/vasco-santos/ipfs-car) or similar. +- 📄 **Create an explainer on how to create a car file either in the browser or server-side** that OpenSea can adopt, and switch to posting CARs so they can locally derive the CID for the asset, set it in their metadata and post the CAR to NFT.storage and guarantee that the CID they generated is the same as the one used to store the asset + - See: [car.ipfs.io](https://car.ipfs.io) + - See: [github.com/vasco-santos/ipfs-car](https://github.com/vasco-santos/ipfs-car) +- 🚫 **We won't focus on splitting large uploads across multiple car files yet.** It is detailed in [this proposal](https://github.com/protocol/web3-dev-team/blob/main/proposals/nft.storage-chunked-car-uploads.md). +- ⏩ Nice to have, once that's all in place, we'll look at making metadata creation something that can all be done client side as well, as part of the general direction of decentralising nft.storage. We've figured out a good pattern for creating nft metadata, now you can use it without relying on our infra kind of thing + +## Success/acceptance criteria (optional) +_How do we know we're done with this project? How do we know we're successful? This field is OPTIONAL for the first draft of an MPP. Sometimes this field needs to be filled out once we have more detail on the shape of the actual solution._ + +## Detailed plans (optional) +_Link to more detailed project plans, e.g. product requirements documents (PRDs) and technical design docs, once they have been created for this project._ + +## Program (optional) +_If this project is part of a program, please indicate the relevant program here._ From ec3d865cb7515839f6e45c28144ee19607a35b9b Mon Sep 17 00:00:00 2001 From: Alan Shaw Date: Mon, 28 Jun 2021 10:01:19 +0100 Subject: [PATCH 2/3] refactor: reword --- .../nft.storage-client-side-content-addressing.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/nft.storage-client-side-content-addressing.md b/proposals/nft.storage-client-side-content-addressing.md index 934dfe8e..8f70206e 100644 --- a/proposals/nft.storage-client-side-content-addressing.md +++ b/proposals/nft.storage-client-side-content-addressing.md @@ -23,15 +23,17 @@ For ease of discussion in PRs, consider breaking lines after every sentence or l ## What is the problem this project solves? _Describe the status quo, including any relevant context on the problem you're seeing that this project should solve. Who is the user you're solving for, and why do they care about this problem? Wherever possible, include pain points or problems that you've seen users experience to help motivate why solving this problem works towards top-line objectives._ -Concurrent upload of NFT content and on-chain minting. In order to mint an NFT, creators typically need to link the token to the content by some URI. The URI must include a CID but currently NFT.storage only provides a CID _after_ content has been uploaded. This change will allow creators to generate a CID prior to uploading their content, enabling them to perform the upload and minting of their NFT concurrently. +**Concurrent upload of NFT content and on-chain minting.** In order to mint an NFT, creators typically need to link to the content by some URI, and that URI is stored on-chain during the minting process. The URI must include a CID but currently NFT.storage only provides a CID _after_ content has been uploaded. This slows downs the process of minting an NFT, especially for large NFTs. + +## Impact +_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_ + +This change will allow creators to generate a CID prior to uploading their content, enabling them to perform the upload and minting of their NFT concurrently to speed up the process. The CID can also be used with the NFT.storage "check API" to see if it is necessary to upload the data at all. Generating CIDs on the client side is also beneficial in a decentralized future where the client does not need to trust the service is generating a _correct_ CID for their content. -## Impact -_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_ - ## The idea _Describe the proposed project solution, at a very high level. Stay at the level of the high-level requirements. Diagrams and interface descriptions can be useful, if you have any that help clarify and explain the idea._ From f00ea0214c6a4e474af377052cef48d6649493b9 Mon Sep 17 00:00:00 2001 From: Alan Shaw Date: Mon, 28 Jun 2021 10:03:12 +0100 Subject: [PATCH 3/3] docs: add links to authors --- proposals/nft.storage-client-side-content-addressing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/nft.storage-client-side-content-addressing.md b/proposals/nft.storage-client-side-content-addressing.md index 8f70206e..10a834fb 100644 --- a/proposals/nft.storage-client-side-content-addressing.md +++ b/proposals/nft.storage-client-side-content-addressing.md @@ -1,6 +1,6 @@ # NFT.storage - client side content addressing -Authors: @olizilla @vasco +Authors: [@olizilla](https://github.com/olizilla) [@vasco](https://github.com/vasco-santos)