<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.!

</aside>

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:

• We built easy-to-use clients in NFT.Storage and web3.storage for web developers to make data available on IPFS and stored on Filecoin in two lines of Javascript
• We wrote Elastic IPFS, our own open source, cloud-native implementation of IPFS built for scalability to give our users faster and more reliable data uploads and storage (99.9% decrease in 5xx errors to uploads, 99th% highest upload time from 1-10 min to <10s)
• We created IPFS HTTP gateway infrastructure that takes advantage of IPFS’s natural affinity for caching, which has resulted in ~10x faster reads of data available on IPFS

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.

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:

• IPFS: Ability to reference data using a unique identifier specific to that data (a “content identifier,” or CID). The Data Layer references everything using IPFS CIDs.
  • Any actor on the web can address the specific piece of data they are intending to using the CID, a cryptographic hash of the data.
  • They can read the data independent of where it physically is as long as it’s on the network (from cloud and decentralized storage, to peers in the network, to locally).
  • Data can internally reference other CIDs, creating “pointers” to other data that roll up into the overall CID without needing the data itself (a complementary protocol called IPLD).
• DID: A cryptographic identifier. The types of DID we use allow the holder to prove they have control over that identity without a centralized source of truth. Every actor that needs an identity and is interacting with the Data Layer should have a DID.