NFT.Storage Q1'22 roadmap and beyond

Storage of off-chain NFT assets is a tricky thing. There are some key requirements: the storage needs to be content-addressed and multi-generational at the very least. Ideally, it’s on decentralized storage so as the NFT gets bought and sold, the risk that the off-chain data is lost is minimal. These are all table stakes things that anyone minting or buying an NFT should double check.

However, there’s a lot more that we can demand out of our NFT storage services to make them useful for everyone that directly or indirectly relies on them - everyone from tooling developers (minting APIs, marketplaces, wallets, block explorers, galleries...), to the artists and others who make the NFTs, to the collectors and users of NFTs.

We hear this call! As an NFT storage provider, we can’t just be providing the minimum. We need to provide NFT data quickly without services needing to run their own own caching layer. We need to make it easy for non-developers to upload 10K metadata and images for their drops. We need to support decentralized authorization primitives allowing services to enable users to upload on their behalf, and vice versa. And the list goes on!

Our goal as NFT.Storage is to provide a delightful user experience to raise the bar for what users expect out of the NFT and Web3 space. In this post, we detail a number of the key things we’ll be working on in Q1 2022, as well as what’s planned for the rest of the year. Our roadmap is always subject to change as the space continues to develop and we learn more, but we hope this gives some insight into how we plan on supporting our users and the entire ecosystem.

Q1 roadmap

In Q1, we plan on landing the following features and tools.

NFT.Storage Gateway

Let’s face it - performance is key to make any web experience a good one. In the span of two decades years, we’ve gone from being OK with waiting 20 seconds for a static webpage to load to getting impatient when there’s a moment of buffering a 4K video. But NFT tools and services often face a choice of whether to sacrifice performance and use decentralized storage as their primary off-chain NFT storage, or go with a centralized storage solution as their primary storage medium. Well-funded players who care a lot about the Web3 ethos might use decentralized storage while running their own centralized caching, but this is too much trouble in practice for most.

It’s true that retrieval from decentralized storage networks can be less performant in practice - these networks are quickly improving but still young. But we believe you don’t have to make compromises with your storage service for the sake of performance! We are releasing an HTTP service called the NFT.Storage Gateway that aims to provide a lightning fast experience for retrieving NFTs that were stored with NFT.Storage. It functions like other IPFS HTTP gateways, but is optimized retrieving for content on NFT.Storage through intelligent caching of data stored with NFT.Storage (along with a CDN). And like any other IPFS gateway, you don’t need to trust our infrastructure to take advantage of decentralized storage, since you’re accessing data via its CID, a unique fingerprint for the data. Of course, the same CIDs are being made available over IPFS both from pinned nodes and from Filecoin - meaning you can always still grab the data in all the other usual ways.

We believe that unlocking fast retrieval of NFTs at the storage service layer will enable amazing user experiences for any tooling player, big or small, without them needing to make compromises around the way they’re storing their NFT data. We hope to release the NFT.Storage Gateway to the public in mid-February, and will continue to improve and optimize its performance after launch.

UCAN authorization

Currently, NFT.Storage requires a private token for users to upload to the service. This is a standard web pattern. However, because there are no scopes to these private tokens, users have to be careful about who has access to their token. This means that if you’re an application that wants their users to upload to NFT.Storage, you either have to run a backend that funnels user uploads to NFT.Storage, or get your users to make their own NFT.Storage account (which can be a clunky user flow). In the worst cases, we’ve seen folks put their private tokens in their application front-ends.

For a while we were thinking we’d just implement scoped tokens, but this is Web3, and we can do better! One of Web3’s superpowers is that identity is often viewed as a primitive across applications and end-users. After some research, we landed on implementing Fission’s UCAN decentralized identity primitive to allow applications to authorize their end-users to upload on their behalf. This should make it way easier for applications like minting services to have their users upload to NFT.Storage without them needing to make their own account.

But that’s not all we’re planning on doing with UCAN! There’s other cool things in store - for instance, we’re thinking about how UCANs can interact with mutable NFTs to grant permission on who can mutate an NFT. In a future post, we’ll share a live roadmap of what we’re hoping to be able to do with UCAN - both for our team, and for other teams who think certain features would be valuable and can want to contribute. You can read more details about UCAN here - think Google OAuth, but decentralized (so anyone with identity can grant permissions to anyone else).

We hope to release this first version of UCAN in late February, and will continue do more cool things with UCAN moving forward.

Improved large upload UX

NFT.Storage is able to take uploads of up to 31GiB and persist them for the long haul on the IPFS and Filecoin networks. However, getting data this large onto the service isn’t always easy, as even technically savvy users have found out. In the most common upload flow, the user needs to convert their file or folder into a CAR file and upload the CAR file into chunks (which gives you the CID of your content before you upload, and allows for things like parallel or pausing / resuming uploads). This is done automatically for you if you use the Javascript client library, or if you use libraries like ipfs-car with carbites to upload via the API directly.

