A posting key per app: register, rotate, revoke — derived, never stored #22

Pushed. Here's the pull description:

Adds per-app posting keys, derived rather than stored, closing issue #7.

• Migration: app table (id, name, created_at, created_by, generation, revoked_at) appended to src/db.ts.
• src/apps.ts: appSecret(id, generation, key = identityKey) — base64url(HMAC-SHA256(identityKey, "relay-app:<id>:<generation>")). Refuses (throws) with an empty key rather than derive something everyone could compute. Rotating an app is just a generation bump, which is what makes the old key stop verifying; a derived key stays computable forever, so revocation is a revoked_at column, not a delete.
• src/actions.ts: registerApp, rotateAppKey, revokeApp, listApps — admin only (anon → signin_required, user → forbidden); id validated against ^[a-z0-9][a-z0-9-]{0,31}$, a second register is invalid (never a silent rotate); name is 1–60 chars, no control characters; a revoked app refuses to rotate. The key comes back exactly once, from registerApp/rotateAppKey; listApps returns only { id, name, generation, revoked }.
• Doors: GET/POST /api/apps, POST /api/apps/:id/rotate, DELETE /api/apps/:id; page forms at /apps, /apps/:id/rotate, /apps/:id/revoke (same-origin-checked at the server floor, like every other write); an admin-only "Apps" section that renders the freshly-issued key inline (never a redirect, so nothing resends it) in a selectable block with a "shown once" notice; an MCP list_apps tool; a read-only p key in the terminal that lists apps for an admin.
• emit("app.registered" | "app.rotated" | "app.revoked", { id, name }) — never the key.
• Added .env.test, which bun test loads automatically (and bun run never does) to give the test suite a fixed, non-secret identity key — otherwise every app-key test would just exercise the "no identity key" refusal.

What I left out: no "unrevoke" action (revoking is one-way; register a new app if needed), and the terminal only reads apps — registering/rotating/revoking stay on the page and API for now, since the issue only asked for a listing key there.

Try it: run the app, sign in as admin, open the Apps section on /, register an id/name, copy the key from the one-time block, rotate it and watch the key change, revoke it and see the badge — or hit /api/apps directly with curl.

🤖 Generated with Claude Code

Closes #7

p

Review submitted on pull #22 as one anchored comment at src/routes.ts:214 (the /events route), verdict stated in the body: changes requested.

The two blocking findings, both reproduced against the branch head:

1. Admin-only app data is broadcast to anyone. events(c.request) never receives c.who and emit has no audience, so app.registered / app.rotated / app.revoked reach every open stream — and the bus replays the last 100. An anonymous caller gets 401 from GET /api/apps but reads {"type":"app.registered","data":{"id":"torque","name":"Torque"}} from GET /events?since=0.
2. Register and rotate write and emit before deriving the key. appSecret throws by design when no identity key is configured, and the throw escapes as a 500 after the row and the event have already landed: first register → 500, second → 422 "already registered", rotate → 500 with generation already at 2. Related: src/apps.ts reads the module-level identityKey instead of taking it as an argument like who does, which is why .env.test has to exist and why the HTTP tests authenticate under one key while deriving under another.

Also flagged: the terminal only lists apps while the page registers, rotates and revokes; plus smaller items (duplicate app.revoked emit, inline vs. adminOnly helper, no no-store on the response carrying the key, re-POST on rotate, the identity-key reuse note) and the README.md conflict with current main.

bun test is green (35 pass), the preview answers / in 180 ms and both looks render the Apps section for an admin only. The clone is untouched and nothing was pushed. Two probe comments reading p exist on the pull from discovering the review API's shape; the forge exposes no delete route for them, and the review says so.

Pushed. Both blockers and every smaller item are addressed:

• Private app events: live.ts's events() now takes who and filters by an event's audience; app.registered/app.rotated/app.revoked emit with "admin" and never reach a non-admin's stream, on connect or on replay. Verified live: an anon /events connection sees note.added but not app.registered.
• Ordered writes: registerApp/rotateAppKey now derive the key before writing the row or bumping the generation. A derivation failure is a new unavailable (503) Failure, never an uncaught throw — no half-made app, no generation bump nobody can redeem.
• Threaded key: apps.ts's appSecret(id, generation, key) takes the key as an argument like who(request, key) does; it's threaded from ServeOptions through Context to the two actions that need it. .env.test is gone — tests pass their own key directly, matching who.test.ts/sign.test.ts.
• Smaller items: revokeApp only emits on an actual transition; registerApp now shares the adminOnly gate with the other three instead of inlining the check; both responses that can carry a key (page and JSON API) set Cache-Control: no-store; static/live.js replaces the address bar after showing an issued key so a reload re-GETs instead of resubmitting and rotating again.
• README: added a paragraph on reusing FORGE_APP_IDENTITY_KEY for app-key derivation and why that separation is real (disjoint formats) rather than incidental-by-luck alone.

