[Decision] Online metadata enrichment — go/no-go before any spec work

[topkoa]

Split from #36 §3. Decision-only — no schema until the team agrees to do online lookup at all. Different gate from the additive metadata issues: a policy question, not a metadata-shape question.

The question

Should feedpak hosts do online metadata lookup (cover art, genre, year, tags) for messy imports? Homelab precedent: Lidarr+MusicBrainz, beets autotagger, Komf. Marketing flagged art-poor grids as a demo-wow + adoption-friction issue.

Non-negotiable constraints if pursued

Opt-in, offline-first, no silent phone-home. The natural home is a library provider / enrichment source, not core.

Spec angle (only relevant if go)

If enriched metadata is written back into the pack, where does it land and how is provenance/override tracked?

• Enriched fields land in the same manifest keys (genres/tags/year/album) — which is exactly why the genre/tags issue ([RFC/Discussion] Library & metadata roadmap from the FeedBack library charrette (difficulty rating, genre/tags, enrichment, DB/ops) #36 §2) should land first (it defines the target fields).
• Provenance reuses the existing {engine, model, version} pattern (§5.3.1) — e.g. a metadata_source object — so machine-fetched values are distinguishable from authored ones and a user override is never silently clobbered.
• §9.5 doesn't bar this (it's authored data about the song, not user/machine state) — but provenance + override semantics are the spec's concern, not the fetching.

Ask: go/no-go on online lookup. No spec PR until resolved.

[ChrisBeWithYou]

Resolving the go/no-go.

Decision: GO — but as an opt-in, offline-first provider, not core. No spec PR now.

Non-negotiables (confirming this issue's own constraints): enrichment is opt-in, offline-first (the app is fully functional with it off or unreachable; a failed/blocked fetch degrades silently to "keep the messy metadata," never blocks an import), no silent phone-home, and its home is a library-provider / enrichment source, not core — so a homelab user who never enables it has zero network surface and core never depends on it.

Open for discussion — on-by-default vs opt-in. I've scoped enrichment as opt-in (the user turns it on), the conservative reading of the "no silent phone-home" line above. The alternative — and the established media-server default (Plex) — is enrichment on by default, a real out-of-box-polish win: libraries look great with zero setup. The trade: on-by-default means a network call without an explicit user action, which cuts against the no-silent-phone-home promise this issue called non-negotiable (it's the Jellyfin-vs-Plex split, and the open-successor "no central dependency" instinct leans Jellyfin). My lean stays opt-in / offline-first, but I want this decided deliberately rather than assumed — open to the argument that out-of-box polish is worth a clearly-disclosed, first-run-consented default.

Where enriched metadata lands (the spec-angle question raised here):

• It lands in the same manifest fields [Spec] Top-level tags manifest key (1.13.0, additive) — genres shipped in 1.12.0 #38 defines (genres / tags / year / cover) — which is exactly why [Spec] Top-level tags manifest key (1.13.0, additive) — genres shipped in 1.12.0 #38 is the prerequisite: enrichment has no target fields until those exist.
• Same plain vocabulary as [Spec] Per-arrangement difficulty rating on arrangements[] (1.13.0, additive) #37: a value a human typed is author-set (authoritative, travels in the pack, never auto-overwritten); a value the provider fetched is auto-filled — provenance-stamped, shown as auto-filled, refreshable/removable, and it never clobbers an author-set value. One provenance idiom across difficulty / genre / enrichment (see [Spec] Per-arrangement difficulty rating on arrangements[] (1.13.0, additive) #37 / [Spec] Top-level tags manifest key (1.13.0, additive) — genres shipped in 1.12.0 #38), not a third bespoke shape.
• Default host-side; embed into the pack only on explicit intent — with one exception. Auto-filled values fill your library view (host-side, re-fetchable); they're written into a pack only when you deliberately "embed," so a portable file stays "what the author put" by default. The one auto-embed exception is cover art the user provides (their own content). Scraped art shows in your grid but embeds only on that same explicit action — because auto-baking third-party-copyrighted covers into files that then get shared is a licensing surface an open, self-hosted format shouldn't take on by default. (Consistent with the open-successor posture: user-authored / user-supplied content travels; third-party fetched content stays host-side unless the user opts to embed it.)
• Join on the stable IDs [Spec] Top-level tags manifest key (1.13.0, additive) — genres shipped in 1.12.0 #38 promotes (MBID / ISRC) — the clean key for a lookup, and the thing the comparable ecosystem never had (it keyed on artist+title text → duplicate/match chaos).
• Lead with the trust signal, not the cover — the highest-value enrichment is "is this the right / accurate version," not just art.

No schema now. The only spec surface enrichment ever needs is provenance + the never-clobber rule, and both are already on record from #37 / #38 (the {engine, model, version} stamp + author-set-vs-auto-filled + "fill-don't-clobber, author wins"). So there's nothing to add to the schema here — ratify the direction, write zero schema, and it rides #38's fields when they land.

Why GO (brief): the closest comparable custom-chart community did zero enrichment, and it showed — art-poor grids and inconsistent, author-entered year / genre that degraded the very facets #38 adds. Enrichment is a real differentiator, and the homelab-native shape is an opt-in provider (mirrors our own separate-service precedent for stem separation) — so we borrow that pattern, keep core network-clean, and get the rich, consistent metadata that community never had without a phone-home or a central dependency.

Sequencing: decision = GO; downstream of #38 (target fields) + the shared provenance rule; no PR until those land. #37 / #38 proceed independently in the meantime.

[topkoa]

Update — one dependency is now partly satisfied. This issue's spec-angle note said the genre/tags issue "should land first — it defines the target fields." With 1.12.0 merged (PR #40), the writeback targets genres/album/year now exist in §5.1; only tags is still pending (#38, retargeted 1.13.0). The core question here is unchanged — go/no-go on online lookup — and provenance/override semantics remain out of scope for 1.12.0 (per #40), still the spec's concern if this goes.