Expose ticket waves on public event responses #66

Merged

padreug merged 1 commit from feat/public-ticket-waves into main

2026-09-29 06:58:37 +00:00

padreug commented

2026-09-29 06:15:06 +00:00

Owner

Prerequisite for wave support in the webapp. Refs #61.

Why

A buyer can't choose a ticket wave without its id, and nothing public carries one:

PublicEventExtra is EventExtraBase, which didn't include ticket_waves
the NIP-52 tags deliberately publish only the active wave, with no identifier (the flat-tag decision on #61)

So GET /events/{id} and /events/public handed a client everything except the one field it needs to say which tier it wants — while api_ticket_create refuses with "Please select a ticket wave" whenever several are open. Only the organizer, through the authenticated ?all_wallets=true listing, could see waves at all.

That makes a checkout wave picker impossible for anyone but the organizer, which blocks the webapp work.

What

Moves ticket_waves from EventExtra up to EventExtraBase, leaving promo_codes as the only organizer-private field in extra.

The judgement call

A TicketWave holds an id, title, date window, currency, price, remaining stock and the fiat flags. All of it is sales information a buyer needs in order to choose, and none of it is organizer-private the way promo codes are.

The one real consequence is that buyers can now see upcoming tiers and their prices before they open — "early bird until Friday, then €25". That is exactly what #61 recorded as the cost of settling on flat Nostr tags, so surfacing it over REST reads as a gain rather than a leak. Worth a second opinion at review, since it is a product decision rather than a technical one, and it is easy to reverse by projecting a narrower wave shape if you'd rather future pricing stayed hidden until it opens.

Tests

Two, pinning both ends of the projection: PublicEventExtra carries waves and never promo codes, and a serialised PublicEvent shows the same. 122 pass; ruff, black clean; mypy error set unchanged from baseline.

I also re-ran the field-ownership AST check from the rebase playbook after moving the field — the merge previously produced a silent reparenting of TicketWave into the wrong class, and this is the same kind of edit.

Sequencing

Independent of #65 (the wave-preservation guard), though both touch this area. Both want a release decision — main is already tagged v1.6.8-aio.1, so they either ride a v1.6.8-aio.2 together or wait for the next events release.

Prerequisite for wave support in the webapp. Refs #61. ## Why A buyer can't choose a ticket wave without its id, and nothing public carries one: - `PublicEventExtra` is `EventExtraBase`, which didn't include `ticket_waves` - the NIP-52 tags deliberately publish only the *active* wave, with no identifier (the flat-tag decision on #61) So `GET /events/{id}` and `/events/public` handed a client everything except the one field it needs to say which tier it wants — while `api_ticket_create` refuses with "Please select a ticket wave" whenever several are open. Only the organizer, through the authenticated `?all_wallets=true` listing, could see waves at all. That makes a checkout wave picker impossible for anyone but the organizer, which blocks the webapp work. ## What Moves `ticket_waves` from `EventExtra` up to `EventExtraBase`, leaving `promo_codes` as the only organizer-private field in `extra`. ## The judgement call A `TicketWave` holds an id, title, date window, currency, price, remaining stock and the fiat flags. All of it is sales information a buyer needs in order to choose, and none of it is organizer-private the way promo codes are. The one real consequence is that **buyers can now see upcoming tiers and their prices before they open** — "early bird until Friday, then €25". That is exactly what #61 recorded as the cost of settling on flat Nostr tags, so surfacing it over REST reads as a gain rather than a leak. Worth a second opinion at review, since it is a product decision rather than a technical one, and it is easy to reverse by projecting a narrower wave shape if you'd rather future pricing stayed hidden until it opens. ## Tests Two, pinning both ends of the projection: `PublicEventExtra` carries waves and never promo codes, and a serialised `PublicEvent` shows the same. 122 pass; ruff, black clean; mypy error set unchanged from baseline. I also re-ran the field-ownership AST check from the rebase playbook after moving the field — the merge previously produced a silent reparenting of `TicketWave` into the wrong class, and this is the same kind of edit. ## Sequencing Independent of #65 (the wave-preservation guard), though both touch this area. Both want a release decision — `main` is already tagged `v1.6.8-aio.1`, so they either ride a `v1.6.8-aio.2` together or wait for the next events release.

padreug added 1 commit

2026-09-29 06:15:06 +00:00

feat: expose ticket waves on public event responses

lint.yml / feat: expose ticket waves on public event responses (pull_request) Failing after 0s

Details

209a895415

A buyer cannot choose a ticket wave without its id, and nothing public
carried one: `PublicEventExtra` is `EventExtraBase`, which did not
include `ticket_waves`, and the NIP-52 tags deliberately publish only
the active wave with no identifier (#61). So `GET /events/{id}` and
`/events/public` gave a client everything except the one field it needs
to say which tier it wants — and the purchase endpoint refuses when
several waves are open.

Moves `ticket_waves` from `EventExtra` to `EventExtraBase`, leaving
`promo_codes` as the only organizer-private field in `extra`.

A wave holds an id, title, date window, currency, price, remaining stock
and the fiat flags — the sales information a buyer needs in order to
choose. The only thing publishing it reveals is the upcoming price
schedule, which is precisely what #61 recorded as the cost of settling
on flat Nostr tags; over REST it is a gain rather than a leak.

Prerequisite for wave support in the webapp, which otherwise cannot
offer a wave picker to anyone but the organizer.

Two tests pin the projection: the public extra carries waves and never
promo codes, and a serialised `PublicEvent` shows the same.

padreug referenced this pull request from a commit

2026-09-29 06:30:30 +00:00

feat(events): ticket-wave types and arithmetic

padreug referenced this pull request from a commit

2026-09-29 06:30:30 +00:00

feat(events): buy from a chosen ticket wave

padreug referenced this pull request from aiolabs/webapp

2026-09-29 06:30:52 +00:00

Ticket waves: manage them, buy from them, stop lying about totals #176

padreug merged commit 26c0a5c429 into main

2026-09-29 06:58:37 +00:00

padreug deleted branch feat/public-ticket-waves