Kanora
Kanora
All dispatches
Ownership

Owning Your Library Means Owning the Paths Too

April 26, 20265 min readBy Kanora
kanoraownershipfeature

The easiest way to spot whether a library app really believes in ownership is not to look at its hero copy. It is to look at what happens to the files once ordinary life gets in the way. Move a drive. Reinstall the app. Change devices. Lose a sync state. Pull a track down from somewhere remote and ask where it actually lands. If the app gets vague at that point, the ownership language is probably doing more work than the implementation.

That is why a surprising amount of Kanora’s identity lives in path handling. On iOS, the managed library sits in Application Support rather than floating around the Files view like casual app debris. Relative paths matter because app container paths change. External media needs bookmarks because “I still know where this drive is” is not the same thing as the OS giving you permission to touch it again. If something starts remote and becomes local, the app should be able to explain exactly what happened and where the resulting file now lives. None of this is glamorous. All of it is the difference between a library you possess and a library you are merely borrowing from a piece of software.

The ownership angle here is not theoretical. Both Apple and Spotify are perfectly open about the fact that subscription catalogues are conditional. Apple’s support documentation explicitly says a song can show up as “No Longer Available” because it has been removed from the Apple Music catalogue, and Spotify says the music it offers varies over time and between countries depending on permissions from rights holders. Those are not edge cases from critics; they are platform realities described by the platforms themselves. Apple also warns that Apple Music is not a backup service, which is a sensible thing for them to say and a useful thing for library builders to take seriously. If the service is honest enough to tell you it is not your archive, your own software probably ought to behave as though that distinction matters.

If you want the blunter legal version of the argument, the EFF’s write-up on digital media ownership is worth reading. Their point is straightforward: even many so-called purchases are really licenses, and the rights people associate with ownership do not automatically follow you online. That is separate again from streaming, where the proposition is even more explicit: you are paying for access to a changing catalogue you do not control. That does not make streaming bad. It just means it should not be confused with possession.

The strange thing is that the industry data does not even support the lazy idea that people have fully stopped caring about possession. The RIAA’s 2024 year-end report shows streaming utterly dominating revenue, which is not surprising, but it also notes that vinyl continues to grow and accounted for nearly three-quarters of physical-format revenue. I do not read that as evidence that everyone wants to go backwards. I read it as evidence that convenience won the mass market while ownership never really disappeared as a value. It just became something fewer products were interested in respecting.

That tension is a big part of why Kanora exists. I am not trying to argue that streaming has no place. It obviously does. Discovery is easier there. Casual listening is easier there. Breadth is easier there. But a development blog for a library app should be allowed to say the quiet part plainly: access and ownership are not interchangeable, and software built for one tends to make the other look eccentric. I think that has skewed product expectations for years.

From a build perspective, this is why I care about relative paths, stale-path recovery, bookmarks, and import destinations more than I care about a lot of flashier UI decisions. If the app can recover a local file after the iOS container changes, that is ownership. If a remote download becomes a local file in a place the user can reason about, that is ownership. If an external folder remains legible after the OS renegotiates access, that is ownership. These are not abstract values. They are behaviours, and they either exist in the product or they do not.

AI has actually been quite good for this class of work, mostly because it is very comfortable doing the tedious inventorying that ownership features require. Where are the paths stored. Which ones are absolute. Which ones are relative. Which service resolves bookmarks. Where does remote media land. What assumptions only hold in one platform container. These are exactly the kinds of questions that are easy to half-answer from memory and much better answered by forcing a tool to trace the actual code paths back to you. The payoff is not inspiration. It is confidence.

I suspect this is one of those areas where Kanora will keep getting more opinionated as it matures. Not louder, just more definite. A local library app should know what it believes about the status of the collection, and I increasingly think that belief has to be visible in the infrastructure before it is visible anywhere else. If the software cannot answer “where is this file and what controls it” without flinching, then the rest of the ownership story is just furniture.

Further reading, if you want the platform and legal framing behind this: