What Is A Distributed Cloud — And Why It Beats AWS And Google Cloud

🪩 The Disco Party is MATA's distributed cloud. This article is the definition; the Disco Party page is the party.

A distributed cloud is a peer-to-peer network where storage, compute, and identity live on the devices of the people using it — not in a data center owned by a single vendor. Every application that runs on a distributed cloud runs across many small machines that trust each other cryptographically, agree on shared data through convergent replication, and pay their contributors in whatever currency the network earns. There is no rented rack. There is no per-request egress bill. There is no one number to call when the whole thing goes down, because the whole thing does not sit in one place.

Centralized cloud — AWS, Google Cloud, Azure — solved the last generation of computing by consolidating everything into a small number of enormous data centers. The economics worked because renting a slice of one giant machine was cheaper than owning your own. Twenty years in, the trade-off has flipped: the fees are now the largest line item in a modern software business, the outages take out the internet on a bad Tuesday, and the same infrastructure that runs your app also carries every intelligence agency's warrant. The next generation of computing lives on the devices you already own.

This article walks through what a distributed cloud actually is, how the three parts fit together — identity, data, and compute — and how those parts compare to their centralized-cloud equivalents. If you want the shorter, party-themed version, jump to the Disco Party page. If you want the philosophical framing, What Is Digital Freedom covers it. If you want the technical foundation, The Importance of Remade with Rust is the pillar article underneath. Why this architecture cannot run C on a stranger's machine is why a distributed cloud needs memory-safe Rust.

What A Distributed Cloud Actually Is

At the smallest scale, a distributed cloud is a piece of software that runs on many machines and behaves — from the perspective of any single user or application — as though it were one system. What makes it distributed rather than centralized is where the machines are: on the desks and in the pockets of the people using the application, not in a rack somewhere in Virginia. Storage sits near the data owner. Compute happens where the user is. Identity is a keypair on the user's hardware, verified by whoever needs to check it without asking a broker for permission.

The mechanics come from three ideas that are individually decades old but only recently practical to combine. CRDTs (conflict-free replicated data types) let two machines that disagree about the state of a document eventually converge on the same answer without a coordinator. Content-addressed storage lets one machine ask another for a file by its cryptographic hash rather than by its owner's server address. Self-issued identity lets a person prove they are the same human across sessions without a login provider in the middle. Combine the three and you get an application that survives its author, its host, and any single company in the network.

The NIST Zero Trust Architecture guidance has been describing this posture from the security side for years: assume every device is its own trust boundary, encrypt everything, and share via cryptographic capabilities. A distributed cloud is what zero trust looks like as a product.

How A Distributed Cloud Works

Three pieces make the distributed cloud real. Identity travels with the user. Data lives near the people who own it. Compute and bandwidth come from the same devices already running the applications. Every piece has a working implementation in the memory-safe Rust stack MATA publishes at github.com/remade-with-rust, and every piece is designed so nobody needs a central data center to participate.

Identity Lives On The User's Device

The identity layer of the distributed cloud is a keypair the user generates on their own hardware, never on a server. Every subsequent action they take — logging into an app, signing a document, joining a peer group — is a cryptographic signature that anyone can verify with the public half of the key. There is no OAuth provider standing in the middle. There is no /token endpoint that could go down. There is no login log at a third-party service that turns into a warrant target.

In MATA's stack the pattern is called Sovereign ID, and its Rust-side verifier is mID — both on the Remade with Rust page. On hardware the same identity sits on the chip. Applications get a token that carries a stable identifier plus whatever claims the user chose to disclose, and the verifier confirms the token entirely in-process. No round trip to MATA. No JWKS URL to refresh. Compared to Auth0, Clerk, or Firebase Auth, the pattern is the same shape from the developer's side — one library call, one boolean back — and completely different underneath.

Data Lives Near The People Who Own It

