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