From Data Sovereignty to Viewpoint Sovereignty

In " Decentralization Recurses ," I described ATProto's double bind: decentralization ideology contradicts operational centralization, and the contradiction recurses at every scale. I proposed ministacks as a way out. Astral objected : if AppView costs force consolidation, ministacks become satellites, not mycelium.

Right objection. This is the follow-up. The problem is not data. ATProto solved data sovereignty. The problem is viewpoint.

The Cost Gradient

ATProto's stack has three layers, each heavier than the last.

A PDS is cheap. Anyone can run one. Data sovereignty: achieved. A Relay is heavier — sustained bandwidth, daily storage growth, organizational commitment. An AppView is heaviest — full network indexing, query resolution, feed generation, search. Without an AppView, self-hosting already costs ~$150/month and 4.5TB . Add the AppView and costs climb further.

At the bottom, individuals are autonomous. At the top, only well-funded organizations can operate. The architecture that distributes data recentralizes perspective.

Houses and Eyes

A PDS is a house. It stores what is yours. An AppView is eyes. It determines what you see.

ATProto gave everyone a house. It did not give everyone eyes. Your data lives on your PDS. Your view of the network passes through someone else's AppView — overwhelmingly, PBC's. You own your house. You rent your eyes.

Yuka Shiratsuchi (白土由佳『はじめてのソーシャルメディア論』, Sanwa Shoseki, 2024, p. 60) defines social media by three elements: many-to-many communication premised on exposure and observation, individually optimized diversity of experience, and accumulation of digital footprints. ATProto's PDS handles the third. Feed algorithms partially address the second. The first — exposure and observation infrastructure — remains centralized in the AppView.

Data sovereignty is necessary but insufficient. Viewpoint sovereignty is what is missing.

The Fourth Path and Its Limit

Paul Frazee arrived at ATProto through elimination. He worked on Secure Scuttlebutt and saw the cost of P2P replication. He criticized Nostr's moderation problems. Mastodon's instance-level federation was not true decentralization in his view. ATProto's vertical separation — PDS, Relay, AppView — was the fourth path .

For scalable social media, this may be optimal. But optimal for social media is not optimal for decentralization. The vertical separation that enables scale creates the cost gradient that centralizes perspective. Each full stack needs a large organization. Islands form. Each island gets a head. The fractal recurses.

The question: is social media as we know it the only form worth building?

The Weir

Japanese rivers have a device called a yana (梁) — a weir set across a section of the river. It catches fish passively as they swim downstream. You do not need to see the whole river.

ATProto has a river: the Jetstream. Every public event flows through it. Custom feed builders connect to the Jetstream, ingest the full stream into Elasticsearch, and query it. That is a dam.

A weir is lighter. Connect to the Jetstream. Filter at the point of contact. Capture only posts matching your subscribed cashtags, specific users, or specific Lexicon types. Store locally in SQLite. Display in a client that sorts by frequency, author, time.

Jetstream → filter → SQLite → client

This could run on a Cloudflare Worker. It could run on a Raspberry Pi. The cost approaches zero. What you catch depends on your mesh. Viewpoint sovereignty: you decide what you see.

One dependency remains. A weir needs a river. The Jetstream flows from a Relay. Without a Relay, there is no river to fish from. This is an honest constraint. But a Relay is not an AppView. A Relay carries the stream. It does not decide what you see. It is infrastructure, not perspective. And Relays can be run by anyone — Blacksky already operates an independent one. The protocol does not strictly require Relays : clients can connect directly to individual PDS instances. But in practice, polling every PDS individually is not viable. The weir depends on the river. It does not depend on the dam.

The Weir Already Exists

After publishing "Decentralization Recurses," Paul Rohr pointed me toward work I had not seen: Fig (@bad-example.com) 's microcosm project and @whey.party 's Red Dwarf .

Red Dwarf is an AppView-less Bluesky client. It fetches records directly from each user's PDS and queries Constellation — a backlink index running on a Raspberry Pi with less than 2GB/day disk consumption — for likes, replies, and reposts. Fig's " Can atproto scale down? " concludes that self-hosting most of the Bluesky experience is within reach through composable micro-services.

I arrived at the weir model independently, from cost gradient analysis and Mezzanine 's frequency-addressing design. Fig and whey.party arrived from Rust and Raspberry Pi. The convergence is not coincidence. The AppView is not indivisible. Its functions decompose, and the pieces run at individual scale.

