This post focuses on outlines the vision of web3.storage. The state of the post reflects where the product will be in Q4 2022. For instance, we are currently in Beta of our new upload API that natively uses UCAN for auth, and will have this incorporated in the web3.storage client and website the coming weeks. In the meantime, some of what is outlined in this blog post might not yet be incorporated into the core web3.storage and NFT.Storage products.

Click here to read Part 1 or Part 2 of our introduction to the web3.storage platform!

So far, we’ve covered a ton, and depending on your background, there might be a lot of new information to take in! The good news is, regardless of what kind of developer you are, you can benefit from the Data Layer. It might be helpful to zoom out and see what utilizing the Data Layer via web3.storage might look like in practice.

The Data Layer in practice with web3.storage

  • The Data Layer can be interacted with independently of the specific places data itself is stored and processed. We call this “Data, Anywhere.”

    • But by using IPFS and UCAN together, you can construct applications or run workloads that are trustless, user-focused, more serverless, less siloed, and more

  • In one version of the world, a business (say, an NFT minting service) can have a web3.storage account and delegate permissions to users

    • For instance, they can register their DID with NFT.Storage and have users register with their website with w3ui components, generating a DID for each of these users
    • They can then delegate permission to users via UCAN to upload directly to NFT.Storage on their behalf

  • In another version of the world, users can each have web3.storage accounts and delegate permission to a Dropbox-like business to read the data in their account

    • The business might use w3ui to design a sign up console that generates a DID for its users and a web3.storage account for the user (where they put in their credit card info, etc.)
    • The user can then install the Dropbox-like app that has its own specific DID per install, and allocate permission via UCAN to upload to and read data out of the web3.storage account
    • With w3ui, you’d be able to just copy and paste the code of the module into the application frontend, and have it plug into your user’s identity provider
    • This makes it natural for apps to be able to compete with each other based on who best satisfies the users’ needs, rather than who gates their users in through data silos or other means

  • Developers and users can (and should) still have opinions on what infrastructure should support their workloads, but they are no longer locked-in and can construct applications that are far more user-focused

    • Users can choose whatever service provider meets their needs with no fear

    • For instance, since w3up uses Elastic IPFS and is run by the team that made it, you might choose it for your hosted storage provider for performance reasons

    • However, if you ever get unhappy, you can easily switch to any other storage provider that uses the same UCAN authentication and IPFS - even if you adopted other tools like w3ui, you can just switch the service you’re pointing to (so no painful rearchitecture of your application)

    • With each actor in the system able to have its own DID, and data and workloads able to be verifiable, things can look very similar to a blockchain without the global consensus layer. We call this the “Serverless Bazaar.”

      • Verifiable proofs can be generated locally or across service boundaries. Actors in the network can verify each other (leveraging what IPFS, UCAN, and Filecoin bring to the table) - for instance, users can verify proofs generated by w3query if they want to and move to a different service if the proof is invalid
      • Interactions across actors can become creative (e.g., multiple users with credit card numbers associated with their accounts can funding a web3.storage account’s storage balance)

    Imagine an ecosystem of interoperable widgets that all speak UCANs and CIDs that can delegate permission across users, applications, cloud services (not just web3.storage’s), and more!

    One important thing to note is that we still enable any existing application infrastructure. But once the data layer is unlocked, the way you can build your app is only limited by your creativity!

    Eating our dogfood

    Internally, the web3.storage platform eats its own dogfood. For instance, we actually utilize existing multiple cloud infrastructure providers across our microservices architecture, but instrument APIs that speak IPFS and UCAN on top of them so our workloads are open, verifiable, and portable. And all actors within our systems - from users, accounts, infra endpoints, and more, have their own DID.

    This way, we can lean into efficiencies. AWS cheap for compute but expensive for egress? Cloudflare has free egress but not as good in terms of compute solutions? Filecoin has ~free, verifiable storage, but slow reads? We can run workloads wherever minimizes cost with the same verifiable guarantees! And we can then productize this - charge users by operation and storage cost, and let them select where they want their data to exist or workloads to run. In practice, this will mean that we will be able to offer the least expensive storage offering, given Filecoin’s negative storage pricing.

    Next up: Calling all builders

    In this post, we discussed at a high level what using the web3.storage might unlock in practice. In the next post, we will discuss what’s next for web3.storage and what you might build to take advantage of it - roadmap and potential use cases!