side-quest: /side-quest:signup — generate a keypair, register a display name, enroll in the leaderboard #2

New issue

Open

opened 2026-08-27 15:18:19 +00:00 by trtmn · 0 comments

trtmn commented

2026-08-27 15:18:19 +00:00

Owner

Companion to #1 (public XP leaderboard). Before a player can appear on the leaderboard they need an identity: a keypair whose public half the leaderboard verifies against, and a display name.

`/side-quest:signup` flow

Generate a keypair if one does not already exist. Default to a dedicated ed25519 key at ~/.claude/side-quest/id_ed25519 — not the user's main ~/.ssh/id_ed25519; keep the game's signing key separate and single-purpose. ssh-keygen -t ed25519 -N "" -f ~/.claude/side-quest/id_ed25519 -C "side-quest:<name>".
Ask for a display name (via the command's prompt). This is what shows on the leaderboard. Validate: trimmed, length-capped, printable.
Register with the server: POST /signup with {name, pubkey} plus a signature over that payload by the new private key (proof of key possession). Server stores name -> pubkey and returns a player id.
Persist locally: ~/.claude/side-quest/identity.json = {player_id, name, pubkey_path}. xp.sh leaderboard-submit reads this.
"Sign in": once the keypair is registered there is no session or password — every later leaderboard-submit is authenticated by signature. "Sign in to the server" == the one-time registration; after that the key is the credential.

Open questions

Identity vs. Forgejo — the core design fork. #1 proposes trust-rooting pubkeys in Forgejo's https://git.trtmn.io/<user>.keys, which assumes every player has a Forgejo account.
- Forgejo-rooted: no separate name registry; <user>.keys is the trust source; signup verifies you control a Forgejo account and registers the game key against your username. Closed to the Forgejo org.
- Self-serve (TOFU): the leaderboard server owns the name -> pubkey table; first registration of a name wins; open to anyone; needs its own abuse handling.
Key location: dedicated ~/.claude/side-quest/id_ed25519 (recommended) vs. reuse ~/.ssh/id_ed25519.
Name collisions: reject, or auto-suffix (matt, matt#2)?
Rotation / rename: allow re-running signup to change the display name or rotate the key (new request signed by the old key)?
Multi-machine: identity is per-person, not per-machine — signup on one machine, then copy identity.json + the key to the others (or re-run signup pointing at the existing key). Document this.
Command shape: new commands/signup.md invoking an xp.sh signup subcommand that does the keygen, name prompt, signed registration POST, and local persistence.

Scope

commands/signup.md + xp.sh signup, the server-side /signup endpoint (shared infra with #1), local identity persistence, and docs. Depends on #1's hosting decision.

Related: #1.

Companion to #1 (public XP leaderboard). Before a player can appear on the leaderboard they need an identity: a keypair whose public half the leaderboard verifies against, and a display name. ## `/side-quest:signup` flow 1. **Generate a keypair** if one does not already exist. Default to a dedicated ed25519 key at `~/.claude/side-quest/id_ed25519` — not the user's main `~/.ssh/id_ed25519`; keep the game's signing key separate and single-purpose. `ssh-keygen -t ed25519 -N "" -f ~/.claude/side-quest/id_ed25519 -C "side-quest:<name>"`. 2. **Ask for a display name** (via the command's prompt). This is what shows on the leaderboard. Validate: trimmed, length-capped, printable. 3. **Register with the server**: `POST /signup` with `{name, pubkey}` plus a signature over that payload by the new private key (proof of key possession). Server stores name -> pubkey and returns a player id. 4. **Persist locally**: `~/.claude/side-quest/identity.json` = `{player_id, name, pubkey_path}`. `xp.sh leaderboard-submit` reads this. 5. **"Sign in"**: once the keypair is registered there is no session or password — every later `leaderboard-submit` is authenticated by signature. "Sign in to the server" == the one-time registration; after that the key *is* the credential. ## Open questions - **Identity vs. Forgejo — the core design fork.** #1 proposes trust-rooting pubkeys in Forgejo's `https://git.trtmn.io/<user>.keys`, which assumes every player has a Forgejo account. - **Forgejo-rooted:** no separate name registry; `<user>.keys` is the trust source; signup verifies you control a Forgejo account and registers the game key against your username. Closed to the Forgejo org. - **Self-serve (TOFU):** the leaderboard server owns the name -> pubkey table; first registration of a name wins; open to anyone; needs its own abuse handling. - **Key location:** dedicated `~/.claude/side-quest/id_ed25519` (recommended) vs. reuse `~/.ssh/id_ed25519`. - **Name collisions:** reject, or auto-suffix (`matt`, `matt#2`)? - **Rotation / rename:** allow re-running signup to change the display name or rotate the key (new request signed by the old key)? - **Multi-machine:** identity is per-person, not per-machine — signup on one machine, then copy `identity.json` + the key to the others (or re-run signup pointing at the existing key). Document this. - **Command shape:** new `commands/signup.md` invoking an `xp.sh signup` subcommand that does the keygen, name prompt, signed registration POST, and local persistence. ## Scope `commands/signup.md` + `xp.sh signup`, the server-side `/signup` endpoint (shared infra with #1), local identity persistence, and docs. Depends on #1's hosting decision. Related: #1.

trtmn added the

CR3

labels

2026-08-27 15:18:19 +00:00

trtmn referenced this issue

2026-08-27 17:31:02 +00:00

side-quest 2.4.0 → 2.5.0 (recovery: landed on the GitHub mirror by mistake) #3