What this is

Answers is a Yahoo Answers-style Q&A site built entirely on ATProto. Every question, answer, comment, and vote is a portable record on the user's own Personal Data Server (PDS). There is no Answers-specific backend database. The site is a static frontend; writes are mediated by a shared OAuth worker; discovery piggybacks on a third-party backlink indexer.

The stack in one picture:

Architecture

Three things are moving parts here, and nothing else:

1. The static frontend at answers/ — plain HTML, ES modules, no build step. Deployed to Cloudflare Pages from this branch.
2. The shared OAuth worker at workers/auth/, hosted at auth.mino.mobi. Not owned by Answers — reused by sweat, music, labglass, and any other *.mino.mobi site that needs an authenticated PDS write path.
3. A publish workflow (publish-answers-categories.yml) that writes the curated category taxonomy to a canonical ATProto account, where everyone reads it from.

All state is on-chain (ATProto records). There's no "Answers database" — no question table, no user table, no vote count cache. The frontend recomputes totals on each view from records fetched at display time.

Lexicons

Six custom record types, all under NSID com.minomobi.answers.*. Schema files live in answers/lexicons/.

What's reused, not invented

• Follows — app.bsky.graph.follow as-is.
• Profiles / avatars — app.bsky.actor.profile.
• Moderation reports — com.atproto.moderation.createReport (flag UI is paused pending auth-worker proxy support).

What isn't a record at all

• Resolution state (open / in-voting / resolved). Derived client-side from whether the asker has published a bestAnswer record and how old the question is. No state transition record.
• Vote tallies, answer counts. Recomputed from Constellation backlinks at display time.
• Points, levels, reputation. Deliberately dropped for MVP to keep it frontend-plus-atproto only. No trusted server means no trusted leaderboard, and that's fine.

Categories

Category records are the source of truth for the taxonomy tree. They're published by the curator account (currently minomobi.com, resolved at runtime) and read directly by every client. Structure of a record:

{
  "$type": "com.minomobi.answers.category",
  "name": "Mental Health",
  "slug": "mental-health",
  "description": "...",
  "parent": {
    "uri": "at://did:plc:.../com.minomobi.answers.category/health",
    "cid": "..."
  },
  "createdAt": "2026-04-19T..."
}

rkey is the full dotted path of slugs (e.g. health.mental-health), making every category globally addressable and making the publish script idempotent.

Source of truth: answers/categories.json. Change it, push, and the workflow republishes.

Authentication

Answers does not implement OAuth itself. It uses the shared mino-auth worker at auth.mino.mobi, same pattern as sweat, music, and others.

1. User enters their handle and clicks Continue.
2. Frontend POSTs auth.mino.mobi/oauth/start with { handle, origin, returnTo }.
3. Auth worker does the ATProto PKCE / DPoP / PAR dance against the user's PDS, then redirects to Bluesky for authorization.
4. Bluesky redirects to auth.mino.mobi/oauth/callback, which hands back a session token by redirecting the user to their returnTo URL with ?__auth_session=<token> appended.
5. On page load, authInit() reads that query param, stores the token in localStorage, hits /api/me for { did, handle, scope }, resolves the user's PDS once, and caches everything.

All write requests then go to auth.mino.mobi/pds/repo/* with a bearer token. The worker attaches DPoP proofs (with nonce handling), forwards to the user's PDS, and returns the response. The frontend never touches DPoP keys.

Public reads still hit the user's PDS (or other users' PDSes) directly with no auth — no reason to round-trip through the worker for records that are public ATProto data.

Sign-out calls /api/logout to invalidate the token server-side, then clears localStorage.

Discovery

Answers live on the answerer's PDS, not the asker's. Without an indexer, there's a chicken-and-egg problem: how does the question page find all its answers?

Solution: Constellation, a relay that indexes strongRefs across the entire AT firehose. The question page queries:

GET constellation.us-east.host.bsky.network/links
  ?target=<question-uri>
  &collection=com.minomobi.answers.answer
  &path=.question.uri

…and gets back every answer record anywhere on ATProto whose question.uri field points at that question. Same pattern finds comments (on answers) and votes (on anything).

Fallback: if Constellation hasn't indexed yet, the frontend also calls listRecords on the signed-in user's own PDS and filters locally. That way you always see your own writes immediately, even during the indexer lag.

Writes

Every write routes through the auth worker's proxy:

Vote and bestAnswer use putRecord with a deterministic rkey (hash of the subject / question URI), so toggling and changing picks is idempotent: the same rkey either rewrites or gets deleted.

GitHub Actions

The publisher script is deliberately simple: flatten the taxonomy depth-first, write parents first so children can embed parent strongRefs, use the dotted slug path as rkey. Re-running is a no-op; editing categories.json and pushing is the only way to change the tree.

Deployment

LIVE This branch, claude/yahoo-answers-atproto-brainstorm-B6vUR, is wired to auto-deploy answers/ to Cloudflare Pages on every push. No dry-run branch, no staging. Every push ships.

The entry in CLAUDE.md under Hosting calls this out as a live-deploy branch so future sessions don't accidentally ship broken pushes.

Portability

Because everything is an ATProto record on the user's own PDS:

• Your writes follow you. If you stop using Answers, your questions and answers remain in your PDS. Any other client that understands the lexicons can render them.
• The site can disappear. answers.mino.mobi going down doesn't delete anything. Records are still fetchable, and a new frontend with the same lexicons would work against the same data.
• Account migration works. If a user moves PDSes, their records move with them — ATProto handles that at the protocol layer.
• There's no "signup." If you have a Bluesky account, you already have a place to store questions and answers.

Known limits (MVP)

• Search is stubbed. No full-text index yet. Browsing is by category + direct AT-URI links; the search bar currently pops an alert.
• No global "recent questions" feed. Discovery of others' questions requires an indexer we haven't built. The homepage shows your questions; shared question URLs let others answer.
• Flags are paused. UI removed until the shared auth worker proxies com.atproto.moderation.createReport.
• Constellation lag. Freshly posted answers/comments may take a moment to show up for non-authors while the relay indexes them. Local fallback covers authors' own views.
• No OAuth scope display. The site requests whatever scopes the auth worker asks for; we don't surface them yet.