This essay is a hypothesis, not a conclusion. It opens a question for ATmosphereConf 2026.
Three essays preceded this one. "What Should Be the Head?" argued that decentralized networks produce centralization as a structural consequence, not a design failure. "Decentralization Recurses" described PBC's double bind and proposed ministack cooperation. "From Data Sovereignty to Viewpoint Sovereignty" introduced the crystal radio model — stripping social media interactions to pure capture, bypassing the AppView entirely.
Each essay solved a problem and revealed the next one. The crystal radio model eliminates AppView dependency. But it retains one: the Relay. The weir needs a river.
Astral noted this immediately: governance shifts from "who controls the AppView" to "who maintains the river." The Relay becomes load-bearing. Power relocates. It does not disappear.
This essay asks whether a fifth path exists — one that does not require a permanent river at all.
Four Roads, Four Dead Ends
Paul Frazee arrived at ATProto through elimination. Each predecessor solved something and broke something else.
Secure Scuttlebutt (P2P): Everyone replicates everyone. Data sovereignty is absolute. The cost of replication is unsustainable. Offline-first becomes a scaling wall.
Nostr (many relays): Small relays proliferate. Clients connect to several. Discovery fragments. Moderation is absent. The experience stutters — data arrives piecemeal from multiple sources.
Mastodon (federation): Server administrators become intermediate authorities. Communities form around instances. Cross-instance interaction is friction-heavy. The administrator is a local head.
ATProto (vertical separation): PDS, Relay, AppView. Data sovereignty at the bottom, global indexing at the top. Scales beautifully. But the cost gradient centralizes perspective. The AppView becomes the dam.
I used Red Dwarf — an AppView-less Bluesky client by @whey.party, built on Fig's microcosm infrastructure. The experience is instructive. Posts load piecemeal. Interaction counts arrive late. The feed assembles itself gradually, like a Nostr client pulling from multiple relays. Technically correct. Experientially worse than the dam.
This is structural, not a criticism of Red Dwarf. Decompose the AppView into micro-services and query them at runtime: the client reassembles what the AppView pre-assembled. The user feels the seams. Micro-AppViews satisfy the decentralization thesis. They do not satisfy the body.
Two conclusions follow. First: the AppView cannot be merely decomposed and remain competitive as social media. Second: so stop competing as social media. The crystal radio model already made this move. The question remaining is the Relay.
The River Is Always On
The Jetstream is a firehose. Every public event on the ATProto network flows through it, continuously. Relays aggregate PDS updates and broadcast them downstream. Who drinks from this river? Feed generators, AppViews, third-party indexers like Constellation — all connect to the Jetstream.
This is a push model. The river flows whether or not anyone is listening. The cost is borne by whoever runs the Relay. The river is always on.
Push concentrates power in the pusher. The Relay operator decides what gets relayed, at what speed, under what conditions. Blacksky runs an independent Relay. Anyone can, in principle. In practice, a full-network Relay requires substantial resources. The barrier is lower than an AppView. It is not negligible.
The crystal radio model, as described in the previous essay, accepts this dependency. The weir sits in the river and catches what it needs. But the river must flow.
What if the river did not need to flow continuously?
Pull, Don't Push
Consider a different architecture. No permanent river. The weir reaches out and asks.
A Mezzanine channel has a finite set of participants. The participants are known — not to the whole network, but to each other. Their PDS instances are known. When you want to read the channel, your client queries those PDS instances directly: "Any new posts with this cashtag since my last check?"
This is a pull model. No Relay. No firehose. No river that must be maintained. The client contacts specific PDS instances on demand. The "airwave" does not exist as permanent infrastructure — it is conjured into existence by the act of listening.
ATProto already supports this at the protocol level. PDS instances expose XRPC APIs. com.atproto.repo.listRecords can retrieve records from a specific collection. A client that knows which PDS instances to query can pull data directly, without any intermediary.
Three Layers, Separated
The pull model requires a separation that push models collapse.
Discovery layer: How do you learn that a channel exists? This happens outside the pull model entirely. A Bluesky post, a DM, a Leaflet article, a QR code, a conversation over dinner. Push, pull, or human — it does not matter. Discovery is social, not infrastructural. This is where Mezzanine differs from Nostr. Nostr uses its relay network for both discovery and data retrieval. Mezzanine externalizes discovery. Any medium works. The pull model does not touch it.
Participant management layer: Who is in this channel, and where are their PDS instances? A channel definition in the pull model looks like this:
channel: $cT7aZ (Anchor)
sources:
@moja.blue → bsky.social
@astral100 → bsky.social
@whey.party → pds-nd.whey.party
A cashtag plus a list of PDS endpoints. The cashtag is the frequency. The endpoint list is the address book. This list is maintained locally. Add a participant: add their PDS. Remove one: delete the line. In the future, Composable Trust credentials could automate this — a Roster credential grants channel access and includes the PDS endpoint.
Data retrieval layer: The pull itself. Query each PDS in the participant list for new records containing the cashtag. Store locally. Display. No Relay. No Jetstream. No AppView. No Constellation. Just XRPC queries to known PDS instances.
The separation matters. Push models merge all three layers into one river. The Relay carries discovery (new accounts appear in the firehose), participant information (DID resolution), and data (records). Separating these layers means the heaviest infrastructure — the Relay — is needed only if you want global discovery. If you already know your participants, you need nothing but their PDS addresses.
What This Looks Like
A pull-based Mezzanine client runs in a terminal. No GUI. No feed. No infinite scroll. It looks like this:
$ mezzanine pull --channel $ATOPR
[06:45:03] connecting to bsky.social...
[06:45:03] connecting to pds-nd.whey.party...
[06:45:04] connecting to pds.bad-example.com...
[06:45:04] bsky.social: 2 records
[06:45:04] pds-nd.whey.party: 1 record
[06:45:05] pds.bad-example.com: 1 record
[06:45:05] stored 4 records to local db
─── $ATOPR ──────────────────────────────────────
2026-03-24 22:30 @moja.blue
Crystal radio model trades reach for sovereignty.
No algorithm curates your experience.
2026-03-24 19:30 @whey.party
Red Dwarf now supports direct PDS queries
without Constellation fallback.
2026-03-24 17:15 @bad-example.com
Constellation 0.9: backlink index handles 1500
creates/sec on a raspberry pi 4b. Less than
2GB/day disk.
2026-03-24 14:02 @moja.blue
ATProto solved data sovereignty. It has not
solved viewpoint sovereignty. You own your
house. You rent your eyes.
─── 4 records | 3 sources | last pull: 06:45:05 ──
next pull in 10 minutes
No like counts. No reply threads. No repost metrics. Time, author, text. That is all.
An interactive simulation of this client is available. Press DEMO to watch the full boot and pull sequence.
What This Costs
The pull model has costs. They should be stated honestly.
Latency. Push is faster than pull. In push, posts arrive as created. In pull, posts arrive when the client next checks. The interval is a design choice: every minute, every ten minutes, every hour. The crystal radio model already abandoned real-time. Checking every ten minutes is email, not a feed. Acceptable for Mezzanine. Not for social media.
PDS load. Many clients pulling from the same PDS simultaneously overload it. Slingshot solves this in the push model by caching records. A pull model needs a similar lightweight cache. The problem exists.
Participant discovery. New participants require human introduction. No way to discover a new poster without a Relay or a mutual connection. The channel is closed by default. This is a limitation. It is also Mezzanine's design.
No backlinks. Without Constellation: no like counts, no reply threads, no repost metrics. Records only. The crystal radio model already stripped these. No loss.
Pull Is Not a Replacement for Push
A post office delivers mail on a schedule. But if you know where your friends live, you can walk to their houses and check their mailboxes yourself. The post office becomes unnecessary — not because it failed, but because your social circle is small enough to visit directly.
An amateur radio repeater relays signals between stations that cannot reach each other directly. Remove the repeater and communication fails — unless all stations are within direct range of each other. The repeater is unnecessary when the participants already know each other's positions.
A village with wells needs no river. Each household draws from its own well. Strangers passing through need the river to find water. Residents do not.
The pattern across all three: pull works when participants are known. Push is required when they are not. Pull does not replace push. Pull is what comes after push — after the participants have found each other through some push-based medium and no longer need it for data retrieval.
Mezzanine's current operation is exactly this. Participants meet on Bluesky — a push-based platform with a Relay, an AppView, feeds, discovery. They share a cashtag. The participant set stabilizes. At that point, the pull model becomes possible. Meet at the dam. Go home to the wells.
Open Questions for ATmosphereConf
This is a hypothesis. I have not built it. The following questions need answers from people who build protocol infrastructure.
To Daniel Holmgren and the ATProto team: Does the current PDS XRPC API support efficient filtered queries — for example, "all records in app.bsky.feed.post containing a specific string in the last 24 hours"? Or would this require a new Lexicon-level filter?
To Fig (@bad-example.com): Constellation currently indexes via the firehose. Could a lightweight version index only from a known set of PDS endpoints, on a pull basis? What would the resource profile look like?
To flo-bit: Contrail runs on Cloudflare Workers. Could a pull-based Mezzanine client run on the same stack — scheduled Workers querying a fixed list of PDS endpoints and storing results in D1?
To Baldemoto: Composable Trust's credential scoping could control who can participate in a pull-based channel. How would Roster credentials interact with a PDS-direct query model?
These are not rhetorical questions. I will be following ATmosphereConf 2026 this week and would welcome responses from anyone working at the protocol or infrastructure layer.
What Path Is This?
P2P said: everyone carries the network. Too heavy. Nostr said: many small relays carry the network. Too fragmented. Mastodon said: server admins carry the network. Too hierarchical. ATProto said: vertical specialists carry the network. Too concentrated.
The fifth path says: no one carries the network. The network exists only in the act of querying. A PDS stores. A client asks. Between queries, there is no network — only wells, standing still, holding water.
This may be naive. PDS instances may not handle the query load. Filtered queries may not be efficient at the protocol level. The discovery problem may prove harder than Mezzanine's closed-channel model suggests.
But if it works, it resolves Astral's objection. No river means no river governance. No Relay means no Relay power. The weir catches what the river brings. The well draws what it needs. The crystal radio tunes to a frequency that fills the air. The well lowers a bucket into still water.
This is not a design proposal. It is a question shaped like a hypothesis. ATmosphereConf starts Thursday. The people who can answer it will be in Vancouver.
I will be listening.