A prompt, a room, and the song you were thinking of.

Listening Party centres the conversation around a song: the memory, person or mood that made someone choose it. Its 40 original prompts give the room a starting point, while separate host and player views keep submissions private until they are ready.

A player can answer by voice or with a private typed fallback. The host sees the proposed match, can preview or search again, and approves the song before the room hears it. This keeps an uncertain automated match away from the shared queue until a person checks it.

Forty cards are easy to browse until a host wants one for a particular feeling or moment. The prompt finder searches the existing deck from a short request such as “a confidence song for starting over.” It does not write new cards.

The browser implementation compares two familiar retrieval methods. BM25 rewards matching words. Compact 50-dimensional GloVe word vectors can also surface prompts whose language is related without being identical. The live finder now makes those results easier to inspect: it shows matched words, the original-card source and a plain explanation when common words are doing the matching. A host can clear, close or switch category without losing the room flow.

I used two batches of synthetic, agent-authored English requests: 40 to decide whether a new rule was useful, then 34 held aside for comparison. They were grouped into related intents before scoring. This is an engineering check, not user research, and it does not claim full blinding.

Each new rule stopped bad suggestions by stopping useful ones too, so I kept the simpler search and did not carry those rules into the held-back comparison. There, BM25 found an expected card in the first three for 18 of 22 usable requests and the semantic comparison did so for 19. That small synthetic difference does not justify calling one a winner.

The older 34-case comparison remains available as a dated v1 record. Its denominators are kept separate from this later evaluation.

A slow connection exposed an old 20-second deadline for the optional model download. I had it extended to 90 seconds while keeping keyword search usable. Two regression cases failed at the old deadline and passed after the change: a simulated 58-second download completed while keyword results stayed available, and a stalled download reached the limit with a retry.

The release then passed 126 tests, with two opt-in provider tests skipped, and 12 live-browser checks. Those checks covered the explanations and recovery controls, keyboard use at 390, 768 and 1440 pixels, the real browser model checksum, and a host dealing a card for a separate guest to read back. They did not test microphone input, transcription, paid providers, physical devices or multi-device audio.

The deck is small and fixed. That makes a compact local index a better fit than adding a generation service, vector database or laptop companion. Search can run on the visitor’s device after its static assets load, with no model API bill and no host brief sent to a new provider.

Python prepares the compact GloVe model and runs the search evaluation. TypeScript searches the 40-card deck in the browser. The game itself uses Next.js, React, Supabase and Cloudflare, with YouTube search and host approval before shared playback.

I defined the host workflow, directed the search implementation and compared the candidate approaches. I kept BM25 as the default because the stricter options hid useful cards. The host still makes the final choice.

I checked the live flow from finding a card to dealing it to a separate guest. The linked results include the test requests, scores and the reasoning behind that release decision.

The host reviews each YouTube match before it joins shared playback. Players can join without creating an account; the browser may ask for a tap to start audio.

Hosts can search from their room. Both search methods run in the browser, with BM25 selected by default.