How taste maps your listening

taste takes listening from Last.fm scrobbles, a Discogs shelf, and screenshots, and resolves every artist and release to a cluster_id: the identity key the whole hosaka fleet shares. Once resolved, your library is keyed to the same artist identities the rest of the fleet uses, so the dashboard and recommendations draw on documented connections rather than anonymous play counts.

One identity per artist, with or without the paperwork

The hosaka map — the substrate taste resolves into — models every artist as a constellation of sightings: DJ sets, radio appearances, press coverage, shelf listings, bookings, and more. As of July 2026 the hosaka map holds approximately 1.97 M artist clusters built from 14 independent source kinds across 448 scene areas.

External catalogue IDs — MusicBrainz MBID, Discogs artist ID — are annotations attached to a cluster after the fact. They are not the key. This means newly-active artists who have never filed paperwork are already in the graph if the fleet has seen them, and identity survives catalogue gaps cleanly.

The hosaka map is a fleet-wide resource, not a taste feature. See hosaka.fm and its first consumer, ninsei.hosaka.fm, for the wider picture.

Resolve, don’t re-anchor

When an item arrives in your library, taste calls the fleet’s resolver via crate’s public API — the same call any external integrator would make. taste never re-keys your library on a third-party catalogue or builds its own disambiguation layer; that work lives in the fleet, and taste consumes it the way any customer would.

The resolver returns a cluster_id when it finds a match, and nothing when it does not. That explicit gap is the next block.

Coverage, honestly

Resolution is never 100%. The public benchmark: approximately 47.9% of scene-booking artists currently lack a Discogs ID or MusicBrainz ID — two of the annotation signals the resolver uses. Your dashboard shows a coverage dial so you can see the proportion at a glance. Unmatched items are labelled unmatched and excluded from recommendations; they are never silently padded in or counted as resolved to keep the number tidy.

Coverage moves as the hosaka map grows and as your library changes. It is a live dial, not a one-time figure.

What comes out

Resolved listening produces four axes in your dashboard:

• Timeline — your plays over time, anchored to the dates the source recorded them.
• Collection — what you own or have shelved, with resolution coverage per item.
• Clusters — your artists plotted on the hosaka map; see the scene neighbourhoods your taste sits in.
• Coverage — the proportion resolved clean, shown transparently rather than hidden.

On top of the four axes: graph-grounded recommendations. From July 2026 taste traverses the hosaka map — shared bills, labels, scenes, co-appearances — seeded by the artists you have already resolved, and returns suggestions with artist-scene chips that name the city-scene the artist plays in. Scene chips describe where an artist plays; taste holds no user location.

What goes in today

Live connectors:

• Last.fm — scrobble history via your public username.
• Discogs — your public collection by username, no OAuth required. Private collections receive an honest error.
• Screenshots and PDFs — upload a capture (PNG, JPEG, WebP, or PDF up to 15 MiB); taste reads it in memory using OCR and discards the image immediately. Nothing enters your profile until you confirm the extracted candidates in a batch review step.

Roadmap — marked as forward-looking, not promises: more connectors as their terms of service allow. Bandcamp enters only as your own screenshots or exports — taste will never do server-side scraping of a service that forbids it.