Web5: Own Data, Not Tokens

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 real GET.
  • 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?
13 Likes

2 posts were split to a new topic: 再一次,基础性逻辑错误被展示,代币和数据不是排斥性关系,代币是数据的其中一种

变革:

中心化组织到底解决了哪些问题,web5替代后,会延伸哪些新问题

拿上面的去中心化音乐平台举例,当人们发现这个音乐平台更具有效应,更好用,更便宜(会员费),有更多音乐,创作者发现更自由,更赚钱(合法内),自然人们就发现了去中心化的作用和意义

会逐渐从一个点扩散,蔓延到其他点

《归我们!》

★从区块链到加密货币,数字民主能够改变打工人被剥削的命运吗?

★平台合作社如何助力劳动者构建自主的网络空间?

★内卷没有未来,躺平不是出路,如何破局?

☆告别内卷,走向自主!

一个幽灵,合作社的幽灵,在数字资本主义的虚拟王国中游荡

一群不愿内卷也不甘躺平的年轻人,正联合起来改变游戏规则

这是一个转型期的故事。

从数码封建主义到开放合作主义,从网络等级制度到去中心化自治,共有经济新世界的大门已经向我们敞开。

在个体原子化和反全球化保守潮流的双重大流行中,世界正经历着翻天覆地的变化。许多人正在从裂缝中跌落,丧失了社会安全保障网的支撑。年轻人在现有系统中看不到未来,渴望一种能创造尊严和安全的工作模式,数字平台合作社应运而生。它继承了传统合作社共同运营、民主管理、利益共享的原则,又结合了去中心化的区块链等尖端数字技术,由员工和用户共同拥有和控制平台。在这种自下而上、“民享民治”的经济模式中,成员优先于利益,企业不再需要承受来自投资人的利润增长压力,每个成员在运营问题上都拥有真正的投票决定权,并能通过控制劳动条件实现体面的工作方式。

从美国芝加哥到印度农村,从流媒体音乐社区到司机联合运营的打车平台,全球各地的鲜活案例向我们证明了一个更美好的世界不仅是可能的,而且它已经存在于我们中间,并正在等待你的加入。

3 Likes

I like how Market for Bytes serves as a slogan for CKB. Where Bitcoin explains itself in its name, Common Knowledge Base finds its utility summed up in Market for Bytes. But we don’t want people to confuse CKB with things like Filecoin, they are totally different. The offchain micro-payment plus common knowledge onchain is a new inspiration for the market of bytes to explain such difference. One extra chanllendage might be the mental cost problem, while the LLM token-based charge seems educate the users a little bit in such aspect.