<aside> ⚠️ This doc is in progress, and is not intended to be consumable by a mass audience. It’s the set of ideas that will seed future blog posts, etc.!


Miro with diagrams

At DAG House, we’ve been building services that allow developers and end users to easily utilize IPFS content addressing with their data:

This has allowed users to utilize content addressing in production use cases where it is the best solution without risking performance compromises often associated with peer-to-peer technology. As a result, you see many developers using NFT.Storage and web3.storage to take advantage of IPFS’s immutability guarantees. Much of this traction has been in the blockchain space (e.g., to store and reference off-chain NFT metadata and images), but this is just the tip of the iceberg of the benefits of content addressing when it is able to be performant and reliable.

Number of uploads to web3.storage platform.svg

Over 140M uploads to web3.storage + NFT.Storage (which runs on the web3.storage platform)

But making content addressing accessible and production-ready has only been the first step in our vision to bring web3 to the web. We’ve been working hard on executing on a vision, coupling IPFS with UCAN, a self-contained, verifiable authorization primitive that uses decentralized identifiers for identity, to transform web3.storage into a developer platform that allows apps to break out of siloed services. This improves efficiency, eliminates lock-in, and opens up a broader set of application architectures. By natively utilizing these open, cryptographically verifiable, and portable protocols, the platform allows:

  1. Apps and users to trustlessly interact with (download, link, reference) data as long as it’s available via IPFS simply by pointing to its content address - we call this data anywhere, which breaks down data silos, reconnecting the web and improving bandwidth efficiency
  2. Users, apps, services, etc. to utilize permissioned services (e.g., store data, run compute workloads) portably using their own identity - we call this the serverless bazaar, which allows users to take their workloads anywhere (i.e., can take the exact same request and trustlessly plug it in to any other service) with no intermediaries

By combining the ease-of-use of a developer platform with these verifiable, decentralized protocols, developers can start interacting with their “data layer” separately from their “infrastructure layer.” Developers can choose to store data or run workloads wherever it makes the most sense - with web3.storage, locally, with other cloud providers, in blockchains - without changing how they interact across these services. This makes the benefits of web3 tangible - it opens up the possibility of any application architecture, not just traditional ones, so you can pick what solves your users’ needs the best. It also limits vendor lock-in, forcing transparency and accountability in cloud services.

The Data Layer

We like to say that web3.storage helps unlock your “data layer.” What does this mean?

The Data Layer refers to data itself, independent of where it is physically stored. It is fluid and flexible, where any entity on the web - end-users, applications, infrastructure, organizations, and more - can interact with it (store it, read it, process it, send it, and more) without having to worry about whether the data they care about is controlled by someone else.

Overview of key protocols

We’ll get more into the technical details later, but for now, it’s useful to know that the Data Layer is fundamentally enabled by three decentralized protocols: