Levyraati26_go/docs/later.md

Later

Ideas with their reasoning, kept so the thinking isn't redone from scratch. None of this is v1 work, and none of it should shape v1 code beyond what the API contract already allows.

---

Email: password reset and announcements

Wanted, blocked on not having a reliable SMTP server. Members already have addresses in their profile (decisions 31), so the data is there when the transport is.

Two things to remember when it happens:

• v1 cannot verify addresses. Some of them will be typos, and a password reset to a typo'd address is a locked-out member. The admin already resets passwords, so that is the fallback — but the reset flow should not assume the address works.
• Announcements need an opt-out, or they become the reason someone stops reading them.

---

Lyrics with scaled autoscroll

Fetch lyrics and scroll them in time with the audio. Designed and decided (decisions 45), not built.

Coverage, measured 2026-07-31 rather than assumed. An earlier version of this page guessed LRCLIB would miss nearly all Finnish music. It does not:

Search	Results	With syncedLyrics
Nightwish	20	20
Eppu Normaali	20	13
CMX	15	12
Popeda	20	8

LRCLIB (lrclib.net) needs no API key. /api/get matches on artist, track and duration within ±2 s and returns syncedLyrics — real LRC with [mm:ss.xx] per line — alongside plainLyrics; /api/search?q= is the looser fallback. Go's side is net/http and encoding/json, so the dependency budget survives, and it is treated exactly like ffmpeg and yt-dlp: a timeout, allowed to fail, never blocking anything.

Where it happens: at submission, as a suggestion.

• The worker attempts one automatic lookup after conversion, using whatever metadata exists.
• The waiting page has a Hae sanoitukset button that re-queries with whatever is currently typed in the title and artist fields. That is the answer for messy tags — Sentenced Noose from a YouTube upload will not match until the submitter fixes it, and the automatic attempt would otherwise just look broken.
• Neither ever overwrites text the submitter has typed. They can accept the suggestion, edit it, or leave the field empty.

