Gap analysis from the five-subsystem set (acl/feed/flow/mod/search): - store-on-sx: event-sourcing foundation the others fake with in-memory lists (build first) - commerce-on-sx: catalog/cart/pricing/orders on miniKanren (+ store + flow) - identity-on-sx: OAuth2/sessions/membership on Erlang (the core acl assumes) - content-on-sx: documents/blocks/CRDT on Smalltalk - events-on-sx: calendar/ticketing on Datalog + flow-driven delivery - host-on-sx: the web boundary — off Quart onto native server+SXTP now, dream-on-sx next All DRAFT outlines; substrate choices proposed, not final. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.8 KiB
events-on-sx: Calendar, ticketing & notification delivery on Datalog
DRAFT outline. The events vertical + the shared notification-delivery edge. Depends on
store-on-sx(bookings ledger) andflow-on-sx(reminders, retrying delivery). Pairs withcommerce-on-sxfor paid tickets.
rose-ash's events domain is calendar + ticketing: recurring events, availability,
capacity, bookings. Scheduling is constraint reasoning — "is this slot free given
recurrence, capacity, and the attendee's other bookings?" — which is rule
evaluation over facts. Datalog expresses availability, recurrence expansion, and
capacity as rules; a booking is a transaction; reminders and digests are durable
flows. Notification delivery (email/push) — needed here and by feed/notify —
is folded in as an injected transport, extractable later.
End-state: a Datalog-on-SX events layer with recurrence expansion, availability + capacity rules, transactional booking, and a flow-driven notification dispatcher (reminders, digests, retries) over an injected transport.
Status (rolling)
bash lib/events/conformance.sh → 0/0 (not yet started)
Ground rules
- Scope: only
lib/events/**andplans/events-on-sx.md. May import fromlib/datalog/, and (once they exist)lib/store/+lib/flow/. Do not edit substrates. - Architecture: events/availability/capacity are Datalog facts + rules;
recurrence expands to occurrence facts within a window; a booking checks rules
then appends a
storeevent (idempotent, capacity-safe). Notifications are flows that suspend on transport IO and retry on failure. - Determinism: recurrence expansion + availability must be reproducible for a fixed window + ruleset; capacity checks must be race-safe (no overbooking).
- Commits: one feature per commit. Progress log + tick boxes.
Architecture sketch
Event + booking Result
event(id,start,rrule,capacity) {:booked | :full | :conflict} + reminders
│ ▲
▼ │
lib/events/calendar.sx lib/events/availability.sx
— event facts, recurrence (RRULE) — free/busy + capacity rules (Datalog)
— expand occurrences in window │
│ ▲
▼ │
lib/events/booking.sx lib/events/notify.sx (flow)
— transactional, capacity-safe — reminders / digests, retry on fail
— bookings → store ledger — injected transport (email/push)
│ │
▼ ▼
lib/events/api.sx ── (events/schedule) (events/book) (events/agenda) ──────┘
Phase 1 — Calendar + recurrence
calendar.sx— event facts, RRULE expansion in a windowavailability.sx— free/busy rulesapi.sx+ tests + scoreboard + conformance.sh
Phase 2 — Ticketing + booking
- capacity rules; transactional booking →
store(no overbooking) - paid tickets compose with
commerceorder flow - tests: capacity edge, double-book guard, conflict detection
Phase 3 — Notification delivery (flow)
notify.sx— reminder/digest flows over injected transport- retry/backoff on transport failure (flow suspend/resume)
- tests: delivery success, retry path, idempotent re-send
- NOTE: shared with
feed/notify— candidate for later extraction to adelivery-on-sxonce a second consumer is real
Phase 4 — Federation
- cross-instance events (peer calendar) — trust-gated stub
- tests: federated agenda merge
Progress log
(loop fills this in)
Blockers
(loop fills this in)