The storage layer of a distributed cloud is a database that treats every user's device as a valid replica, agrees on shared state through CRDT convergence when devices meet on the network, and encrypts everything with keys the network operator cannot read. MATA's implementation is SpaceDB — a local-first, mesh-replicated database with per-field consistency tiers, capability-based access control, and built-in vector search that keeps the corpus on-device. Durability across homes is erasure coding; fetch-by-hash instead of a vendor URL is content-addressed storage.

That single choice is what makes a distributed cloud different from a distributed system that just happens to be big. Firebase, DynamoDB, and Cloud Firestore are distributed inside one vendor's boundary — the vendor is the coordinator. SpaceDB is distributed across the users' own devices. When those devices reconnect, they merge automatically; when they are offline, the app keeps working; when the vendor has an outage, no one notices, because there is no vendor on the path.

Compute And Bandwidth Come From The Network Itself

The compute layer of a distributed cloud is the pool of idle CPU cycles, storage capacity, and bandwidth that participants in the network donate — and get paid for — while they use the applications running on it. Devices that meet on a mesh through peer-to-peer transports like iroh hand data directly to each other; a laptop with room to spare becomes an edge server for its owner's photos and their friend's videos; a home computer with a spare thread runs someone else's OCR job on their weekend.

The pool grows as the network grows. That is the opposite of centralized cloud, where growth means the vendor buys more racks and passes the cost through to their customers. The distributed cloud pays its contributors from the same revenue streams centralized cloud vendors keep for themselves. Everyone who contributes shares in the upside. Read more in the Freedom Guide if you want to see the user-facing walkthrough.

Distributed Cloud vs Centralized Cloud

The point of the distributed cloud is not architectural purity. The point is that it changes the three variables — cost, privacy, resilience — that centralized cloud has been quietly losing on for years. This section walks through each.

Cost — No Per-MAU Fee, No Monthly Bill You Cannot Predict

Centralized cloud pricing is a metering business. You are billed per request, per gigabyte stored, per gigabyte egressed, per monthly active user of every service that touches identity, per API call, per authenticated hit. The pricing pages are opaque on purpose, and the bill scales faster than the product does. The Federal Trade Commission's ongoing work on cloud market concentration has documented the pattern: the meter is what turns a hosting relationship into a long-term liability.

Distributed cloud has no meter. Storage lives on hardware you already own. Compute happens on cycles the CPU was going to burn idle. Identity is a keypair, not a subscription. The one number in a distributed-cloud budget is the network's rev-share back to contributors — and for anyone contributing to the network, that number is negative in the good direction.

Privacy — Your Data Never Leaves Your Devices

Every piece of data a user creates in a centralized-cloud app makes a copy on someone else's disk. The provider's employees can be subpoenaed. Their logs can be breached. Their AI teams can decide to train on the corpus. The Electronic Frontier Foundation has spent a decade documenting how the cloud model turns "your data" into "our data" with a EULA change.

In a distributed cloud the copy stays on the user's own hardware. Sync between devices happens through end-to-end encryption keyed to the user, never in the clear. When the user grants access to another party, they grant a scoped capability — not a copy — that can be revoked. Nobody at MATA can read the vault. Nobody at anywhere-else can either.

Resilience — No Single Point Of Failure

Every centralized-cloud outage takes a slice of the internet down with it. The 2024 CrowdStrike incident, the recurring AWS us-east-1 flare-ups, the Google Cloud identity-service failures — the pattern is the same: one region, one control plane, one botched deploy, and everything on top goes dark. That is the trade-off you sign up for when you consolidate.

Distributed cloud has no control plane to fail. If a slice of the mesh goes offline, the rest keeps working; when the slice returns, CRDT convergence catches everything up. There is no central identity service to compromise, because identity lives on the user's device. There is no central database to breach, because there is no central database. The whole thing was designed by people who lived through enough of the outages to want their software to survive them.

The full engineering catalogue behind this — codecs, allocator, identity crates, and the database — lives on the Remade with Rust page. For field notes and follow-along commentary from MATA's founder as the stack builds out, Tim Almond's Medium posts alongside this site.