However, conversion into a CAR file can be memory intensive - usually at least 2x of the file size ends up in your memory at some point. This is also why folks have issues uploading large files or folders via the website, because browsers usually have stricter memory constraints than the computer they’re on!

One of the next frontiers of NFTs are large NFTs, with high res art, videos, and gaming NFTs starting to explode. We’re revisiting how we do large uploads to enable these use cases, like looking at alternative ways to generate CAR files that aren’t so memory-intensive. That way, folks can fully take advantage of NFT.Storage’s large data upload limits (which stem from Filecoin’s ability to store large files for cheap/free) and easily store files up to 31GiB.

In parallel, we’re also creating a no-code app that allows users to upload large directories and files to NFT.Storage without needing to rely on their browser or CLI, starting with a focus on enabling uploads for 10K NFT drops! We’re hoping this enables artists to take full advantage of content-addressed, decentralized storage.

We hope to release this no-code app in late February, and have an overall improved large upload system by the end of Q1.

Niftysave Ethereum and niftystats

We’ve mentioned this before, but something we’ve been doing for a while now is watching Ethereum’s mainnet and storing NFT metadata and assets we index from the chain on NFT.Storage - an effort we’ve been calling “niftysave.” Regardless of how NFTs were minted, we want all NFTs to be content addressed and safe in long-term storage.

As we store off-chain data from Ethereum NFTs into NFT.Storage, we will publish a simple IPLD data structure that maps NFT addresses to metadata and asset CIDs and continue to update it, so regardless of how an NFT was minted, it can be directly referencing the intended content. In addition, we use the data from this effort to make statements about the state of the health of NFTs (called “niftystats”) - like what percentage are content addressed, or how many are “lost” (with the NFT data no longer retrievable).

We hope to launch niftystats by late February, and make the mapping of NFTs to CIDs public by the end of Q1.

Plans for the rest of 2022

We have a lot more in store for 2022! Here are some more things to get excited about:

• Automated deal renewal using FVM: When the Filecoin Virtual Machine launches, we will set up smart contracts to automatically renew Filecoin storage deals containing NFT.Storage data, setting up the foundations for fully decentralized long-term storage of NFTs.
• NFT.Storage DAO: In parallel with automated deal renewal, we plan on creating a DAO that funds renewal of deals. Verified storage deals on the Filecoin network are free today (and likely will for a long time, with block rewards able to subsidize work on crypto networks for many years), but for when this stops being the case, the NFT.Storage DAO will contain funds to pay for the renewal of deals (which will still likely be cheap given the amount of storage on the Filecoin network - 15+ EiB at the moment!).
• Wallet authorization: Currently, NFT.Storage users sign in using their email address or Github account. We will support the ability to sign in and fully interact with the service using crypto wallets, using or alongside what we’re doing with UCAN to create an even more powerful decentralized authentication story.
• Expanding niftysave: We’ve been making sure to make the niftysave system not just work for Ethereum, but easily apply it to other chains. This year, we hope to tackle 3-5 more chains!
• NFT.Storage w3name: We’ve implemented IPNS in our sister project, Web3.Storage, called w3name. This allows you to create mutable references that point to different CIDs over time. This feature is still in its experimental stage, but as it matures, we will bring it over to NFT.Storage, which will allow for things like mutable NFTs!
• Uploads > 31GiB: In terms of size limits for individual uploads, the only thing that prevents larger than 31GiB uploads is that Filecoin deal sector sizes are generally 32GiB. But because of IPFS magic, we can split larger uploads into < 32GiB chunks before uploading to Filecoin, unlocking even larger uploads!
• Off-the-shelf integration with web frameworks: An awesome thing about the NFT movement is that a ton of new folks are getting into web development. For developers both new and seasoned, dependency management in web dev can be really annoying, and there are tons of questions on our Discord and Github about dependency errors. Many of the solutions are easy and are teaching moments for new devs, but there are also tougher issues to get around when new versions of packages and frameworks are released. We want to get better at preemptively testing and giving instructions on integrating with common web frameworks to help reduce friction for users.

We want to grow with you

As someone in the NFT space, you see the rapid evolution of the industry first-hand. We’ve been listening closely to users’ needs to come up with the list above, but we also want to keep in touch as you continue to learn more and grow as well! Pop into the #nft-storage channel on IPFS Discord or drop an issue on Github to let us know what you’re excited about from this post, what you think is missing, and how things are changing for you over time. We’re can’t wait to see what’s next for you, and hope to be the partner you need in this journey.