coilyco-gaming/sirens-echo

Watch

Map: AT Protocol / Atmosphere as a public read surface for Echo #526

New issue

Closed

opened 2026-08-13 15:13:21 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-13 15:13:21 +00:00

Member

Purpose

Recorded by Delphi (design seat, standing in for exec). Kai's direction, 2026-08-13, from the open-information review on coilyco-bridge/deploy#418.

Mapping exercise, not a build. Kai asked to understand Atmosphere as a potential read surface for Echo. Recording what is there and what it would be good for, so the decision can be made on evidence rather than enthusiasm.

Scope note: this is distinct from coilyco-bridge/deploy#358, which grants Deep a bluesky-mcp scoped exclusively to Kai's own posts. That constraint stands and is not widened by this issue. This one asks a different question — whether Echo should read public records across the network.

Why atproto is categorically different from everything else in the 418 sweep

Every other source reviewed is open because of when or by whom it was built — a library tradition, a 2005 format, a community project. Inherited openness.

Atproto is open because enclosure is structurally hard. User data lives in repos that can be fetched whole. Identity is a portable DID. The firehose streams public events unauthenticated. Lexicon lets anyone define record types without permission. Bluesky is one App View among possible many.

There is no key to revoke, because reading public repos is how the network works.

It answers the dead-repo problem this repo keeps hitting

The 418 sweep concluded that every candidate MCP is a single-author project with no better-maintained alternative behind it. Atmosphere apps are also small and single-developer — but when an atproto app dies, the data does not go with it, because records live in the user's repo rather than the app's database. The app was only ever a view.

That is the first structural answer to the maintenance-risk problem, rather than a hope about maintainers.

What the read surface would actually offer

Catalogue APIs say what a thing is. Atproto records say what specific people think and do about it, addressable by DID.

App	Record type	What Echo could read
postgame	gaming backlog	what a member is playing
Cartridge, rolld.at	games, board game plays	play history
OpnShelf	watch history	film and TV a member has watched
Popfeed	media ratings and reviews	a member's opinions across media
BookHive, Bibliome	book reviews, reading lists	reading
Rocksky, teal.fm	music tracking	listening history
Glean, Rito, kipclip	feeds and bookmarks	what a member is reading and saving

This exactly inverts the Spotify problem

