dag.house aims to equip developers and end-users with the superpowers of content addressed and decentralized storage via IPFS and Filecoin while bringing the ease-of-use and performance that they might be used to. The goal is to grow the number of quality applications, tools, and services using IPFS and Filecoin for storage and increasing the volume of data stored on the networks (via more engaged and growing numbers of users), and help them be viewed as the default storage option for Web3 use cases.

Overview

As paradigms shift to Web3, there is a ton of whitespace for developers to build transformative products that can help fix the broken parts of using the Internet. In a world using decentralized storage, we’ll quickly see strong network effects as the public content-addressed data graph grows.

However, mass adoption cannot occur without meeting and outperforming on dimensions that developers and end-users consider table stakes with regards to storage - ease-of-use, reliability, performance, cost, transparency, flexibility, among other things. One illustration of this is in the NFT space: as long as we see NFTs minted referencing centralized URLs because decentralized storage is too confusing and slow to use, how can we expect deeper and more sophisticated applications and use cases to pop up?

The wave is coming and we want to build services and tools that ignite new developer ecosystems and end-user verticals by taking the current, ultimately temporary, friction out of web3 DX (you or your users don’t need to run your own infrastructure! you can store and retrieve data large or small! storage and retrieval is fast enough! etc.) all by taking advantage of the PL Stack and other Web3 superpowers (content addressing! decentralized identity! provable storage! user control over data!).

When building these services and tools, we need to strike a balance - designing interfaces and systems such that provide great experiences to our users today even in areas that are most important where there are current shortcomings of our stack, while positioning ourselves to take advantage of future upgrades (e.g., FVM, fast Filecoin storage/retrieval, retrieval markets).

As more users onboard into Web3, we also need to jumpstart new standards to truly achieve its vision. If we leave users even with the best intentions to their own devices, anti-patterns will still emerge (e.g. HTTP URLs in Solana NFTs).

Product theses

In the first 6 months of our products, we’ve learned a ton that we want to carry over into our evolution. Some examples include:

• The vast majority of users need the reliability and performance that they’re used to from production Web2 storage systems. This is their first-order concern, generally far more pressing than using 100% decentralized infrastructure
  • At the same time, if they choose to use IPFS, they (rightfully) expect all the decentralized pieces to interoperate (e.g., pin data from their local node to Web3.Storage, access data uploaded to NFT.Storage from any gateway)
  • Further, it’s fine to be a centralized onboarding ramp for data to get onto IPFS since CIDs are trustless (especially for the sake of speed and reliability), but we should decentralize persistence where we can (e.g., automated renewal of deals)
  • However, we can’t become too attached to our solutions in this regard. We should never make decisions that prevent us from taking advantage of more decentralized alternatives in the present / future
• Even if we can reach table stakes parity, we need to meet users where they are today (e.g., HTTP) before any mass transition to more Web3-native solutions.
  • Simultaneously, we have to push the transition to being Web3-native. For instance, we’d prefer if NFTs have ipfs:// URLs in them (in Solana, HTTP is enforced for metadata URLs!)
  • We shouldn’t see decentralized protocols and HTTP as dualistic, exclusive or otherwise in conflict. By adopting decentralized protocols over an HTTP transport we jumpstart the usage and further development of the underlying protocols. We can accelerate the adoption and development of IPNS, UCANN, and other protocols in this way.
• Developers, end-users, and folks in between will all be interacting deeply with our service. This is only partially attributable to lack of great tooling in the ecosystem (e.g., NFT artists creating NFT.Storage accounts because no good tools exist for the types of drops they want to do). In many cases, there is a shift towards empowering users to have self-sovereignty over their data, only now emerging as a desire because it has only now possible to decompose the user’s storage layer from the application.
• Web3 applications, even dApps, will continue to need centralized backends even as decentralized compute and storage layers improve. The good ones are mindful about what parts of the application to run on smart contracts or locally by users to maintain trustlessness. Beyond just CIDs, we need to support these trustless interactions between centralized and decentralized entities (e.g., utilizing identity tools like UCAN and wallet auth)
• NFTs will be a backbone to Web3 beyond just art, so we need to make sure that NFT.Storage nails this use case. However, for NFTs to reach their potential to fully decentralize ownership of digital assets, their persistence needs to be treated as a public good to eliminate issues around misaligned incentives
• NFTs represent just one set of patterns and needs (e.g., permanent storage), and as more use cases gain traction, we need to generalize our products and their features to meet these varying needs
• If we take on any sort of infrastructure effort, we need to think through the implications on how folks will use them (and in some cases, potentially be ready to run it forever - e.g., gateway.nft.storage will likely be used in NFT URLs despite our best efforts to deter this)

These learnings help give clarity on the right high-level direction to take our products:

NFT.Storage

• NFT.Storage should drive making NFT persistence free and forever, though we need to decentralize their continued persistence
  • In the short-term, this also means ensuring that no data loss can occur
  • We also should support our ecosystem partners persisting NFTs on their services forever (e.g., Pinata) - rising tide!
  • Example work: FVM smart contracts for automated renewal, Data DAOs to fund continued persistence, niftysave (both the centralized effort today and a future version that’s done by smart contracts)