Table Of ContentsWhat is the long-term vision for NFT.Storage?How long will data be stored on NFT.Storage?Are there any size restrictions for stored NFTs?Where can I learn more about NFT best practices?Who can access the data I store on NFT.Storage?Can I delete my data on NFT.Storage?I tried using an HTTP gateway to retrieve my content from IPFS but am receiving an HTTP error. Does this mean my content was not stored successfully on NFT.Storage?How is NFT.Storage free to use?Is there a limit on numbers of files in a directory?Why am I seeing: SyntaxError: Unexpected token '.'Why am I seeing: SyntaxError: Cannot use import statement outside a moduleWhy don't you support versions of Node prior to v14?Upload metadata with existing image url?
NFT.Storage helps NFT developers today who are looking for easy APIs and best practices for storing their NFT data securely and resiliently. Even in the short-term, it is a trustless and decentralized solution. Users are able to cryptographically verify that the content identifiers that the service provides corresponds to their data, and that this data is hosted in multiple ways across the IPFS and Filecoin networks (allowing for accessibility across the network and preventing lock-in, with users also able to pin their data elsewhere to increase redundance).
Though we believe that there will always be value in some form of the libraries and services NFT.Storage provides, in the long-term the goal is to increasingly decentralize NFT.Storage. This includes relying more directly on the Filecoin network as the protocol continues to evolve. Some examples include storing data directly on the Filecoin network without putting it on a centralized IPFS node first and building oracles + DAOs + bridges to ensure n copies of data on the network (as Filecoin continues to evolve). We also want to make it easy for users to deploy and run their own NFT.Storage storage service. This, and other exciting things on the horizon, will help upgrade today's NFT.Storage implementation into the provably permanent storage solutions of tomorrow.
Data will be available in IPFS indefinitely as well as stored in long-term, redundant Filecoin storage deals with the global community of miners. See the Terms of Service for details.
NFT.Storage can store NFTs up to 31GiB in size! (There was previously a 100MB limit due to Cloudflare workers but NFT.Storage now supports chunked uploads, allowing files bigger than 100MB to be uploaded! 🎉)
Visit NFT School for information on NFT best practices as well as a variety of helpful tutorials and how-to guides for NFT developers.
All data uploaded to NFT.Storage is available to anyone who requests it using the correct CID. Do not store any private or sensitive information in an unencrypted form using NFT.Storage.
You can delete data from being associated with your account, and it will no longer appear on the Files page of your account. However, this doesn’t prevent nodes in the IPFS decentralized storage network from retaining copies of the data indefinitely. Do not use NFT.Storage for data that may need to be permanently deleted in the future.
#I tried using an HTTP gateway to retrieve my content from IPFS but am receiving an HTTP error. Does this mean my content was not stored successfully on NFT.Storage?
Not necessarily! HTTP gateways are a great way for users who aren't running their own IPFS nodes to retrieve content from the IPFS network. However, they do introduce a centralized point of failure to a user flow. If a given gateway is down, or is under too much load, or is facing other issues, users who are accessing content through that gateway might be unable to access content. In this case, we recommend trying another gateway or running and using your own IPFS node.
Additionally, if the data was not stored on NFT.Storage, then there might be issues with the IPFS node(s) with a copy of the data providing that data to the gateway. Using NFT.Storage makes sure that the content stored is broadcasted to the network using best practices!
Filecoin storage providers commit their hard drive capacity to the Filecoin network, and earn significant block rewards for doing so. This translates into real-world profits for storage providers, which incentivizes them to continue committing additional hard disk space to the Filecoin network. However, when storage providers are storing data from Filecoin users, their likelihood of winning block rewards goes up by a big factor 一 10x! Because NFT.Storage participates in the Filecoin Plus program, all data uploaded through the service is eligible for this 10x reward multiplier. This is such a powerful incentive for Filecoin storage providers to store user data that they tend to be willing to offer free storage and retrieval services in order to get this block reward multiple. As a result, most storage providers offer free storage and retrieval on Filecoin today and will continue to do so as long as block rewards continue to be a powerful incentive. This should be true for a very long time 一 for example, it is still the case that block rewards are powerful incentives for Bitcoin miners today. While there is some additional infrastructure cost associated with running the NFT.Storage service, Protocol Labs is committed to maintaining this infrastructure indefinitely as part of our mission to grow the decentralized storage ecosystem and preserve humanity's information for future generations.
It depends. If you're using
storeDirectory from the JS library (i.e. sending a multipart HTTP request) then the request will be limited by 100MB so you'll only be able to send as many files as can fit in that limit. This will be fixed in the future (see here). If you have lots of tiny tiny files, then you may end up causing the IPFS node to create a directory that is bigger than the maximum block size that libp2p is willing to transfer (although it's not clear if that is even possible within the 100MB request limit). This could happen because go-ipfs doesn't currently shard directories (but this is planned by default for v0.11). If you use the
storeCar method from the JS library (i.e. sending multiple split CAR files) then it should be effectively unlimited if you use
ipfs-car to create the CAR file since
ipfs-car uses the default
shardSplitThreshold: 1000 from unixfs-importer meaning the directory node likely won't grow beyond the 1MiB block limit.
Try updating to Node version 14 or later. This error can occur because of having an old version of Node. We no longer offer support for Node versions prior to v14 (see here). With Node v14 or greater, you should be able to use
import if you are using ESM Modules, otherwise you will need to use
We generally try to steer people away from linking to specific HTTP gateways, since they can be a single point of failure and may go down or disappear some point. If your heart is set on using HTTP URLs, I'd say your best bet is to create the metadata json manually and store it using
storeBlob. There's an example app called minty that creates metadata like this, which might help demonstrate. Minty stores IPFS URIs in the metadata, but it could easily be modified to store gateway URLs instead.