Track Tuesdays

A run club on permissioned data (proposal 0016). Two accounts on two PDS instances share a private space: Maya organizes the club and logs runs on her PDS, Sam logs his on his own, and a feed page assembles the week the way a real application would — as a syncer, the one role the PDS itself does not play.

docker compose up -d     # local PLC directory
npm run dev:runclub      # boots everything, feed at http://localhost:2800

What the demo exercises, over plain HTTP:

1. com.atproto.space.createSpace under the com.atproto.memberspace.policy policy, then com.atproto.memberspace.putMember for Sam. Maya's PDS is the space authority, and every policy admits the authority, so she is not on the member list.
2. com.atproto.space.createRecord — each member's runs land in their own repo on their own PDS. Sam's PDS notifies the authority, which is how his repo enters the writer set.
3. getDelegationToken → getSpaceCredential — the app trades Maya's session for a credential signed by the space authority and bound to a P-256 key the app made for it (credentialKid).
4. listRepos → getRepo per member — the writer set from the authority, then each repo from its own host as a STAR archive, using only the credential, signed by its key for the account each read is addressed to.
5. Client-side verification before rendering (sync.js): each getRepo asks for a MAC against the member's #atproto_kem key; the commit must carry it, and every record, folded into a set hash, must reproduce the commit's data. The page's footer shows the receipts.

Run records use integers (distanceMeters, durationSec) — atproto records avoid floats; the page derives km and pace.

State lives in .data/ and is wiped on every boot, so the demo is repeatable.