AT Protocol Ecosystem Repository Analysis#

Generated 2026-08-12 (rev. 2) · Reference document for future LLM sessions

1. Methodology#

Discovery. Seed sources: the psingletary.com Tangled profile, exosphere.site/airglow, rrcobb/atprotozoa, plus nekomimi.pet/wisp.place-monorepo (added rev. 2 — it is the source of the wisp.place hosting platform used by several repos in this set). Crawl rule: analysis stopped inside each repo once found; external sites referenced by repos were noted but not visited.

Access limitations (fields marked "unknown"). Tangled's web UI rendered READMEs and file trees but not raw package.json contents, so exact direct-dependency lists are unknown for zodiac, altifier, verifier, airglow, ATProtocol-Playground, and wisp.place-monorepo. atprotozoa was analyzed from its full file tree and README. Language attribution uses labels displayed on the Tangled repo listing plus observed file types.

2. Repository Inventory#

airglow — tangled.org/exosphere.site/airglow#

"Automations for the AT Protocol — listen to events, filter them, and trigger actions like webhook deliveries or PDS record creation"; connects to Jetstream, works like "IFTTT or Zapier, but the trigger side is always 'something happened on the AT Protocol.'"

• Language: TypeScript (primary)
• Framework/tooling: Bun runtime + Vite
• Hosting: self-hosted (env-var config: DATABASE_PATH for SQLite, JETSTREAM_URL, NSID allow/blocklists)
• Deployment: manual self-host; CI unknown
• AT Proto specifics: Jetstream consumer; custom lexicons in lexicons/ managed with goat; exact npm deps unknown

wisp.place-monorepo — tangled.org/nekomimi.pet/wisp.place-monorepo#

The platform behind wisp.place: hosts static sites inside an AT Protocol repository — the PDS is the source of truth (signed manifests + file blobs), and a hosting microservice watches the firehose to cache and serve sites via *.wisp.place subdomains or custom domains with CDN distribution.

• Languages: TypeScript (primary — backend + frontend), Rust (secondary — CLI)
• Frameworks: Elysia (main backend), Hono (hosting microservice), React 19 (frontend)
• Structure (one inventory entry, monorepo): apps/main-app (OAuth, site management, custom domains, React UI), apps/hosting-service (serves cached sites), cli/ (Rust: PDS uploads, firehose updates), packages/ (shared internals)
• Hosting: self-hosted service (it is the delivery platform); end-user deploys via wispctl / npm create wisp
• Deployment: CLI-driven uploads to the PDS; no CI/CD configs observed — unknown
• AT Proto specifics: ATProto OAuth; custom lexicons; PDS blobs as site storage; firehose consumer; Jacquard (Rust ATProto library) in the CLI; supports .wispignore and _redirects

atprotozoa — github.com/rrcobb/atprotozoa#

"A monorepo of ~200 tiny atproto experiments" — many small sites, each its own Cloudflare Worker at <name>.bisks.net, deployed on commit; many built by the @buildthis.bisks.net Bluesky bot ("tag it with an idea and it builds the site").

• Language: TypeScript (per-site src/index.ts Workers) + vanilla JavaScript front-ends
• Framework: none — hand-rolled static HTML + copied vanilla-JS libs; explicit "copy-don't-abstract" rule
• Hosting: Cloudflare Workers (wrangler.toml per site; apex/ front-door Worker for gallery + handle verification)
• Deployment: GitHub Actions deploy-on-commit (.github/workflows/deploy.yml, buildthis.yml); pnpm workspaces
• AT Proto specifics: hand-rolled per-site libs — lib/oauth.js + lib/oauth-jwt.js + public/client-metadata.json (ATProto OAuth), lib/atproto.js, lib/car.js (CAR parsing), lib/identity.js, lib/handle-typeahead.js; OG image generation via og-gen.mjs (+ @resvg); repo-wide audit/ health-check scripts

altifier — tangled.org/psingletary.com/altifier#

"Scans the image posts (app.bsky.feed.post records with app.bsky.embed.images) in your PDS, identifies images missing alt text, generates descriptions via AI, and lets you apply them by recreating your posts."

• Language: JavaScript · Framework: React ("fully static React SPA")
• Hosting/deploy: wisp.place via wispctl deploy, Tangled Sites (deploy dir /build), or any static host
• Deps: ATProto OAuth (src/contexts/AuthContext.js + public/client-metadata.json); Google Gemini 2.5 Flash; full package.json unknown

verifier — tangled.org/psingletary.com/verifier#

