Your record collection, overflowing into the room

I had a week of Claude and Codex usage to burn through, and rather than grind on the backlog I pointed it at a question I'd been turning over for a while: what would Kanora look like on a Meta Quest 3? I have the hardware. The library is already there. The Companion API already lets other devices talk to a host. It seemed like the right kind of low-stakes side-quest to think out loud about.

What follows is a plan, not a shipped feature. There is no build yet — just a spec, a set of decisions, and one idea I had to throw away before the good one showed up. That throwing-away is most of the story, so I'll start there.

The idea I started with, and why it was wrong

The first version was the obvious one, and the wrong one: a virtual listening room. You put the headset on, you are sat in a modelled space — a lounge, a planetarium, whatever — and your music plays around you in spatial audio while album art drifts past. It demos beautifully in your head.

It falls apart the moment you try to make the audio real. Playing music on the Quest means decoding the files on the headset, and a Kanora library leans heavily on lossless. Apple Lossless does not decode cleanly on Android, which is what the Quest runs underneath. Worse, the whole premise of an ambient music app is that the sound keeps going while you do something else — and whether a Quest app can hold audio while you switch to another app is, politely, not something you want to bet a product on. I spent a good while speccing all of that anyway: a native decoder bridge, a fallback to host-side transcoding, a spike just to find out what the platform would even allow.

Then the obvious thing finally landed. I have a hi-fi. The person this is for has a hi-fi. Why is the headset trying to be the thing that plays the music?

The headset that doesn't play the music

So the whole thing flipped. The Quest plays no audio at all. The listener is sat in their room with their hi-fi, and the hi-fi — driven by the Mac that is already running Kanora — is the thing making sound. The headset becomes two other things instead: a remote, and a way to look at your collection that a phone simply cannot do.

That single decision deleted every hard problem at once. No decoder. No codecs. No transcoding fallback. No background-audio gamble. The fragile, risky half of the project stopped existing. What is left is the half that is actually fun.

Crate-digging in mid-air

Here is the part worth wearing a headset for.

In passthrough — so you can still see your actual room, your actual hi-fi — your collection overflows into the space around you. Not a grid on a screen you scroll, but a wall of cover art that wraps past the edge of your vision and recedes into the distance, the way the racks in a record shop do. Near records are large and detailed; the collection trails off into depth behind them. You turn your head to see more. You lean in. You reach out, pull a sleeve toward you until it is full size in front of you, and set it on the platter to start it playing — on the hi-fi. I have been calling this view the Stacks.

<!-- Concept image placeholder: passthrough view of a curved wall of album covers wrapping around a seated listener, nearest covers large, the collection receding into depth, the real hi-fi visible underneath. -->

For a focused set — a playlist, a collection — there is a more tactile version: a crate of records on your real table that you flip through with your hands, pull one out to look at the sleeve properly, and drop on the platter. It is unashamedly nostalgic, and it suits an app built for people who care about owning their music.

Underneath both is the surface you actually live in: the album that is playing, floating as a large gatefold anchored over your real hi-fi, with the tracklist and where you are in it. You glance at it from your listening chair. You take the headset off; the music keeps playing. The headset is for enjoying and steering the collection, not for the listening itself.

Most of it is already built

The neat trick is how little of this is new.

Kanora already has an Apple TV companion that does exactly this control job: pick something on the big screen, it plays through the Mac's hi-fi, and transport and now-playing all work over the local network. That whole surface — pairing, browsing, the play/pause/skip/seek/shuffle/repeat commands, the now-playing state — already exists and is already in use.

So the Quest does not need the host to change at all. It pairs the same way the Apple TV does, browses the same library endpoints, fetches the same cover art, and sends the same playback commands. As the spec stands, the number of changes required to the existing Kanora codebase to support all of this is zero. The Quest app is a new thing in its own repository that talks to an API that is already there. That is the difference between a fun idea and a fun idea you could actually start on a Saturday.

What I don't know yet

Two honest unknowns.

The first is whether floating a thousand or more album covers in passthrough holds frame rate. In VR, dropped frames are not jank — they are nausea — so this is a correctness problem, not a polish one. It is the first thing to build: a throwaway test that puts 500, then 1,000, then 2,000 covers in the air and measures, before a single line of the real browser is designed. If it does not hold, the design changes to fit what the hardware can do.

The second is softer and more important. Because the music plays whether or not the headset is on, the app has to earn being worn. A floating remote control would not — you would just use your phone. The only justification for the headset is that browsing your collection this way is genuinely more enjoyable than scrolling a list. If the Stacks is not a pleasure to move through, the whole thing is pointless. That is the bar, and it is a high one.

Doing it with Claude and Codex

Since the whole reason this exists is that I had AI-tool usage to spend, it is worth saying what that was actually like.

The useful part was not code — there is no code yet. It was the speccing. I worked through the design the same spec-first way the rest of Kanora gets built: a written specification, an implementation plan, a task breakdown, all in the house format. The tools were good at turning a loose idea into a structured spec quickly, and good at grounding it in the real codebase — pulling the actual Companion API endpoints, the real pairing flow, the exact playback commands that already exist — rather than hand-waving about what a host "probably" exposes.

The more valuable thing, though, was that the back-and-forth killed the bad idea faster than I would have alone. I had written most of an in-headset-audio spec before the "wait, the hi-fi should play the music" reframe landed. Once it did, throwing the audio half away and rewriting around the remote took an afternoon, not a week. Cheap iteration on a design is underrated. The judgement calls — that the listening room was a trap, that the browsing has to earn the wear — were still mine to make. The leverage was getting from idea to a concrete, honest, throw-away-able plan fast enough that being wrong barely cost anything.

Where it stands

None of this is built. It is a spec — number 016, if you are counting along at home — sitting in a separate repository, waiting for a first weekend. The first move is the frame-rate test, because everything else depends on the answer. After that: pairing, then the remote, then the Stacks.

It might turn into a real thing. It might stay a nicely-specced experiment that proved the idea was not worth the silicon. Either way it was a good use of a week of tokens I would otherwise have let expire — and the Quest can stop sitting on the shelf wondering why it owns a music library it has never been allowed to see.