Proposal: nft.storage for NFTHack

[alanshaw]

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.

Rendered

[ribasushi]

Looks great!
Probably a few devils will be in the details, but that's to be hashed out during design.

[lidel]

This proposal is fully packed! Provides clear onboarding path for NFT developers that:

• use CIDs identifiers for addressing assets
• leverage IPFS for hot storage and data retrieval
• provides a demonstration how Filecoin-backed pinning service could look like
• promotes future-proof api with no vendor-lock in:
  • makes pinning services api the standard for long term persistence
  • developers can switch from nft.storage to Pinata or something else without changing anything in their code (!)

• current feature gaps like adding pin.remote commands to js-ipfs are solved as implementation detail of this proposal.

[jnthnvctr]

Super crucial! I think right now a lot of our collabs (e.g Foundation) are looking to us to have well designed solutions that they can drop into - and are looking to us to define how these things shoudl work. Being able to experiment here would be super valuable!

[jnthnvctr]

I think this is going to be super important as more folks like Textile/Fleek are enabling IPFS -> Filecoin services. Having a reference implementation would be powerful.

One note - we should apply for DataCap with Andrew ( through https://plus.fil.org so we can be set up to make deals if we need to well in advance!)

[jnthnvctr]

Perhaps related to the next two bullet points, but should we consider also trying to get an MVP service for "CID/Deal querying"?

I think one pattern that has emerged with NFTs is we have these end users (you or me) who use an app like foundation who will manage the storage of data as a blackbox-> but we run into the "if X was hit by a bus, do I lose my data".

One answer to that ( which I think @rvagg touched on for his batching proposal) - was potentially exposing the CID/Deal info so a user could grab that externally (and take over retrieval and payment) - is it worth trying to also prototype something lightweight here?

[alanshaw]

I think one pattern that has emerged with NFTs is we have these end users (you or me) who use an app like foundation who will manage the storage of data as a blackbox-> but we run into the "if X was hit by a bus, do I lose my data".

I'm not sure I understand what X is in this context. The storage provider? I would assume that the remote pinning service is doing it's best not to lose my data. Just like I assume Dropbox is doing their best to not lose my data. Perhaps this means multiple redundant copies are stored on Filecoin and I can see value in a library what negotiates deals to achieve this (RAID for Filecoin, except D - Disk is instead Deal 😉).

In IPFS this problem is alleviated a little - anyone that has ever accessed your CID will become a host for it (until they next GC) and can pin it themselves to keep the content alive on the network forever. So even if you only pin to a single provider that gets hit by a bus then there's a chance you'll still be able to get your content from someone else in the network.

One answer to that ( which I think @rvagg touched on for his batching proposal) - was potentially exposing the CID/Deal info so a user could grab that externally (and take over retrieval and payment) - is it worth trying to also prototype something lightweight here?

So, you'll have the CID of the content immediately. I don't think that it would be possible to take over the deal but you could negotiate a deal yourself with a different miner for the same content.

Assuming the content is currently retrievable, there's nothing stopping you from pinning it yourself to a backup pinning service or your own IPFS node.

In the remote pinning service API you can query the status of a pinned CID. I think it would be a good idea to enhance that response to include details of the Filecoin deal it is currently backed up in so that it can still be retrieved even if the pinning service went away.

[jnthnvctr]

+1000

[mikeal]

This is a fantastic proposal 😍

[olizilla]

I love it! I would add the work we did on cube as a reference... having a UI where any and all members 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, would be rad. The first n years could be covered automagically.

[momack2]

I think we should proxy to Pinata. I don't want the ecosystem to feel like we're creating a tool that eats someone else's business and reduces their ability to serve users in the ecosystem