"A lightweight tool for creating and managing Bluesky verification records (app.bsky.graph.verification) on an account's PDS."

• Language: JavaScript · Framework: React, fully static SPA
• Hosting/deploy: static host (same pattern as altifier); deps/CI unknown

zodiac — tangled.org/psingletary.com/zodiac#

"Private astrology compatibility website… no accounts, no tracking, no data storage" — ATProto-adjacent (hosted via ATProto-native infra).

• Language: TypeScript · Framework: Next.js 16 (App Router) + Tailwind CSS v4, "fully static — zero server routes… deployable to any static host (Tangled, wisp, Vercel, S3, etc.)"
• Deploy/CI: manual static deploy; no CI configs found; deps unknown

daily-bsky-hype-vid — tangled.org/psingletary.com/daily-bsky-hype-vid#

"A daily, AI-produced hype video of your Bluesky mutuals' last 24 hours" — Claude Code fetches mutuals' posts, composes a soundtrack, renders a <60s vertical video.

• Language: Python (numpy, scipy, Pillow, ffmpeg; Claude Code)
• AT Proto access: raw public Bluesky AppView API, no auth, no SDK (fetch_bsky.py)
• Hosting/deploy: none — local, manual run

ATProtocol-Playground — tangled.org/psingletary.com/ATProtocol-Playground#

"Scripts for fooling around with ATProto and BSky.app"; dirs: docs/, js/, sample/, tests/; no manifest or CI files visible.

• Language: Python (primary), some JS · Hosting/deploy/deps: unknown/none

ptharbor — tangled.org/psingletary.com/ptharbor#

Migration of a small-business site (Point Harbor Signs) from Weebly to the AT Protocol stack: wisp.place hosting, Protobase.at managed PDS, Tangled git, Marque.at registrar — "a repeatable blueprint for migrating small businesses off Facebook/Instagram/WordPress/Wix to AT Protocol."

• Language: HTML · Framework: none (static port)
• Hosting: wisp.place (PDS-based static hosting); did:web identity files (did-web/, did.json at ptharbor.net)
• Deployment: manual scripts (scripts/ for key generation, deploy)

3. Ranked: Programming Languages (primary, one per repo; n=9)#

Notable secondary: Rust (wisp.place CLI).

4. Ranked: Website Delivery Platforms#

5. Ranked: Deployment Processes#

Note: Tangled offers native CI/CD via Spindle workflows (.tangled/workflows YAML, push/PR/manual triggers), but zero repos in this set were observed using it. See §8.2.

6. Ranked: Libraries (observed evidence only; most manifests unreadable — see Methodology)#

AT Protocol–specific:

General:

7. Aggregate Summary of AT Protocol Tools#

Categories observed: (a) PDS record tooling — altifier, verifier: static browser apps reading/writing records directly in the user's PDS; (b) event/automation infrastructure — airglow (Jetstream → actions); (c) hosting infrastructure — wisp.place: the PDS itself as a static-site origin, firehose-invalidated CDN cache in front; (d) micro-app factories — atprotozoa's bot pipeline (mention → LLM builds site → deploy-on-commit → Worker); (e) migration/identity tooling — ptharbor (did:web + managed PDS + wisp); (f) AppView-scraping content generators; (g) learning playgrounds.

Architectural patterns:

1. Static-first, serverless-second. Dominant shape: fully static SPA doing ATProto OAuth in-browser, talking directly to the user's PDS — no backend. Backends, where present, are a tiny Worker or a single Bun/TypeScript process with SQLite.
2. PDS as infrastructure primitive. wisp.place stores entire websites as PDS blobs with signed manifests; Tangled stores git and CI records (sh.tangled.* lexicons) in PDSes. The PDS is becoming the deployment target, not just the social-data store.
3. ATProto-native supply chain. Code on Tangled, hosting on wisp.place, identity via did:web/did:plc, managed PDS (Protobase.at) — a full stack that never touches traditional PaaS.
4. SDK avoidance in small projects. Copied single-file vanilla libs (OAuth, CAR parsing, identity resolution) or raw AppView calls instead of @atproto/api; atprotozoa codifies this as "copy, not extract." Infrastructure projects, by contrast, adopt real libraries (Jacquard).
5. LLM-in-the-loop development. buildthis bot, Claude Code pipelines, .hermes/plans/ agent-planned implementations.
6. Repeated OAuth boilerplate: every app re-ships client-metadata.json pinned to its domain, oauth.js/oauth-jwt.js, handle typeahead.

