Designing applications around bucket-based storage has been fundamental for developers and the applications we are so used to using on a daily basis. Initially, we have had Amazon Web Services offering their Storage solution also known as S3 since 2006. It was clear this was going to change the way we thought about our applications, why? Simply because now we are able to offload the responsibility of keeping media-type data in our servers.
Alternatively, there have been new offerings made available, such as Google Cloud Storage or Azure Storage by Microsoft. All of these, essentially accomplish the same thing: Allocating data in data centers, removing the responsibility from the developer itself and making sure this data is accessible and distributed for low latency.
S3 as a protocol
With the growth and benefits of S3, it was extraofficially adopted as a protocol, meaning, developers started creating compatible wrappers with S3 where you could still use the SDKs available. Today, most cloud providers are S3 compatible where with a one-line change in your SDK code, you can switch providers in your app.
Load, the S3 permanent provider
Load Network has been working nonstop in making permanent storage feel relatable and achievable for existing applications. Today, we are excited to announce that the Load Network storage layer is now compatible with S3 SDKs.
By using the s3.load.rs S3 compatible endpoint, developers are able to connect to the S3 bridge of Load, bringing the following benefits:
- Permanent Buckets
- Permanent Object Storage
- Data ownership and portability
- Censorship resistance & data access through globally distributed 270+ Arweave gateways
If your app contains data that can ideally be stored permanently, this solution bridges S3 and permanency with no extra effort.
Get an API key
Go to cloud.load.network and sign up with your email address to create an account. Once inside, a default API key will populate in the API Keys tab, and you can create any number of secondary keys inside the UI.
Feature parity in version 0
The S3 standard in web3 – examples
A worrying amount of web3 infrastructure relies on AWS. Nodes, indexers, RPCs, proofs – for an industry built on decentralization, centralized offchain services handle more than we’d like to admit. We aren’t looking to replace AWS for VMs, but can offer a serious alternative to S3 for permanent storage.
Since decentralized storage is expensive and IPFS is unreliable, many teams building digital assets and onchain RWAs fallback onto what they used in their web2 days. S3 storage hosts a huge amount of NFTs that have left holders with 404s in their wallets.
Cost and reliability aside, we see the issue as one of developer experience. The usage patterns, syntax, integration and ease of use of S3 has embedded itself across every industry, even those allergic to centralization.
This is also reflected in systems like BNB Greenfield. Greenfield’s storage provider spec matches S3 1:1, to make it easy for network participants to spin up a new S3 instance and join without changing configs.
This is proof that the structures S3 uses has gained dominance in both web2 and web3, and it’s this that prompted us to build a fully S3-compatible storage layer that uses Load Network and Arweave for permanence. This erases the #1 problem with S3: data disappears when you stop paying bills. For Load, it’s pay once store forever.
What’s on the roadmap
- The next major upgrade is full feature parity. In the next coming months we will be working not only on integrating more endpoints belonging to the S3 protocol, but also, implementing more functionality that is accessed through certain headers, parameters, etc, making sure that every S3 endpoint is fully compatible with Load.
- Adding more regions to our S3 service and hot cache, to lower the latency of permanent storage worldwide.
- Fine-grained access tokens, to give users the power to limit access to Load S3 features within their org.