# EventSnap — Ideas & Future Extensions

A dumping ground for design ideas that are **not yet on the roadmap**. Everything here is a
v2+ candidate, brainstormed once the core experience is stable. For shipped or actively
planned scope see [FEATURES.md](FEATURES.md) and the `CONCEPT_*.md` design docs.

The bar to land here is low: "would be cool one day" qualifies. The bar to graduate to a
`CONCEPT_*.md` is much higher (design committed, ready to build).

---

## Diashow extensions

### Global / synchronised diashow

Multiple devices show **the same slide at the same time** (e.g. a projector in the main
hall plus tablets behind the bar plus a screen by the photo booth).

Sketch:
- Server holds a single authoritative "current slide" cursor for the event.
- New SSE event `diashow-tick` broadcasts `{ slide_id, started_at, next_at }`.
- Each subscribed client renders locally — server only chooses ordering and pace.
- Live-queue / shuffle-queue logic (see [CONCEPT_DIASHOW.md](CONCEPT_DIASHOW.md)) lives
  server-side instead of client-side.
- A "leader device" can claim the diashow, or the server runs it head­lessly. Host UI lets
  Host start / stop the global diashow.
- Plays well with venues that already have multiple displays — no need for HDMI splitters
  or chromecast hacks.

### Audio bed

- Host uploads or selects a background track (per-event).
- Videos in the diashow auto-mute so they don't fight the music.
- Optional ducking when a video has speech.

### Curated diashow mode

- Diashow filtered by a hashtag (`#highlights`) or to a Host-pinned set ("Story" feature).
- Useful for the end-of-evening recap reel.

### Animation pack

- More transitions out of the box: zoom, slide, mosaic, dip-to-black, push.
- Per-event "theme" preset — wedding-elegant, party-energetic, minimal, gallery-classic.
- Builds on the maintainability principle below: each transition is a drop-in Svelte
  component, so growing the pack is trivial.

### Lower-third metadata

- Subtle chyron at the bottom of each slide: uploader name + timestamp + caption.
- Off by default; toggle in the diashow settings popover.

### Smart pacing

- Detect video duration and let videos play their full length (with a cap), pause stills
  for the remainder. Avoids choppy 6-second cuts on a clip with key content at 0:08.
- "Action density" heuristic — slow down for portraits, speed up for landscapes.

---

## Social

### Per-guest gallery

A first-class "All posts by Anna" view, navigable from a guest's avatar — not just a
filter chip. Doubles as a personal "what did I post?" page.

### Story-style highlights

Host curates a best-of timeline pinned at the top of the feed (already in PROJECT.md's
"Should Have"). Tap-through, fullscreen, ~5 s per story, like Instagram. Could double as
the source for the curated-diashow mode above.

### Reactions beyond like

Multiple emoji reactions (❤️ 😂 😍 🎉 🥲) instead of just like. The DB design already keys
the `like` table on `(upload_id, user_id)` — generalising to `(upload_id, user_id, kind)`
is a small migration.

### Mentions and reply-threads in comments

- `@anna` in a comment becomes a tap-through to her profile / posts.
- Threaded replies under each top-level comment.
- Combined with PWA push, drives engagement.

### Collaborative captions

Co-authored captions when multiple uploaders are in the same photo — second tagger
contributes their `#hashtags` to the same post.

---

## Notifications

- PWA push for new comments on a guest's own posts.
- Per-user opt-in; granular per-event preference (mute event, mute uploader, etc.).
- Email digest after the event (1 message per guest) — optional, controversial vs. the
  "no email" identity model. Could be opt-in only.

---

## Capture & posting

- **Live-photo mode** — capture a 1–2 s clip alongside each still (Apple-style). Diashow
  could animate stills using the live clip as the Ken Burns source.
- **Boomerang / GIF capture** — short looping clips.
- **Client-side filters and stickers** — Instagram-style.
- **Voice notes** attached to a photo — "first dance" voice memo + the photo.
- **Bulk-upload presets** — pre-fill a caption for a batch ("Photos from the ceremony").

---

## Privacy & moderation

- **Per-post visibility** — "only visible to people with this hashtag" or
  "private to my friend group".
- **Pre-moderation queue** — Host approves posts before they hit the public feed (default
  off; for sensitive events).
- **Auto-blur** of detected faces of non-guests, or NSFW detection.
- **Per-uploader watermark** on full-quality downloads.

---

## Multi-tenancy

- **Multiple events per instance** — picked by URL slug. Today the binary is single-event.
- **Org accounts** — a wedding photographer running 4 weddings a month against the same
  deployment.
- **Per-event admin** vs. **instance admin** roles.

---

## Internationalisation

- Localisation beyond German — English, French, Spanish, ...
- Admin picks UI language during setup; per-user override.
- Strings extracted into a small JSON catalogue — works well with `svelte-i18n` or similar.

---

## Export

- **Year-in-pictures PDF** — host-curated layout, printable.
- **ICS calendar attachment** of the event, included in the export ZIP.
- **Direct upload to a guest's chosen cloud** (iCloud, Google Photos) — needs OAuth, adds
  a third-party integration where today there are none.

---

## Resilience / infrastructure

- **Distributed rate limiting** (Redis) for multi-instance / multi-event deploys.
- **Object-storage backend** (S3 / MinIO) behind a feature flag — out of scope for the
  single-VPS use case but easy to add if multi-tenancy is ever pursued.
- **Read replicas** for very large events.

---

## Maintainability principles to keep adding features cheap

The codebase is small today and should stay friendly to extension. A few patterns to lean
into as the surface grows:

- **Diashow transitions as drop-in components.** Each transition implements a tiny
  interface (`enter`, `leave`, optional `duration`). Adding a new animation is one file in
  `frontend/src/lib/diashow/transitions/` and one line in a registry. Same idea for
  hashtag-filter operators.
- **Per-feature toggle flags in the `config` table.** Today rate limits and quotas are
  individually toggleable (see [FEATURES.md](FEATURES.md)). The same pattern fits for any
  future opt-in feature — no need to redeploy to flip behaviour.
- **Background-task trait on the server.** Export, compression, and (future) analytics
  jobs would all share a `BackgroundJob` interface that wires into the existing
  `export_job` progress + SSE pipeline. New long-running work plugs in by implementing the
  trait — no bespoke worker code per feature.
- **One Svelte store per cross-cutting concern.** Auth, upload queue, SSE, data mode,
  diashow state — each lives in its own store under `frontend/src/lib/`. New UI features
  consume the stores; cross-feature behaviour is composed, not copy-pasted.
- **DTOs in one file** ([frontend/src/lib/types.ts](../frontend/src/lib/types.ts)),
  mirrored to the Rust DTOs. Changing a contract is exactly two edits.
- **Migration-first schema evolution** — never edit an old migration; always add a new
  `0NN_*.up.sql` / `.down.sql` pair. Already the discipline; just keep it.

---

## Speculative / "would be cool"

Lower bar of plausibility — keep these around as conversation seeds:

- **AI-generated event summary** at release time (3-paragraph recap, key moments,
  funniest comment).
- **AI auto-tagging** — suggested hashtags based on image content, opt-in per upload.
- **Guest-of-honour mode** — special UI for the couple / birthday person showing
  *everything they're in*, prioritised by face detection.
- **Live caption translation** for international weddings — auto-translate comments
  inline.
- **Sound-reactive diashow** — slides advance in sync with music BPM picked up via the
  device mic.
- **Photo-booth integration** — a fixed iPad at the venue posts to the feed with a single
  tap, no PIN.