8. Recommendations: Tools That Need to Be Built#

Stack suggestions follow the rankings: TypeScript, static-first, wisp.place/Tangled or Cloudflare Workers hosting, vendorable vanilla-JS libs, Bun + SQLite for services.

1. create-atproto-app scaffolding CLI (the "project factory"). Problem: every app hand-assembles OAuth metadata, typeahead, deploy config. Stack: TypeScript CLI (Bun), templates for static SPA + optional Worker; emits client-metadata.json, wrangler.toml/wisp config, vendored single-file libs — and a .tangled/workflows/deploy.yml (see §8.2). (Directly serves the project-factory goal.)

2. Spindle adoption kit + hosted runners. (Revised after evaluating Tangled Spindle docs.) The earlier claim "Tangled lacks native CI/CD" is no longer true: Spindle workflows live in .tangled/workflows (YAML), trigger on push/pull_request/manual with branch/tag globs, run on Docker (nixery) or microVM engines, support repo secrets, and the docs include a working deploy-to-Cloudflare-Workers example and PDS artifact publishing. The real gap is adoption and infrastructure: (a) none of the four manually-deployed Tangled repos in this set use Spindle; (b) Spindle is a self-hosted Go runner service listening on Jetstream — most individual developers won't run one. What to build: ready-made workflow templates (especially deploy-to-wisp.place via wispctl, which doesn't exist as a documented example), and/or a community/hosted spindle offering so repos get CI without operating runner hosts. Stack: YAML templates + Go (spindle is Go) or a managed nixery-engine host.

3. Vendorable ATProto micro-library set. Problem: the "copy-don't-abstract" culture exists because @atproto/api is heavy for static SPAs; copied oauth.js/car.js/identity.js files drift and duplicate bugs across ~200 sites. Build audited, zero-dependency single-file ES modules (OAuth+DPoP, CAR reader, DID/handle resolution) designed to be copied. Stack: TypeScript → standalone ESM.

4. Non-destructive PDS record editor. (Expanded.) The problem in depth: altifier's only way to fix alt text is delete-and-recreate the post. Because the new record gets a new rkey, its at-uri changes, so every like, repost, reply, and quote — all of which point at the old at-uri (as a strongRef of uri + CID) — is orphaned. The user must choose between accessibility and their engagement history. What's missing is a general-purpose tool built around the safer primitives the protocol already has: com.atproto.repo.putRecord overwrites a record in place, preserving the rkey and at-uri (replies and likes keep resolving; only the CID changes); com.atproto.repo.applyWrites batches creates/updates/deletes atomically; com.atproto.sync.getRepo exports a full CAR backup before any mutation. Feature set: browse any collection in your PDS (not just app.bsky.*), edit records as validated JSON against their lexicon, show a dry-run diff of every proposed write, warn when an edit would change semantics AppViews index (e.g. createdAt), automatic pre-mutation CAR snapshot with one-click restore, and bulk find-and-replace across a collection. No tool in the analyzed set — or widely in the ecosystem — combines editing with backup/diff/undo safety rails; existing repo browsers are read-only, and writing tools (altifier, verifier) are single-purpose. Stack: static React/TypeScript SPA, ATProto OAuth, CAR parsing lib (§8.3), hosted on wisp.place.

5. Managed multi-tenant Jetstream automation. Problem: airglow is self-host-only. A hosted or one-click-deploy version (Workers + Durable Objects, or Bun+SQLite image) would open ATProto automations to non-operators.

6. Small-business migration toolkit. Problem: ptharbor proves the demand but is a manual one-off. Automate: site scrape → static port → wisp.place deploy → did:web generation → managed-PDS provisioning checklist. Stack: TypeScript CLI + template repo on Tangled. (See companion doc Migration_Toolkit_research.md.)

7. Fleet health dashboard for micro-sites. Problem: atprotozoa needed bespoke audit/ scripts. A reusable uptime/OAuth-metadata/handle-verification monitor for many small ATProto sites doesn't exist in this set. Stack: scheduled Worker + static dashboard.

8. OG-image service for ATProto apps. Problem: nearly every atprotozoa site bundles fonts + a per-site og-gen.mjs. A shared Worker rendering OG cards from URL params would delete hundreds of copies. Stack: Cloudflare Worker + resvg-wasm.

Caveat: Tangled's web UI does not expose raw manifests, so the library ranking (§6) remains the weakest section — @atproto/api/atcute usage in the TS/React apps is plausible but unverified.