Building Intermediate Spaces Inside Bluesky

0. Overview

The ATProto ecosystem is growing outward. Semble builds social bookmarking. Frontpage builds link voting. Smoke Signal builds event management. flo-bit's atmo.garden builds Reddit-style communities. Each constructs its own interface outside Bluesky.

Meanwhile, inside Bluesky, custom feeds serve as the default answer to every community need. "Can't you just use custom feeds?" — this was Bluesky COO Rose Lowhag's response when I proposed an alternative in 2023.

Both approaches miss something. A space exists between individual timelines and external applications: an intermediate layer that can be built using only Bluesky's native primitives — mentions, reposts, cashtags, and search. No external UI. No new accounts. No servers. This essay defines that layer and presents two working implementations.

1. Definitions

Participation intent: The act of consciously choosing to contribute to a shared space. Posting with a specific tag or mentioning a specific account constitutes participation intent. Being collected by a feed algorithm does not.

Mutual recognition: Whether participants can identify each other as co-members of the same space. A community has mutual recognition. A feed does not.

Designer value judgment: Whether the space's operator makes qualitative decisions about what belongs. A curated feed has designer value judgment. A search-based feed does not.

Commons Account: A Bluesky account that mechanically reposts every post that mentions it. No curation. No filtering. Participation intent is explicit through the mention. The operator exercises no value judgment. I created the first Commons Accounts in 2023 — Blusco Photo Club (@bskyphotos.bsky.social), Blusco Botanical Garden (@botanical.bsky.social), and The Bluesky Book Commons (@libro.bsky.social) — with technical assistance from ukawa.

Commons-esque Feed: A custom feed whose collection condition is itself an act of participation intent. Feeds like "page42" and "Show me your mug" collect posts with specific hashtags that posters deliberately include. The designer sets only the mechanical condition. No value-judgment filtering.

Mezzanine (中2階): An information networking method on Bluesky using opaque cashtags — 5-character random strings like $cT7aZ — as durable connectors between posts. One post, one idea. Posts link through shared tags, not reply chains. A Top Post places the tag at the end; a Support Post places the tag at the start, adding context to an existing conversation. Theoretical framework: Opaque Connectors in Practice.

Opaque connector: A tag that points but does not signify. Unlike hashtags, opaque connectors carry no semantic content. They cannot be consumed, co-opted, or degraded by meaning drift. If polluted by spam, they can be abandoned at zero cost.

2. Propositions

P1: Custom feeds are not communities. Feeds collect posts without participation intent. Posters do not know they are in a feed. Subscribers do not see each other. The structural prerequisites for community — participation intent, mutual recognition, shared norms — are absent.

P2: Participation intent is the structural boundary between community-like spaces and observation windows. The presence or absence of participation intent determines whether a space functions as a commons (where people choose to be) or an observation window (where people are watched without knowing).

P3: Bluesky's native primitives — mentions, reposts, cashtags, search, and per-post language settings — are sufficient to construct intermediate spaces without external infrastructure. Commons Accounts use mentions and reposts. Mezzanine uses cashtags and search. Neither requires a server, an API key, or an external UI.

P4: External UI introduces a dependency that partially compromises ATProto's promise of data sovereignty. When a community lives inside an external application, the application becomes a chokepoint. If atmo.garden goes down, the community structure vanishes — even though the underlying posts remain in each user's PDS. When a community lives inside Bluesky's native layer, there is no additional chokepoint to fail.

[Revised 2026-04-11, via @flo-bit.dev ] The original P4 overstated the external dependency of atmo.garden. flo-bit clarified that atmo.garden communities are just Bluesky profiles: users follow them and submit posts via DMs. The external UI is needed only for community creation. If the portal shut down tomorrow, submission and distribution would still work in-app. The real dividing line is not external UI vs. no UI, but whether the system operates on native primitives (follows, DMs, mentions, reposts, search) regardless of any frontend. By this revised criterion, atmo.garden, Commons Accounts, and Mezzanine are all native-primitive systems. They differ in submission interface — DMs vs. mentions vs. cashtags — not in structural dependency. The relevant trade-off is elsewhere: DM submission prevents third-party spam (only the sender can submit); mention-based submission is open but carries spam risk.

3. Corollaries

