In Q3, web3.storage was heads-down working on its expansion into a full-fledged developer platform:
We crafted our vision as a data platform that unlocks the data layer, built on top decentralized data and auth protocols to enable openness, verifiability, and portability, while still providing best-in-class performance and reliability
We launched improvements across our platform, including:
- The beta version of w3up, our new upload client and API that natively utilizes decentralized UCAN auth while solving a ton of pain points like memory-intensiveness and inefficiency when uploading large files
- w3ui, a headless, type-safe frontend component that takes advantage of w3up's usage of UCANs to allow you to copy and paste its code and immediately give your application the ability to upload files to IPFS and Filecoin without needing to set up your own backend server
- w3link, an IPFS HTTP gateway that gives any user with a web browser the ability to performantly read data off the IPFS network
- w3name, a client and API that provides mutability IPNS while eliminating the usual overhead associated with it
We transitioned to a paid product, no longer focused on just onboarding user data to the Filecoin network, but holistically on the needs of developers building the next generation of serverless, user-centric, and innovative applications, including introducing a Service Level Agreement
So, what's next?
We've only come this far because of the feedback of our users. Our Q4 priorities also reflect this continued dedication to improving the product based on what we've been hearing!
w3up in production
The w3up beta is ready for the big-time! In Q4, we will transparently migrate our current APIs to write to the w3up API on the backend. The existing client libraries and API will not feel any different - this is purely a back-end change. However, this will be a huge first step in migrating our existing platform over to w3up for uploads and storage.
In parallel, we'll be evolving the DID and key management system that w3up beta uses to be usable in the context of the web3.storage website and platform. For instance, currently a user creates a DID and registers it via the w3up CLI. However, we will break out these components into a standalone w3keyring library, and instrument a new login flow on top of this. Not only will this allow users to start interacting with their w3up account in the web3.storage website, but it opens up the door for future integration between w3up and other identity providers that utilize DIDs or private-public keypairs, from crypto wallets, web3 identity tools, and more traditional auth providers!
To bring w3up to production, there's a number of front-end components we need to create. However, since these all interact with DIDs and UCANs, we can build on top of w3ui to create w3console, which expands on the vision of w3ui to unlock not only uploads, but login, DID management, and more. We'll be dogfooding w3console ourselves in the web3.storage website to roll out w3up (allowing users to upload large files via the browser without worrying about client-side memory constraints), but w3console will also be useful for any developer looking to bring the full potential of w3up and decentralized auth to their users.
Improved w3link gateway performance and increased bandwidth
w3link is already the most performant IPFS HTTP gateway out there. However, it still doesn't quite meet the performance and reliability we or our users would like to see.
In Q4, we'll focus on making reads faster immediately after it was written to web3.storage. Currently, we generally go through external infrastructure to connect w3link to our hosted IPFS infrastructure, but we will make this link more direct, meaning you'll be able to reliably serve just-uploaded files using w3link.
Further, we'll also more generally bring more IPFS components to the edge to aim to provide unlimited and more consistently performant reads of your data through w3link! Right now, plans have a cap on bandwidth for data read from web3.storage, but this is because we currently pay for some egress from our hosted IPFS infrastructure. By bringing more of this infrastructure to the edge, we can aim to provide increased bandwidth through the gateway and serve your data stored with web3.storage more reliably.
Lower storage pricing
We rolled out pricing last quarter. This was often requested by our users, as many applications would rather pay for an SLA than trust an opaque, "free" model. And we were overwhelmed by the overall positivity from our users!
However, because of our plans to decrease our read bandwidth cost through w3link as well as other infrastructure cost optimizations, we aim to drastically lower pricing this quarter. We can't yet say what the exact amount will be, but we anticipate around $0.06-0.08 per GiB stored per month. This will be reflected in the tiered plans, so you should get far more bang for your buck with your tiered plan!
Next year, we will aim to move from subscription-based to consumption-based pricing. Currently, tiered pricing is determined by taking our variable costs and averaging them out across user behavior. Consumption-based pricing will allow us to charge users based on the services they consume, which will break out one-time costs (like the up-front cost of indexing the CIDs of blocks of data upon upload), ongoing costs (like storage costs on our different physical storage providers), and read costs (like if applications read from our IPFS peers hosted in places where we pay for egress). In tandem, we will allow users to choose where they want us to physically store their data. This will allow users to just hold copies of data in places where it makes the most sense - like just on the edge for fast reads, or just in Filecoin for free long-term storage, or some combination!
Thanks for your support!
In the year or so that we've been around, web3.storage has been able to provide some of the most reliable and easy to use IPFS hosting. However, thanks to feedback from our users, we've also been working hard to evolve into a platform that solves some of the largest pain points of all developers, not just existing IPFS users. This next quarter represents an opportunity to solve some of the remaining major pain points of our users as we solidify our platform, continuing to bring our potential to fruition.