feat(share-web): /<handle> profile + /me dashboard + sign-in

[graydawnc]

What

Three more public routes that turn a published share into an actual identity surface on spool.pro:

• GET /<handle> → <Profile>: someone else's public profile page. Lists their profile-listed shares. The /<handle> route is what unlisted shares deliberately don't appear in — visibility opt-in stays per-share.
• GET /me → <Me>: the signed-in user's dashboard. Claim or change handle (live availability check), see your live shares (revoke from here, copy-link, view), schedule or cancel account deletion. The desktop Settings → Account screen is a mirror of this — same primitives, same wire shape.
• GET /sign-in → <SignIn>: provider list, currently just Google. Same identity-first redesign as Me / Profile — one consistent visual surface across the three identity routes.

Plus the backend half:

• GET /api/profiles/<handle> — public endpoint that returns {name, avatar_url, shares: [...]}. Rate-limited 120/min/IP (anti-enumeration, but loose enough for legit reload). Returns 404 for both invalid-handle and missing-handle so a scanner can't tell the two apart.

Why one PR

The three routes share the same client API surface (api.ts's fetchMe, claimHandle, checkHandle, revokeShare, scheduleAccountDeletion, etc.) and the same identity visual system. Splitting them would mean each gets approved in a half-formed state. The backend /api/profiles/<handle> only matters once the renderer can hit it, so it lands here too.

A Profile page that exists but can't be reached because there's no Me dashboard for the user to claim a handle on first would be a dead end. A SignIn page that exists but doesn't lead anywhere is just a button.

Routes + ownership

flowchart LR
    subgraph public["public routes"]
        S["/s/<slug>"]
        P["/<handle>"]
        T["Tombstone"]
    end
    subgraph authed["authed routes"]
        ME["/me"]
        SI["/sign-in"]
    end
    subgraph api["share-backend"]
        SN["/api/snapshots/:id"]
        PR["/api/profiles/:handle"]
        M["/api/me"]
        MS["/api/me/shares"]
        H["/api/handles/*"]
        D["/api/me/delete"]
        OUT["/api/auth/sign-out"]
    end

    S --> SN
    P --> PR
    ME --> M
    ME --> MS
    ME --> H
    ME --> D
    ME --> OUT
    SI -. "/api/auth/google/start" .-> M

Loading

Profile page rules

• Lists profile-listed shares only. Unlisted shares are not enumerated under the handle even though the backend knows which handle owns them — the visibility opt-in is per-share, not per-account.
• SHARE_LIMIT = 100 on the backend. A handle with thousands of profile-listed shares paginates server-side; the v0.5 cutoff keeps the page lean and uncomplicated.
• released_at IS NULL on the handle query — released handles 404 immediately. If alex releases their handle and someone else claims it, the new account's profile is what /alex shows, not a frozen snapshot of the previous owner's shares.
• users.deleted_at IS NULL joined in — a deletion-pending user is still reachable; a fully-deleted user 404s.

Me dashboard state machine

stateDiagram-v2
    [*] --> Loading
    Loading --> Anonymous: GET /api/me returns 401
    Anonymous --> SignIn: click "Sign in"
    Loading --> NoHandle: 200, handle is null
    Loading --> Ready: 200, handle claimed
    NoHandle --> Claiming: submit handle form
    Claiming --> NoHandle: 409 / 422
    Claiming --> Ready: 200
    Ready --> Renaming: edit handle in place
    Renaming --> Ready: 200 (old handle released, new claimed)
    Renaming --> Ready: 409 (status banner, handle unchanged)
    Ready --> Deleting: click "Delete account"
    Deleting --> Ready: cancel modal
    Deleting --> Pending: confirm (POST /api/me/delete)
    Pending --> Ready: click "Keep my account"<br/>(DELETE /api/me/delete)
    Pending --> Tombstoned: 24h grace expired,<br/>worker ran (PR #360)

Loading

Handle availability — debounced, race-safe

sequenceDiagram
    autonumber
    participant U as User
    participant H as <Me> handle input
    participant API as /api/handles/check

    U->>H: "a"
    H->>H: debounce 320ms
    U->>H: "al"
    Note over H: timer reset on keypress
    U->>H: "alex"
    H->>API: GET ?handle=alex (seq=42)
    U->>H: "alexn"
    H->>API: GET ?handle=alexn (seq=43)
    API-->>H: alex → taken (seq=42, late)
    Note over H: seq < latest, drop
    API-->>H: alexn → available (seq=43)
    H-->>U: green check, "available"

Loading

The seq counter is what keeps an out-of-order response from stamping a stale "available" over a fresh "taken" when the user is typing fast. The desktop Settings → Account uses the same pattern with the same 320ms debounce — they're peer renderers of the same identity surface.

Anti-enumeration

/api/profiles/<handle> and /api/handles/check both return identical error shapes for "invalid format" and "not found":

Input	Response
/api/profiles/!@# (invalid format)	404
/api/profiles/ghostuser (valid but unclaimed)	404

If we returned 422 for invalid and 404 for missing, a scanner could trivially probe which handles are merely typoable vs which are real but unclaimed (interesting target for impersonation), or real and claimed (interesting target for harassment).

Verification

• pnpm --filter @spool-lab/share-backend test — profiles.test.ts (28 cases: valid + invalid + missing handle, rate limit trip, deleted user 404, released handle 404, profile-listed only, 100 cap, OWASP escape on name)
• pnpm --filter @spool/share-web test — api.test.ts (request shape), route.test.ts (handle vs slug ambiguity)
• Manual: claim handle on /me, hit /<my handle> in another tab, publish a profile-listed share, hit /<my handle> again; release handle, /<handle> 404s; schedule delete on desktop, refresh /me in web → pending banner with executeAt

Risk

/api/profiles/<handle> is public — it's the first endpoint that exposes user info to an unauthenticated visitor. The rate limit + 404-on-invalid + released_at IS NULL filters are the trust boundary. tests/_helpers/fakes.ts adds the two new SQL matchers needed by profiles tests without touching the existing ones.

Submitted by @graydawnc.