Activities: show ticket buyer's username + npub in the hoster scan list #117

New issue

Open

opened 2026-06-17 17:11:01 +00:00 by padreug · 0 comments

padreug commented

2026-06-17 17:11:01 +00:00

Owner

From the 17 Jun design review: the event hoster's Tickets list (ScanTicketsPage) should show the buyer's username (it currently shows their id/npub), and per follow-up, also show the npub.

Why it's not webapp-only

The hoster roster comes from GET /events/api/v1/tickets/event/{id}/stats, whose per-ticket shape is just:

{ id, name, registered, registered_at }

name is "holder display name from the backend, if any" — in practice the npub/id (per the review). There's no pubkey, npub, or username field, so the webapp can't resolve or display either reliably (treating name as an npub is fragile — it may be a friendly name, an id, an npub, or null).

Proposed fix

aiolabs/events backend: include the buyer's pubkey (and, if available, username) on each ticket in the stats endpoint (and ideally the register endpoint, which already has user_id/email).
Webapp: add pubkey/username to EventTicket (useTicketScanner), and in the scan list row show the username as the primary label with the npub (nip19.npubEncode(pubkey), truncated) beneath — falling back to the current name when absent. Could also resolve a display name via ProfileService from the pubkey.

Deferred from the 17 Jun review batch: backend-dependent, not a clean webapp-only PR.

From the 17 Jun design review: the event hoster's Tickets list (ScanTicketsPage) should show the buyer's **username** (it currently shows their id/npub), and per follow-up, **also show the npub**. ## Why it's not webapp-only The hoster roster comes from `GET /events/api/v1/tickets/event/{id}/stats`, whose per-ticket shape is just: ``` { id, name, registered, registered_at } ``` `name` is "holder display name from the backend, if any" — in practice the npub/id (per the review). There's **no pubkey, npub, or username** field, so the webapp can't resolve or display either reliably (treating `name` as an npub is fragile — it may be a friendly name, an id, an npub, or null). ## Proposed fix 1. **`aiolabs/events` backend:** include the buyer's `pubkey` (and, if available, `username`) on each ticket in the stats endpoint (and ideally the register endpoint, which already has `user_id`/`email`). 2. **Webapp:** add `pubkey`/`username` to `EventTicket` (`useTicketScanner`), and in the scan list row show the username as the primary label with the npub (`nip19.npubEncode(pubkey)`, truncated) beneath — falling back to the current `name` when absent. Could also resolve a display name via ProfileService from the pubkey. _Deferred from the 17 Jun review batch: backend-dependent, not a clean webapp-only PR._

padreug referenced this issue from aiolabs/events

2026-06-17 17:12:37 +00:00

Surface ticket buyer npub (nostr_identifier) in the event stats endpoint #25

padreug added the

app:activities

enhancement

labels

2026-06-17 17:17:45 +00:00