Rebase fork onto upstream v1.6.8 (waves / on-chain / approval reconciliation) #33

New issue

Open

opened 2026-06-20 09:51:44 +00:00 by padreug · 0 comments

padreug commented

2026-06-20 09:51:44 +00:00

Owner

Tracking issue for the eventual rebase of this fork (based on upstream v1.6.1) onto upstream v1.6.8 — 7 releases ahead. Assessment done 2026-06-20.

Verdict

Well-positioned, not a fast-forward. The migration layer is clean by design; the work is a bounded manual merge of the purchase flow plus a one-time "adopt ticket waves" adaptation. Budget ~1 focused session.

Clean — carries over with zero/near-zero conflict

migrations.py is byte-identical to both v1.6.1 and v1.6.8 → migration rebase is a no-op. (Keep this invariant.)
No column collisions. Upstream's v1.6.8 features (ticket waves, on-chain/SatsPay, ticket images) serialize into existing extra JSON — no new DB columns. Our migrations_fork.py real columns (status, location, categories, nostr_event_id, nostr_event_created_at, payment_hash, user_id) are a separate namespace.
Net-new fork files (zero conflict): all nostr_*.py, transport_rpcs.py, nostr_sync.py, migrations_fork.py, tests.
set_ticket_paid survives in v1.6.8 (same name/signature) and is already wave-aware — our per-event lock + publish_or_delete_nostr_event() graft re-applies cleanly; tasks.py and the free-ticket path keep working.

Overlap — manual reconciliation (8 files; effort in 2)

File	upstream Δ	fork Δ	note
`views_api.py`	+440	+533	the hard one — both rewrote `api_ticket_create`
`models.py`	+126	+101	mostly additive fields
`services.py`	+291	+39	small graft re-applies
`crud.py`	+45	+183	mostly additive queries
`__init__.py`	+3	+77	small
`static/js/{index,display}.*`	large	medium	take upstream wholesale, re-apply minimal fork bits

Semantic adaptations to plan

Pricing moved into ticket waves. v1.6.8 reads selected_wave.price_per_ticket / .allow_fiat / .currency; our fork reads event.price_per_ticket (top-level fields still exist). Mechanical remap, but every pricing read in our additions (fiat, multi-ticket, free tickets) must thread through wave selection. Free tickets resolve to a wave or use the event-level fallback set_ticket_paid already supports.
Approval workflow is fork-only. v1.6.8 has no status/proposed/approve. Re-insert our events.status + api_event_approve + the api_ticket_create gate by hand into upstream's rewritten file.
On-chain/SatsPay is new upstream surface — decide whether to adopt; if yes, make our fiat/free/Nostr additions coexist with it.

Recommendations

Keep the fork-migrations discipline — it's why this is tractable.
The views_api.py gap only widens with each upstream release; rebase sooner if we want waves/on-chain, else cherry-pick specific upstream fixes.
#31 (free tickets) adds slightly to the gap but remaps trivially — not a reason to hold it.

Tracking issue for the eventual rebase of this fork (based on upstream **v1.6.1**) onto upstream **v1.6.8** — 7 releases ahead. Assessment done 2026-06-20. ## Verdict Well-positioned, **not** a fast-forward. The migration layer is clean by design; the work is a bounded manual merge of the purchase flow plus a one-time "adopt ticket waves" adaptation. Budget ~1 focused session. ## Clean — carries over with zero/near-zero conflict - `migrations.py` is **byte-identical** to both v1.6.1 and v1.6.8 → migration rebase is a no-op. (Keep this invariant.) - **No column collisions.** Upstream's v1.6.8 features (ticket **waves**, **on-chain/SatsPay**, ticket images) serialize into existing `extra` JSON — no new DB columns. Our `migrations_fork.py` real columns (`status`, `location`, `categories`, `nostr_event_id`, `nostr_event_created_at`, `payment_hash`, `user_id`) are a separate namespace. - Net-new fork files (zero conflict): all `nostr_*.py`, `transport_rpcs.py`, `nostr_sync.py`, `migrations_fork.py`, tests. - `set_ticket_paid` **survives** in v1.6.8 (same name/signature) and is already wave-aware — our per-event lock + `publish_or_delete_nostr_event()` graft re-applies cleanly; `tasks.py` and the free-ticket path keep working. ## Overlap — manual reconciliation (8 files; effort in 2) | File | upstream Δ | fork Δ | note | |---|---|---|---| | `views_api.py` | +440 | +533 | **the hard one** — both rewrote `api_ticket_create` | | `models.py` | +126 | +101 | mostly additive fields | | `services.py` | +291 | +39 | small graft re-applies | | `crud.py` | +45 | +183 | mostly additive queries | | `__init__.py` | +3 | +77 | small | | `static/js/{index,display}.*` | large | medium | take upstream wholesale, re-apply minimal fork bits | ## Semantic adaptations to plan 1. **Pricing moved into ticket waves.** v1.6.8 reads `selected_wave.price_per_ticket / .allow_fiat / .currency`; our fork reads `event.price_per_ticket` (top-level fields still exist). Mechanical remap, but every pricing read in our additions (fiat, multi-ticket, **free tickets**) must thread through wave selection. Free tickets resolve to a wave or use the event-level fallback `set_ticket_paid` already supports. 2. **Approval workflow is fork-only.** v1.6.8 has no `status`/`proposed`/`approve`. Re-insert our `events.status` + `api_event_approve` + the `api_ticket_create` gate by hand into upstream's rewritten file. 3. **On-chain/SatsPay is new upstream surface** — decide whether to adopt; if yes, make our fiat/free/Nostr additions coexist with it. ## Recommendations - Keep the fork-migrations discipline — it's why this is tractable. - The `views_api.py` gap only widens with each upstream release; rebase sooner if we want waves/on-chain, else cherry-pick specific upstream fixes. - #31 (free tickets) adds slightly to the gap but remaps trivially — not a reason to hold it.

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#33

No description provided.

Rows
Columns