9a0ceeced7
- PROJECT.md, README.md, TEST_GUIDE.md: status line refreshed; rate-limiter doc-vs-code drift fixed; HTML export section rewritten for the SvelteKit- static viewer; SSE event names + new events documented; config seed block extended with planned toggles + privacy_note; decision log entries added. - docs/CONCEPT_HTML_VIEWER.md, docs/CONCEPT_MOBILE_UI.md: banner the design intent as shipped; point at the source-of-truth code paths. - docs/CONCEPT_DIASHOW.md: planned-then-shipped design for the live diashow (two-queue policy, pluggable transitions, data-mode aware). - docs/FEATURES.md: capability matrix by role (Guest / Host / Admin) plus prose per area (auth, posting, feed, moderation, admin, export, gestures, data mode, quotas, privacy note, extensibility). - docs/USER_JOURNEYS.md: step-by-step flows for every supported scenario, including PIN reset by host, data mode, privacy note, gestures, and the admin toggles. - docs/IDEAS.md: speculative extensions (global diashow, reactions, multi-tenancy, animation pack, etc.) — explicitly out of v0.16 scope. - backend/migrations/README.md, frontend/src/lib/README.md: codify the "never edit a shipped migration" rule and the lib/ conventions (one store per concern, gestures via actions, sheets via ContextSheet, transitions as drop-in components). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
200 lines
7.9 KiB
Markdown
200 lines
7.9 KiB
Markdown
# 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 headlessly. 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.
|