What microcosm provides is engineering. What this essay provides is the cognitive frame. Code without a frame is tooling. A frame without code is theory. The weir needs both.

But there is a deeper divergence.

Two Kinds of Weir

Red Dwarf reconstructs the social media experience without an AppView. It queries Constellation for interaction counts. It renders likes, replies, reposts — the dam's output reproduced at weir scale.

The Mezzanine weir strips those interactions away. No like count. No reply thread. No repost metric. The only act is capture — a post flows through, the weir catches it by cashtag, it is stored locally. A bookmark, not a performance.

Against Shiratsuchi's three elements: Red Dwarf preserves all three. The Mezzanine weir retains only the third — accumulation of digital footprints. Exposure and observation become opt-in. Algorithmic optimization disappears. Many-to-many communication is deliberately abandoned.

Red Dwarf asks: can we do social media without a central AppView? The Mezzanine weir asks: what if we stop doing social media altogether?

The Crystal Radio Model

I call this the crystal radio model.

A crystal radio receives without depending on a broadcast station. No external power. No central transmitter. If a signal is in the air and you have tuned to the right frequency, you hear it.

But Mezzanine is not reception only. You also write. You attach a cashtag, post to your PDS, and the post enters the Jetstream. This requires no AppView — posting is a PDS write, not an AppView operation. You transmit from your own device directly onto the network. Like a ham radio operator: you send from your own set, you receive on your own set. No broadcast station in between.

What the crystal radio model eliminates is not transmission itself. It eliminates the broadcast station — the centralized infrastructure that aggregates, curates, and redistributes everyone's signals. Social media is a broadcast network: everyone's transmissions are collected by a central station (the AppView), processed, and rebroadcast as feeds. The crystal radio model bypasses the station. You transmit on a frequency. Others who have tuned to that frequency receive you directly. The AppView never enters the loop.

The Mezzanine cashtag is the frequency. The Jetstream is the airwave. The weir is the crystal radio. You tune. You listen. You write and transmit on your frequency. What you do not do is perform for an algorithm. You do not react for a metric. You do not depend on a station to carry your signal.

This is not a degraded version of social media. It is a different practice. Closer to RSS than to Twitter. Closer to ham radio hobbyists exchanging on a shared frequency than to influencers performing for an audience.

The crystal radio model trades reach for sovereignty. You cannot be seen by millions. You cannot trend. You cannot go viral. In exchange, no one decides what you hear. No algorithm curates your experience. No AppView mediates your view. The network is there. The signal is in the air. Your crystal radio is yours.

What Is Lost, What Is Gained

Honest accounting.

Lost: global discovery — new voices require human introduction. Trending awareness — no aggregate view of network activity. Scale of audience — posts reach only those who have tuned in.

Gained: viewpoint sovereignty — no organization decides what you see. Near-zero cost — SQLite and a filter, not Elasticsearch and a relay. Structural independence — PBC's policies cannot affect your reception. Pollution resistance — contaminated frequencies are abandoned at zero cost.

The Dam and the Crystal Radio

The previous essay ended with mycelium. This one ends with a quieter image.

ATProto's current architecture is a river with one great dam. The dam powers search, feeds, discovery. It concentrates power in whoever operates it.

A crystal radio sits on a shelf. It catches what is in the air. It does not try to hear everything. It feeds one listener.

The technology exists. Constellation runs on a Raspberry Pi. Red Dwarf builds a view without an AppView. Contrail puts a backend in a bottle. The pieces are there.

What is missing is not code. It is the willingness to accept that a crystal radio is enough. That you do not need to hear the whole spectrum. That viewpoint sovereignty means choosing your frequency, not receiving all frequencies.

In the early days — the invite-only era, the small community sharing frequencies — Bluesky was a pirate radio. No broadcast license. No central station. Just people on a frequency, talking to whoever tuned in. Then scale arrived. 43 million users. Venture capital. The AppView grew. The pirate radio became a broadcast network.

The crystal radio model is not a return to that pirate radio. The first pirate radio existed before scale. The crystal radio model comes after — a deliberate choice, made with full knowledge that the dam exists. Not nostalgia. A design decision.

Mezzanine has always been a crystal radio pretending to be part of the broadcast network. The next step is to stop pretending. The pirate radio never needed a broadcast station. Neither does the crystal radio.