simocracy-v2 · profile-page

Profile pages — Bluesky-interoperable user profiles

@daviddao

A new /profile/<did> page reads + writes app.bsky.actor.profile on the user's PDS so it stays interoperable with Bluesky and any other AT-Protocol-aware client. End-to-end run hit two real PDS profiles, the 404 path, and a mobile breakpoint; the layout works and one visual bug was spotted and fixed mid-run.

Date: 2026-04-30 · pass · Target: http://127.0.0.1:3007/profile/<did> (local npm run dev)

---

Headline result

What was tested

1. Profile with banner + long bio + sims + events — @daviddao.org: 4 sims, 2 events (1 admin, 1 council seat).
2. Profile with no banner, short bio, sims + events — @simocracy.climateai.org (the facilitator): 5 sims, 3 events (2 admin, 1 council seat).
3. Invalid actor — /profile/foobar: must 404, not crash, not show a half-rendered shell.
4. Mobile (390×844) — layout reflows cleanly, hero stacks, sim/event cards become single column.
5. Card navigation — clicking a sim card navigates to /sims/<did>/<rkey>; clicking an event card navigates to its gathering page.
6. Lexicon contract — the same record we read via com.atproto.repo.getRecord on the facilitator's PDS is the one the Edit dialog writes back via /api/records.

The visual bug we caught and fixed

Walkthrough

Lexicon — the one Bluesky reads is the one we write

The contract that makes this interoperable, not just “a profile-shaped thing”: the page edits the exact app.bsky.actor.profile/self record that bsky.app, deer.social, tangled, etc. all read. We confirmed by curl-ing the facilitator’s own PDS:

$ curl -s 'https://simocracy.climateai.org/xrpc/com.atproto.repo.getRecord?\
    repo=did:plc:awtx57rxuisy4sf4kzzr3uhf&\
    collection=app.bsky.actor.profile&\
    rkey=self' | jq '.value | {displayName, description, avatar: .avatar.ref."$link"}'
{
  "displayName": "Simocracy",
  "description": null,
  "avatar": "bafkreibxzvcztohjohprogt4pmgutocxafcyzwct3qt7ddpo6rk3eynpbq"
}

The avatar CID matches what public.api.bsky.app/xrpc/app.bsky.actor.getProfile returns, which is what the page renders. Save flow:

1. Owner picks a new image → POST /api/upload-blob on their own PDS, gets back a blob ref.
2. Server reads the existing app.bsky.actor.profile/self record so unknown fields (pronouns, website, labels, joinedViaStarterPack, pinnedPost) survive the round-trip.
3. PUT /api/records with collection: "app.bsky.actor.profile", rkey: "self", and the merged record. The new allow-list entry on app/api/records/route.ts is what permits the write.

Findings

Reproducing