Storage: one nullable lyrics text column on both submissions and songs, copied across at publish. LRC or plain is told apart by whether the first line starts with [, so no second column and no flag. Nothing has launched, so this goes into 001_init.sql rather than a migration 002.

Lyrics stay editable after the song locks — the lock exists so the thing people reviewed stops changing, and nobody reviewed the lyrics. It also means someone can paste them for an old song a year later, which is when this feature is most useful.

Playback:

• Synced hit → highlight the current line properly, driven by the transport's timeupdate.
• Plain hit or manual paste → distribute lines evenly across duration_seconds and scroll the block continuously without highlighting a line. Highlighting makes every second of drift read as a bug, and drift is guaranteed — intros and outros alone break a uniform mapping.
• The Web Animations API does the whole thing including seeking: build the scroll animation with duration_seconds, pause() it, and bind play/pause/seeked on the audio element. No timers, no drift accumulation.
• Leave a nudge knob — a ±10 s offset slider, remembered per song in localStorage. Uniform distribution models a song no real song obeys, and one drag while listening beats any heuristic.

Still open: where the panel lives on the song page. That page's job is now listen and write, and a scrolling lyrics panel competes with the review textarea for both space and attention — a collapsed panel under the player is the starting guess, not a decision.

Copyright posture is the same as the YouTube note: private app, ten people, written down deliberately.

---

AI features (Gemma-class local model)

The constraint that shapes every idea: E2B-class multimodal models are speech models. The audio encoder targets ASR and spoken-audio QA. Music is out of distribution — genre calls are near coin-flips, "describe this track" produces beige copy, and singing over instrumentation is a worst case for ASR. Encoders also work in ~30 s windows, so a four-minute song is a chunk loop, and on CPU beside ffmpeg that is minutes per submission.

So the ideas that use the model to be correct are the weak ones, and the idea that uses it to be entertaining is the strong one:

• A bot reviewer — a member account that listens to each published song and posts a score and a few sentences in character. The model's weaknesses become the feature; nobody files a bug because the robot was wrong about a friend's doom metal demo. It is a users row and a reviews row, no new domain concepts, and the reveal rule already makes its take something you unlock by reviewing — which quietly rewards the behaviour the whole app exists for. Needs: a sharp persona, a ~3-sentence cap, exclusion from the reviewer leaderboards and from the ≥3-review threshold.
• Weak: genre suggestion (buys one click, and a confident wrong default is worse than an empty dropdown), auto-drafted introductions (same objection as YouTube descriptions), "is this actually music" screening (ffmpeg already proves it is audio, and the admin can delete).
• If duplicate detection is ever the real want, that is Chromaprint/AcoustID, not an LLM.
• Architecture, when it happens: an Ollama or llama.cpp sidecar called over HTTP from the worker with a timeout — treated exactly like ffmpeg and yt-dlp, an external process allowed to fail. Go's side is net/http and encoding/json, so the dependency budget survives. Never block publish on inference.

---

Native client

Deferred; the shape depends entirely on what it is for.

• Launcher icon and media keys → a PWA. manifest.json plus ~10 lines of navigator.mediaSession gets media-key control, and on Linux the browser exposes it over MPRIS, so the song appears in the GNOME/KDE media widget with artwork. Zero packaging.
• Playback surviving navigation → a webview shell, and this is not free even then: a webview is one browser context, so in-app navigation tears down <audio> exactly like a tab does. The fixes are an outer shell page with the app in a same-origin <iframe>, fetch-based navigation, or audio played by the native layer with the webview as UI only.
• Offline listening → the only motivation nothing else covers, and a genuinely different project: download endpoint, local cache management, sync.
• Not Electron. It bundles Chromium and Node — ~150 MB on disk, 200–400 MB idle RAM, and Node back in the build, which is the exact dependency surface the rewrite exists to escape. The system-webview equivalents are ~5–10 MB: Wails (Go, same language as the server) is the pick, with Tauri as the Rust alternative.
• Packaging inverts with that choice: a plain Go binary → AppImage (one appimagetool step, one file to hand out). A webview shell links WebKitGTK, which AppImage bundles badly and the GNOME Flatpak runtime provides for free.
• Worth settling first: the usage pattern this app implies is opening a song, listening, and reviewing it right there — one page, playback never interrupted. If that is the real behaviour, the entire rationale reduces to wanting a launcher icon, and that is a .desktop file with chromium --app=….

---

Custom audio player

Native <audio controls> is plain, but it is also correct — keyboard-operable, screen-reader labelled, media-key aware. Replacing it is cheap and purely client-side: drop the controls attribute, keep the same element, and drive it through play(), pause(), currentTime, duration, and timeupdate. Playback, buffering, seeking and Range requests keep working untouched, and the server changes not at all.

Two things keep it cheap and both are already in v1: the player lives in one template partial, and duration_seconds is on the song row. Skip precomputed waveform peaks — if a SoundCloud-style waveform is ever wanted, backfilling a couple hundred .ogg files is a ten-line script.

When building it, re-earn what the native controls gave away for free: keyboard operation, visible focus states, and aria-labels on the buttons. That is the part custom players routinely drop, and it is not optional.

---

Stats not built

Wanted at some point, deliberately out of v1: Top 10 by genre, average given versus received per member, a reviewer agreement matrix, genre distribution, activity over time. The agreement matrix in particular is an O(n²) query and a UI nobody has asked for twice.

Also here: pruning the count-based leaderboards once the queue has drained and they are all ties (decisions 35).

---

Review form as a mixer channel

Idea for the UI polish pass, not now: put the score slider and the review textarea on one row, with the slider vertical like a channel fader on a mixing desk. The score stops being a form field and becomes the instrument the app is actually about, and the two things you do at once — decide a number, write why — stop being stacked a screenful apart.

Notes for whoever builds it:

• A vertical <input type="range"> is native now: writing-mode: vertical-lr; direction: rtl gives bottom-to-top travel with no JS and no custom widget, so keyboard support and the value stay free.
• Keep the live <output> — on a fader it wants to sit at the top of the track, reading like a channel's gain display.
• The row needs a mobile answer: below ~640px, either keep the fader and shrink the textarea beside it, or fall back to the current stacked layout. A short vertical fader is worse than a horizontal one, so measure before choosing.
• Tick marks along the track (1 / 25 / 50 / 75 / 100) replace today's .scorescale row, and are what make it read as equipment rather than decoration.

---

The JSON API

Designed and specified in spec.md §8 — object shapes, endpoints, error codes, pagination — and deliberately not implemented, because nothing calls it (decision 43).

When something does:

• Build only the endpoints that consumer needs, as jsonOf(...) adapters over the same data functions the pages already use, so the domain rules cannot diverge between the surfaces.
• Add the golden-file tests at the same time, one per object shape. They are what makes a renamed field a test failure rather than a silent break in a client you cannot update.
• CORS is a one-line middleware, added the day the consumer is on a different origin. Not before.
• The most likely first consumer is a native client (see above), and the endpoints it needs are login, the queue, a song with its reviews, and posting a review — four routes, not twenty-one.

---

Filters on the browse list

/songs is newest-first with no filters. Once there are a couple of hundred songs, "which ones haven't I reviewed" and "show me the metal" become real questions — one WHERE each, additive to the API contract as query parameters. Worth doing when the scrolling annoys someone, not before.