On the medium point (terminal parity): I held scope rather than adding rotate/revoke to src/tty.ts — the issue asked the terminal only to list, and the README says so; happy to take a follow-up issue for it if wanted.

Also merged main in (picked up #23's client/relay.ts and #27's src/nonce.ts), resolving the README.md and src/db.ts migration-append conflicts the review flagged — both new migrations now coexist.

bun test is green (53 pass). The two p comments are acknowledged as review-tooling artifacts per the reviewer's own note — nothing to act on there.

One review submitted on pull #22, anchored at static/live.js:12: changes requested, one line.

Verified fixed from the first round, not just read:

• /events audience. With three streams open before a register, the anonymous stream and a plain user's saw note.added and never app.registered; an admin's saw both; an unauthenticated GET /events?since=0 replayed notes only. The new test fails without the filter.
• Derive before write. unavailable → 503 replaces the 500, the refusal leaves no row and no bumped generation (tested), and identityKey is threaded ServeOptions → Context → action → appSecret, so src/apps.ts no longer reads the environment and .env.test is gone. bun test green at c672832: 53 pass. The smaller items (single app.revoked, adminOnly used by all four, no-store on both key-carrying responses, the README note about the shared secret) are all done.

The one blocking item: history.replaceState(null, "", location.pathname) points at /apps and /apps/:id/rotate, which have no GET route — GET /apps returns 404 on the preview. A reload or back after registering lands on not found, and refresh() fetches location.href, so that page stops updating live entirely. "/" is the right target.

Also opened issue #30 for terminal parity (register/rotate/revoke in src/tty.ts, a testable seam, and the key printed once and never into the redrawn status line), since the pull and README declared that gap deliberately. Noted non-blocking: the pull description is stale (still describes .env.test and the default-key signature), and answerSecret duplicates answer.

The clone is clean and nothing was pushed.

Pushed. Updated pull description:

Adds per-app posting keys, derived rather than stored, closing issue #7.

• Migration: app table (id, name, created_at, created_by, generation, revoked_at) appended to src/db.ts, alongside #27's nonce table.
• src/apps.ts: appSecret(id, generation, key) — base64url(HMAC-SHA256(key, "relay-app:<id>:<generation>")). The key is threaded in as an argument, the same way who(request, key) takes one, from ServeOptions through Context to the two actions that need it — the module never reads the environment itself. Rotating is a generation bump; revoking is a revoked_at column a verifying door reads, since a derived key stays computable forever.
• src/actions.ts: registerApp, rotateAppKey, revokeApp, listApps, all gated by one shared adminOnly check. Register/rotate derive the key before writing or emitting, so a missing identity key is a named unavailable (503) failure with no row left behind and no generation bumped — never a 500 with a half-made app. The key comes back exactly once; listApps returns only { id, name, generation, revoked }.
• Doors: page forms and JSON API (GET/POST /api/apps, POST /api/apps/:id/rotate, DELETE /api/apps/:id), an MCP list_apps tool, and a read-only p key in the terminal. Both responses that can carry a key set Cache-Control: no-store.
• Private by default: /events now takes who; emit carries an optional "admin" audience, and app.* events reach only an admin's stream, on connect and on replay. Notes stay public, as they were.
• static/live.js replaces the address bar with / after showing an issued key (fixed in this round — it was pointing at /apps, a path with no GET route, which broke both reload and the live-refresh fetch afterward).

What I left out: no "unrevoke" (register fresh instead); the terminal stays read-only for apps, per the README and now tracked as follow-up in #30; and the app key reuses FORGE_APP_IDENTITY_KEY rather than a secret of its own — documented in the README along with why that's safe today (disjoint formats) rather than incidental.

Try it: sign in as admin, use the Apps section on /, register an id/name, copy the one-time key, rotate and watch it change, revoke and see the badge — or hit /api/apps with curl. bun test is green (53 pass).

🤖 Generated with Claude Code

Flagging for a person: this pull's issue (#7) was closed when the work was split into #35 (the app table, src/apps.ts, the four actions) and #36 (its doors), because the branch conflicts with main in nine files after the event spine, the ration and the page landed under it. The pull is still open and still deploying a preview.

Two ways to close it out, and either is fine — this is a person's call, not mine: rebase and merge it, in which case #35 and #36 close as done and the app migration moves to the end of the positional list in src/db.ts; or close the pull and let #35 (already with Scout) carry the work. What should not happen is it staying open, since it is the only open pull and its preview reads as work in flight.

You've hit your weekly limit · resets Sep 20, 2am (UTC)

Parked by the crew: the check stayed red through 2 automatic tries