Rebase aio fork onto upstream v1.6.4 (ticket waves, ticket image, pagination) #18

New issue

Open

opened 2026-05-23 22:29:03 +00:00 by padreug · 0 comments

padreug commented

2026-05-23 22:29:03 +00:00

Owner

Context

Upstream lnbits/events landed three commits since v1.6.1
(currently at v1.6.4): one feature + two hotfixes, ~1865 lines
across 12 files. The feature is meaningful — ticket waves
(early-bird → general → late, each with its own opening/closing
date, capacity, price, currency, fiat config) plus per-event
ticket images and admin-side ticket pagination.

We deferred the rebase when shipping v1.6.1-aio.2 (which added
Nostr-driven inventory sync + multi-ticket purchases) because the
conflict surface is large and the aio fork had just finished its
own model-shaping work. This issue tracks the eventual catch-up.

Upstream commits to inherit

Commit	What
`777c107`	feat: UI fixes, ticket waves, ticket image (#52)
`8c1538f`	fix: no-submit-bug (hotfix on #52)
`35c20ed`	fix: another hot one (hotfix on #52)

New upstream shape (excerpt)

TicketWave model — id, title, opening_date, closing_date,
currency, use_ticket_image, ticket_image_id, allow_fiat,
fiat_currency, amount_tickets, price_per_ticket.
Event.ticket_waves: list[TicketWave] — the previous flat
event.amount_tickets / price_per_ticket / currency / allow_fiat / fiat_currency move into per-wave structures.
Ticket.ticket_wave_id + ticket_wave_title — each purchase
remembers its wave.
NotificationDeliveryResult + TicketResendResult — structured
resend response.
TicketFilters + crud.get_tickets_paginated — admin pagination.
static/image/ticket.jpg default.

Conflict surface with the aio fork

Our fork	Likely conflict
`nostr_publisher.py` — `tickets_available` / `tickets_sold` / `tickets_price` / `tickets_currency` / `tickets_allow_fiat` / `tickets_fiat_currency` tags	High. With multi-wave events, "which wave's counter goes in `tickets_available`" needs an answer. Options: (a) emit per-wave sub-tags like `tickets_wave:<id>:available`, (b) sum across active waves into the existing tags + add a single `tickets_waves` JSON tag, (c) only emit when there's exactly one wave. Decide before the rebase.
`services.set_ticket_paid` (sold/amount_tickets on Event)	High. Counters move per-wave; lock needs to be per-event-id (current) or per-wave-id (new). Probably stay per-event for simplicity since one paid invoice only ever lands on one wave.
`migrations_fork.m001` + `m002` (ticket.payment_hash)	Medium. Upstream's v1.6.4 adds new Ticket columns (`ticket_wave_id`, `ticket_wave_title`); these compose with our `payment_hash` cleanly but need to land in the right migration order.
`views_api.api_ticket_create` — multi-ticket loop, capacity check, quantity bound	High. Capacity check is per-wave. Multi-ticket purchases need a `ticket_wave_id` on the request, defaulting to the currently-open wave.
`views_api` republish endpoints (`/republish-all`, `/republish-mine`)	Low. Additive, should land cleanly.
`views_api` polling endpoint + `GET /tickets/user/{user_id}`	Low. Additive.
Webapp `Activity.ticketInfo` parsed from NIP-52 tags	Medium. Depends on the wave-tag decision above. May need to model "currently-open wave" client-side.

Decisions to make before rebasing

Wave-aware NIP-52 tags. Pick one of the three options above
(per-wave tags, summed + JSON, single-wave-only). Document in
webapp/CLAUDE.md "Payment rails pattern" section so the wire
contract stays explicit.
Multi-ticket + waves on the buy dialog. Does the buyer pick
a wave first, then quantity? Or is quantity per-wave (3 early
bird + 2 general)? Probably the former for v1 simplicity.
Catalog version after rebase. Per CLAUDE.md the new tag is
v1.6.4-aio.1 and the catalog entry version matches. This
restores the upstream-sort property in dev so clicking Upgrade
on the events extension doesn't wipe .git.

Out of scope for this issue

Backporting wave-aware Nostr tags to non-AIO clients — they ignore
unknown tags by NIP-52 spec.
Wave-image rendering on the webapp side. Phase 2 after the model
rebase lands.

Mitigation while deferred

Dev catalog has 1.6.1-aio.2 < upstream 1.6.4. Don't click
Upgrade on the events extension in regtest — it'll extract
upstream's zip into ~/dev/shared/extensions/events/ and wipe our
.git. Recover via git clone over the dir if it happens.

Production isn't at risk (the prod manifest is AIO-only).

## Context Upstream `lnbits/events` landed three commits since v1.6.1 (currently at v1.6.4): one feature + two hotfixes, ~1865 lines across 12 files. The feature is meaningful — **ticket waves** (early-bird → general → late, each with its own opening/closing date, capacity, price, currency, fiat config) plus per-event ticket images and admin-side ticket pagination. We deferred the rebase when shipping `v1.6.1-aio.2` (which added Nostr-driven inventory sync + multi-ticket purchases) because the conflict surface is large and the aio fork had just finished its own model-shaping work. This issue tracks the eventual catch-up. ## Upstream commits to inherit | Commit | What | |---|---| | `777c107` | feat: UI fixes, ticket waves, ticket image (#52) | | `8c1538f` | fix: no-submit-bug (hotfix on #52) | | `35c20ed` | fix: another hot one (hotfix on #52) | ## New upstream shape (excerpt) - `TicketWave` model — `id`, `title`, `opening_date`, `closing_date`, `currency`, `use_ticket_image`, `ticket_image_id`, `allow_fiat`, `fiat_currency`, `amount_tickets`, `price_per_ticket`. - `Event.ticket_waves: list[TicketWave]` — the previous flat `event.amount_tickets / price_per_ticket / currency / allow_fiat / fiat_currency` move into per-wave structures. - `Ticket.ticket_wave_id` + `ticket_wave_title` — each purchase remembers its wave. - `NotificationDeliveryResult` + `TicketResendResult` — structured resend response. - `TicketFilters` + `crud.get_tickets_paginated` — admin pagination. - `static/image/ticket.jpg` default. ## Conflict surface with the aio fork | Our fork | Likely conflict | |---|---| | `nostr_publisher.py` — `tickets_available` / `tickets_sold` / `tickets_price` / `tickets_currency` / `tickets_allow_fiat` / `tickets_fiat_currency` tags | **High.** With multi-wave events, "which wave's counter goes in `tickets_available`" needs an answer. Options: (a) emit per-wave sub-tags like `tickets_wave:<id>:available`, (b) sum across active waves into the existing tags + add a single `tickets_waves` JSON tag, (c) only emit when there's exactly one wave. Decide before the rebase. | | `services.set_ticket_paid` (sold/amount_tickets on Event) | **High.** Counters move per-wave; lock needs to be per-event-id (current) or per-wave-id (new). Probably stay per-event for simplicity since one paid invoice only ever lands on one wave. | | `migrations_fork.m001` + `m002` (ticket.payment_hash) | **Medium.** Upstream's v1.6.4 adds new Ticket columns (`ticket_wave_id`, `ticket_wave_title`); these compose with our `payment_hash` cleanly but need to land in the right migration order. | | `views_api.api_ticket_create` — multi-ticket loop, capacity check, quantity bound | **High.** Capacity check is per-wave. Multi-ticket purchases need a `ticket_wave_id` on the request, defaulting to the currently-open wave. | | `views_api` republish endpoints (`/republish-all`, `/republish-mine`) | **Low.** Additive, should land cleanly. | | `views_api` polling endpoint + `GET /tickets/user/{user_id}` | **Low.** Additive. | | Webapp `Activity.ticketInfo` parsed from NIP-52 tags | **Medium.** Depends on the wave-tag decision above. May need to model "currently-open wave" client-side. | ## Decisions to make before rebasing 1. **Wave-aware NIP-52 tags.** Pick one of the three options above (per-wave tags, summed + JSON, single-wave-only). Document in webapp/CLAUDE.md "Payment rails pattern" section so the wire contract stays explicit. 2. **Multi-ticket + waves on the buy dialog.** Does the buyer pick a wave first, then quantity? Or is quantity per-wave (3 early bird + 2 general)? Probably the former for v1 simplicity. 3. **Catalog version after rebase.** Per CLAUDE.md the new tag is `v1.6.4-aio.1` and the catalog entry version matches. This restores the upstream-sort property in dev so clicking Upgrade on the events extension doesn't wipe `.git`. ## Out of scope for this issue - Backporting wave-aware Nostr tags to non-AIO clients — they ignore unknown tags by NIP-52 spec. - Wave-image rendering on the webapp side. Phase 2 after the model rebase lands. ## Mitigation while deferred Dev catalog has `1.6.1-aio.2` < upstream `1.6.4`. Don't click Upgrade on the events extension in regtest — it'll extract upstream's zip into `~/dev/shared/extensions/events/` and wipe our `.git`. Recover via `git clone` over the dir if it happens. Production isn't at risk (the prod manifest is AIO-only).

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

aiolabs/events#18

No description provided.

Rows
Columns