Uploading data onchain shouldn’t be any more difficult than using Google Drive. The reason tools like Google Drive are popular is because they just work and are cheap/free. Their hidden downsides? You don’t own your data, it’s not permanent, and – especially for blockchain projects – it’s not useful for application developers.
Users just want to put their data somewhere and forget about the upkeep. Developers just want a permanent reference to their data that resolves in any environment. Whichever you are, we built cloud.load.network for you.
The Load Network Cloud is an all-in-one tool to interact with various Load Network storage interfaces and pipelines: one UI, one API key, various integrations, with web2 UX.
The Rationale
Since we started Load Network, we’ve had the vision of an onchain data center – a decentralized network of high performance, cost effectiveness, high-liveness, fault tolerance, low latency and fast finalization, data-centric features and availability.
Building a cloud platform, similar to Google Cloud Platform, means abstracting the robust infrastructure of the (onchain) data center into a single UI, providing a smooth – as straightforward as using Google Cloud Platform to interface with their several services, that are built on top of their robust infrastructure of data centers and what comes along it.
In today’s web3 world, too many teams relies on third-party hosted-IPFS pinning services (e.g. pinata, nft.storage), AWS S3 object storage and its alternatives (Google Cloud Bucket, etc), and other centralized data storage solutions – they are compromising the decentralization and liveness needed for permanent apps for ephemeral unsustainable short-term solutions.
Other teams are already using battle-tested web3 native solutions such as Arweave and Filecoin, however these protocols lack the unification of a single cloud platform that lets developers use them like they’d use AWS S3. This creates engineering overhead for teams to integrate with web3 native solutions, keeping web3 devs in the web2 trap. We’re solving this with the Load Cloud.
Introducing Load Network Cloud Platform: Going Onchain
As a response to the lack of web3 storage solution abstraction and interoperability with the web2 standard interfaces, we have worked on the Load Cloud, a one stop solution to use existing data storage standards, without compromising the core features of web3 data storage provided by Load Network.
Version 1: IPFS + Load Network + Arweave
TL;DR: uploading a file to cloud.load.network returns a permanently pinned IPFS CID and a load0 hash resolvable on both IPFS and load0.network.
We are releasing the first version of LNCP with support of IPFS pinning service, user registration and API keys generation – this will allow you to use IPFS, as same as you would with existing pinning service, however with a single big differentiator, all of the data will be permanently stored on Load Network while maintaining the IPFS API interface.
Version 1 of the Load Cloud provides an interface to sign in with your email to generate a Load Network wallet, create API keys to access Load storage, and upload files to both Load Network and IPFS (permanently pinned).
Coming in the next version of Load Cloud
The next release (very soon) will introduce two new protocols, AWS S3 API and a Dropbox-like service – both will interface with Load storage under the hood while always maintaining parity with the original API specification.
The vision? Imagine using the official AWS S3 SDK, just switching the config URL and API key to interface with Load Network storage while using the same architecture of S3’s object-bucket storage?
This is zero engineering integration overhead, any team using S3 storage for critical data storage (e.g. NFT media, metadata) can switch to Load’s permanent high-throughput data with a simple config switch – a win for abstraction and web3 integrity.
Try version one here.