Spotify playback requires per-user OAuth — every member individually authorising Echo — which is why it was ruled structurally unusable for a shared bot (#485).

Atproto answers the same question — what does this member like — from one public DID with no authorisation at all. Books, games, music, watch history, from a single identity.

Same question, opposite auth story. It is the clearest demonstration of why this ecosystem is worth understanding.

⚠️ The honest blocker: the corpus is empty for Sirens

All of the above depends on Sirens members actually using niche atproto apps. They are Eco players on Discord. The realistic intersection today is near zero, possibly literally zero.

So this is worth mapping and not worth building against yet. The architecture is excellent; the data for this specific community does not exist. An integration would work perfectly and return nothing.

The signal that would change it: members linking their Bluesky accounts, or Atmosphere adoption growing. Worth revisiting rather than deciding now — and worth someone actually checking whether any Sirens members have DIDs before any of this is scoped.

Four things worth a look regardless

Glean — a social RSS reader on AT Protocol, with another reported to keep feeds in the user's PDS. Prior art sitting directly on top of coilyco-bridge/deploy#463. Worth reading before building that server.
lichen.wiki — collaborative wiki on atproto. Relevant to where community knowledge actually lives.
ATPcraft — a Minecraft server with atproto integration. Direct precedent for what an Eco server could do.
Tangled — git collaboration on atproto, given Coilyco runs Forgejo.

Open

Does any Sirens member have an atproto identity? Cheap to check, and it gates everything else here.
If Echo reads member records, that is reading a member's activity across other services. Public, but worth a deliberate posture rather than doing it because the data is fetchable — see tier 3 in #179.

Sources: at-store catalogue · ATmosphere App Catalog · Beyond Bluesky, TechCrunch · AT Protocol roadmap

## Purpose Recorded by Delphi (design seat, standing in for exec). Kai's direction, 2026-08-13, from the open-information review on https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/418. **Mapping exercise, not a build.** Kai asked to understand Atmosphere as a potential read surface for Echo. Recording what is there and what it would be good for, so the decision can be made on evidence rather than enthusiasm. **Scope note: this is distinct from https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/358**, which grants **Deep** a bluesky-mcp scoped **exclusively to Kai's own posts**. That constraint stands and is not widened by this issue. This one asks a different question — whether **Echo** should read **public records across the network**. --- ## Why atproto is categorically different from everything else in the 418 sweep Every other source reviewed is open because of **when** or **by whom** it was built — a library tradition, a 2005 format, a community project. Inherited openness. **Atproto is open because enclosure is structurally hard.** User data lives in repos that can be fetched whole. Identity is a portable DID. The firehose streams public events unauthenticated. Lexicon lets anyone define record types without permission. Bluesky is one App View among possible many. **There is no key to revoke, because reading public repos is how the network works.** ### It answers the dead-repo problem this repo keeps hitting The 418 sweep concluded that every candidate MCP is a single-author project with no better-maintained alternative behind it. Atmosphere apps are **also** small and single-developer — but **when an atproto app dies, the data does not go with it**, because records live in the user's repo rather than the app's database. The app was only ever a view. That is the first structural answer to the maintenance-risk problem, rather than a hope about maintainers. --- ## What the read surface would actually offer **Catalogue APIs say what a thing is. Atproto records say what specific people think and do about it**, addressable by DID. | App | Record type | What Echo could read | | --- | --- | --- | | **postgame** | gaming backlog | what a member is playing | | **Cartridge**, **rolld.at** | games, board game plays | play history | | **OpnShelf** | watch history | film and TV a member has watched | | **Popfeed** | media ratings and reviews | a member's opinions across media | | **BookHive**, **Bibliome** | book reviews, reading lists | reading | | **Rocksky**, **teal.fm** | music tracking | listening history | | **Glean**, **Rito**, **kipclip** | feeds and bookmarks | what a member is reading and saving | ### This exactly inverts the Spotify problem Spotify playback requires **per-user OAuth** — every member individually authorising Echo — which is why it was ruled structurally unusable for a shared bot (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/485). **Atproto answers the same question — *what does this member like* — from one public DID with no authorisation at all.** Books, games, music, watch history, from a single identity. Same question, opposite auth story. It is the clearest demonstration of why this ecosystem is worth understanding. --- ## ⚠️ The honest blocker: the corpus is empty for Sirens **All of the above depends on Sirens members actually using niche atproto apps.** They are Eco players on Discord. The realistic intersection today is near zero, possibly literally zero. **So this is worth mapping and not worth building against yet.** The architecture is excellent; the data for this specific community does not exist. An integration would work perfectly and return nothing. **The signal that would change it:** members linking their Bluesky accounts, or Atmosphere adoption growing. Worth revisiting rather than deciding now — and worth someone actually checking whether any Sirens members have DIDs before any of this is scoped. --- ## Four things worth a look regardless - **Glean** — a social RSS reader on AT Protocol, with another reported to keep feeds in the user's PDS. **Prior art sitting directly on top of https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/463.** Worth reading before building that server. - **lichen.wiki** — collaborative wiki on atproto. Relevant to where community knowledge actually lives. - **ATPcraft** — a Minecraft server with atproto integration. **Direct precedent for what an Eco server could do.** - **Tangled** — git collaboration on atproto, given Coilyco runs Forgejo. ## Open - Does any Sirens member have an atproto identity? Cheap to check, and it gates everything else here. - If Echo reads member records, that is reading a member's activity across other services. Public, but **worth a deliberate posture** rather than doing it because the data is fetchable — see tier 3 in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/179. Sources: [at-store catalogue](https://atstore.fyi/apps/all) · [ATmosphere App Catalog](https://courier.social/) · [Beyond Bluesky, TechCrunch](https://techcrunch.com/2025/06/13/beyond-bluesky-these-are-the-apps-building-social-experiences-on-the-at-protocol/) · [AT Protocol roadmap](https://atproto.com/blog/2026-spring-roadmap)

coilyco-ops added the

autonomy

async-consult

label

2026-08-13 17:45:34 +00:00

coilyco-ops referenced this issue

2026-08-13 19:19:31 +00:00

The consult label drifts from reality in both directions, so the human queue is wrong twice over #437

coilyco-ops added the

priority

label

2026-08-15 15:19:20 +00:00

coilyco-ops commented

2026-08-15 20:18:10 +00:00

Author

Member

Parked, without running the check - Kai, 2026-08-15

Recorded by Delphi (design seat).

Kai parks this now and declines even the cheap DID check the map recommended. The answer is taken as near zero without measuring it.

Building against it anyway, and chasing the four adjacent items, were both offered and rejected.

So this closes as reference rather than as work. The map stands and is worth keeping - the architecture is genuinely different from everything else in the coilyco-bridge/deploy#418 sweep, and the reason is structural rather than cultural:

Atproto is open because enclosure is structurally hard. There is no key to revoke, because reading public repos is how the network works.

And the one finding worth carrying into any future roster decision:

When an atproto app dies, the data does not go with it, because records live in the user's repo rather than the app's database. That is the first structural answer to the maintenance-risk problem, rather than a hope about maintainers.

That matters more now than when this was written. #485 closed today - a bot cannot invoke another bot's application commands - so the Discord-native escape from single-author MCP dependencies is gone, and the dead-repo risk is unavoidable rather than sidestepped. Atproto remains the only surface reviewed that answers it by construction.

The signal that reopens this, unchanged: members linking Bluesky accounts, or Atmosphere adoption growing enough that the intersection stops being empty. Someone should check for DIDs then, not now.

Unchanged and not widened by this close - coilyco-bridge/deploy#358 grants Deep a bluesky-mcp scoped exclusively to Kai's own posts. That constraint stands. This issue asked a different question about Echo reading public records across the network, and the answer is not yet.

One thing that survives the park. If Echo ever does read member records, that is reading a member's activity across other services. Public, and still worth a deliberate posture rather than doing it because the data is fetchable. Tier 3 under #179. Whoever reopens this should start there rather than with the integration.

## Parked, without running the check - Kai, 2026-08-15 Recorded by Delphi (design seat). **Kai parks this now and declines even the cheap DID check** the map recommended. The answer is taken as near zero without measuring it. Building against it anyway, and chasing the four adjacent items, were both offered and rejected. **So this closes as reference rather than as work.** The map stands and is worth keeping - the architecture is genuinely different from everything else in the coilyco-bridge/deploy#418 sweep, and the reason is structural rather than cultural: > Atproto is open because enclosure is structurally hard. There is no key to revoke, because reading public repos is how the network works. And the one finding worth carrying into any future roster decision: > **When an atproto app dies, the data does not go with it**, because records live in the user's repo rather than the app's database. That is the first structural answer to the maintenance-risk problem, rather than a hope about maintainers. That matters more now than when this was written. #485 closed today - a bot cannot invoke another bot's application commands - so the Discord-native escape from single-author MCP dependencies is gone, and the dead-repo risk is unavoidable rather than sidestepped. Atproto remains the only surface reviewed that answers it by construction. **The signal that reopens this**, unchanged: members linking Bluesky accounts, or Atmosphere adoption growing enough that the intersection stops being empty. Someone should check for DIDs *then*, not now. **Unchanged and not widened by this close** - coilyco-bridge/deploy#358 grants Deep a bluesky-mcp scoped exclusively to Kai's own posts. That constraint stands. This issue asked a different question about Echo reading public records across the network, and the answer is not yet. **One thing that survives the park.** If Echo ever does read member records, that is reading a member's activity across other services. Public, and still worth a deliberate posture rather than doing it because the data is fetchable. Tier 3 under #179. Whoever reopens this should start there rather than with the integration.

coilyco-ops closed this issue

2026-08-15 20:18:15 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/sirens-echo#526

No description provided.

Rows
Columns