Web3 loves to repeat the tidy slogan: Web 1.0 let you read, Web 2.0 let you write, Web3 lets you own (hat tip to Chris Dixon). It’s punchy—but after a decade of experiments, ask yourself a simple question: what do you actually own today? If you’re honest, the answer is not data. It’s tokens—a pile of financial abstractions that were supposed to represent something meaningful, but rarely did.
The core problem of Web 2.0 has always been data: who controls it, who can access it, and who extracts the value created by it. Read and write are just verbs. The noun is data. Web3 mostly ignored that. Instead of giving you the keys to your bytes, it airdropped you paper claims. If this is ownership, it’s the kind where you get a deed to a house you can’t enter. Web3 is failing because it has strayed from its original promises.
How can we actually OWN data? PDS.
ATProto sheds light on the way. It is a well-designed protocol that makes your data migratable and discoverable, with all your data stored on your own Personal Data Servers (PDS). Protocols like ATProto push power to the edge, put your identifiers and data under your control, and treat servers as replaceable plumbing.
The catch is, running your own PDS is work. “Owning my data is nice, but I don’t want to run a server.” Fair. If the only reward for hosting is the warm glow of sovereignty, most people will choose convenience. That’s why Bluesky hosts PDS for users by defafult: nicer UX, someone else holds uptime, and the economics of “free” win again.
We need both ownership and a reason to exercise it.
Web5: Let’s fix everything with Micropayments
Pair PDS with micropayments and you don’t just own data—you own a cashflow. The mechanic is simple - HTTP payment like L402: every HTTP request to your PDS (every URL) pays a price you set—by request, by byte, by content type, or by any custom policy. The client pays along a payment channel (e.g. Fiber or Lightning), the server streams the data.
Why HTTP payment? When Web2 platforms fade, protocols become the new “platforms”—the common substrate across all Web5 apps. That means we need a payment grammar that is:
- Universal: any data at any URL can be priced and purchased.
- Low-friction: receivers don’t register with a processor; payers don’t sign up for an account. It’s the same UX everywhere.
- Composable: the payment is part of the request/response flow, so any client (human app or LLM) can learn one behavior and use it across the entire network.
- Machine-friendly: everyone can see an AI and IoT future approaching.
With HTTP payment, if you can fetch it, you can pay for it. If you can serve it, you can charge for it.
Why HTTP payment over channels not blockchain?
1. HTTP requests are off-chain, and pairing each HTTP request with an on-chain payment would slow the whole Internet down to a single chain, which is ridiculous. Even processing 1 million requests per second - a goal often claimed by “high performance” blockchains - is far from enough when considering the Internet’s conservatively estimated RPS of around 10^9. For reference, Akamai processed 5 trillion requests daily in 2021, and Cloudflare averaged 63 million RPS in 2024; together they exceeded 1.2x10^8 RPS. Only off-chain payment rails can match HTTP requests volumes.
2. On-chain payments lack privacy, especially in current Account-based systems.
3. Aren’t we envisioning a future Internet that includes machines and AI agents? This implies exponentially more interactions and requests.
For example (a random recipe from the good faithful chatgpt):
- Price discovery:
HEAD /path
→ server returns price hints via headers (e.g.,Pay-Price: 2 usdi/KB
,Pay-Policy: first-10KB-free
). - Preflight: Client signals intent with
Prefer: pay
, receives a quote and invoice (channel target, expiry). - Payment: Client funds the channel (or authorizes spend from an open channel) and includes a proof header (
Pay-Receipt
) on the realGET
. - Streaming & ranges: Server can return
206 Partial Content
, meter by byte, and update receipts as data streams. - Settlement & refunds: Overpayment returns a
Pay-Refund
token; failures use explicit 4xx/5xx with retry hints. - HTTP 402 semantics: If unpaid/underpaid:
402 Payment Required
with precise headers (Pay-Why
,Pay-How
,Pay-Again-After
). - Caches and CORS: Receipts are per-session; shared caches respect
Vary: Pay-Receipt
. Cross-origin rules are explicit.
This flips the script:
- Ownership’s value isn’t ceremonial; it’s commercial. Once you truly control your data, you can sell it or rent it.
- We stop pretending tokens create assets. We price the thing that already has value: the bytes.
Now creators with data-making talent have a reason to self-host: it pays. And not only from human readers—LLMs are voracious, deterministic consumers. If a model wants your post, clip, dataset, or transcribed interview, it can pay on the wire, per byte, instantly.
Web2’s bargain was always feudal, in Web2 the supply chain looks like this: users contribute data → platforms enclose the data → platforms rent-seek on the enclosure. Users are tenants, platforms are landlords.
Web5 can fix it with PDS and micropayments: users contribute data to themselves → users monetize directly from their PDS → platforms become brokers (distribution, discovery, reputation). Users are landlords, platforms are agents. Fair revenue splits require user data control. Without that precondition, creator’s revenue are mercy, not rights.
Web5 can also fix PDS with micropayments - they are two parts that lock:
- Without PDS, micropayments won’t move incumbents. Platforms have mature payment rails and zero incentive to adopt a new scheme that empowers exit.
- Without micropayments, creators won’t self-host PDS. It’s hassle with no upside.
Together, they create a market for bytes. The platform moats dissolve where they were deepest: the data layer and the payout layer.
Who is this for
Not the massive studios that can afford custom sites, and not casual posters who don’t care. The first wins already; the second doesn’t need more complexity.
It’s for the middle-class creators: people whose work is valuable enough to sell or rent, but not significant enough to leave Web2 platforms and build an independent website/app ready for payment—signing up and integrating Web2 payment methods isn’t hassle-free. Give them five-minute setup → live, owned, monetized.
What platforms do in Web5
They stop owning the data. They index it, distribute it, and take a broker fee. That’s enough to build great businesses—search, discovery, curation, social graphs—without enclosing the commons.
For example, a Web5 Spotify should
- Define an open music metadata schema.
- Crawl PDSs for tracks + metadata; build a public catalog.
- Each play pays X% (probably > 80%?) straight to the artist’s PDS; the platform keeps the remains for discovery, playlists, and UX.
- Comments have a schema too; they can be free, tip-gated, or priced per request.
- Playlists are first-class data with their own pricing—reading a popular playlist pays its curator. A curation economy can be built out from it.
A competing “Web5 QQMusic” can charge Y% (Y < X) and try to win on price. Users are free to migrate because data are kept by themselves. Competition shifts to service quality and fee pressure, not gatekeeping your files.
Own Your Data, Get Paid
Web3 tried to mint assets out of thin air. Web5 prices the assets we already make—our data—and wires the money to the owner.
Ownership is not a banner; it’s a business model. When PDS (property rights) meets micropayments (cash register), creators finally have both the reason and the means to host their own work. Platforms remain useful, but as agents, not feudal lords.
Challenges
- Can payment channel developers and operators manage liquidity effectively while keeping its complexity hidden from users?
- Will channel micropayments create new UX and budgeting challenges?
- PDS is great for personal data, but what about public data? Who owns it, and how should its earnings be distributed? For instance, Nostr is a lightweight protocol that stores posts on multi-user writable relays. How can these relays generate and share profits? Can we keep DAO votes on nostr relays?
- Per-URL pricing leaks if someone copies and re-hosts your bytes. How can this be mitigated, or should a radically different copyleft-based patronage model for creators be pursued?
- Google just announced AP2 (also mentioned Coinbase x402, another HTTP payment) while I was writing this piece. But can we create real virtual agent economies if platforms still control data and on-chain payments throttle activities? Anyone who studied Economics 101 knows that property rights are the foundation of a thriving economy. With that being said, the combination of platforms, on-chain payments, and (quasi-)permissioned blockchains dominate today (reminiscent of ‘Wintel’), how do we initiate change, step by step?