EventSnap/docs/IDEAS.md

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 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) 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). 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), 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.