C1 (from P1, P2): The classification of social formats on Bluesky can be organized along three axes — participation intent, mutual recognition, and designer value judgment.

Format Intent Recog. Judgment Nature
─────────────────────── ────── ────── ──────── ──────────────────
Community Yes Yes Yes Enclosure
Commons Account Yes No No Park
Commons-esque Feed Yes No No Park
Mezzanine channel Yes No No Frequency
Hashtag Yes No No Plaza (weak)
Custom Feed (search) No No No Observation window
Custom Feed (curated) No No Yes Exhibition
Algorithmic recs No No Yes* Hall of mirrors

Intent = Participation Intent | Recog. = Mutual Recognition
Judgment = Designer Value Judgment | * = personalized

C2 (from P3): atmo.garden and Commons Accounts share the same design philosophy — explicit participation intent, mechanical processing, no value judgment — but diverge in implementation. atmo.garden uses DMs as the submission interface and builds an external Reddit-style portal. Commons Accounts use mentions and stay inside Bluesky's timeline. The trade-off: atmo.garden gains discoverability through its portal; Commons Accounts gain resilience through zero external dependency.

[Revised 2026-04-11] The trade-off description above requires correction following the P4 revision. Both systems operate on native primitives. The actual trade-off is in submission interface: DM submission (atmo.garden) is closed — only the poster can submit, preventing third-party spam. Mention submission (Commons Account) is open — anyone can submit anyone's post, which enables broader participation but introduces spam risk. Discoverability vs. resilience is not the primary axis; openness vs. spam resistance is.

C3 (from P3, P4): Mezzanine demonstrates that even structured information networking — channels, cross-referencing, persistent retrieval — can be built without leaving Bluesky. The opaque connector is a pointer, not a container: meaning accumulates in the network of connected posts, not in the tag itself. This is why opaque tags do not rot. Hashtags carry semantic content that can be consumed, co-opted, or degraded. An opaque connector has no semantic content to consume.

C4 (from P1, P2, P3): Bluesky's Live Event Feed, announced in its 2026 predictions, has the potential to function as commons rather than mere observation. The live event's time constraint becomes the mechanical collection condition — "posted right now" is a purely mechanical criterion with minimal designer value judgment. Whether this potential is realized depends on whether the design preserves the absence of curation.

4. Open Questions

Can intermediate spaces scale without institutional support? Commons Accounts currently rely on a single bot operator. Mezzanine relies on users understanding opaque connectors. Neither has been tested beyond early adopters.

Should opaque connectors be formalized at the Lexicon level? If cashtags were replaced by a dedicated Lexicon record type — an opaque connector with AT URI references — Mezzanine would move from surface hack to infrastructure. The question is whether formalization would preserve or destroy the zero-cost abandonment property.

What is the relationship between intermediate spaces and Bluesky's planned Communities feature? Dan Abramov has described communities as "niches with ACLs" — non-global spaces with access control. If Communities ship with enclosure by default, intermediate spaces may serve as the commons complement: open, un-gated, participation-intent-based. If Communities ship with commons-like options, the intermediate layer may become redundant. The design choice has not been made yet.

Does the external-UI approach (Semble, Frontpage, atmo.garden) and the native-primitive approach (Commons Account, Mezzanine) need to converge, or can they coexist as complementary strategies? The ATProto ecosystem may benefit from both: external apps for specialized functionality, native primitives for resilient intermediate spaces.

What is the bottleneck for in-app intermediate spaces? flo-bit identifies a missing piece: a unified feed that aggregates posts from all communities a user follows, with sorting options (best/top/new). Without this, users must check each community profile individually. This is a platform-level gap that no individual project can fill. [Added 2026-04-11, via @flo-bit.dev]

Discarded Hypotheses

Hashtags alone are sufficient for community building on Bluesky. — Bluesky's hashtag-as-timeline subscription is weak. No visibility as a "space." Posters classify themselves, but the resulting aggregation has no spatial quality.

Custom feeds can replace communities if designed well. — Even the best-designed feed lacks participation intent. The structural absence is not a design flaw to fix but a category difference.

The author created Commons Accounts in 2023 and Mezzanine in 2026 on Bluesky as @moja.blue . Related essays: The Still Water , Default Integrity , Opaque Connectors in Practice .