fractal.beauty

2026-06-21

Local-first music players & file storage

I want a ~local-first music player:

Making multiple devices communicate is mostly solved: I would use Iroh, maybe with a central server to help out with account/device management. Once they can talk, syncing the set of metadata (track info, albums, playlists) is easy enough with a CRDT, but the audio data is much larger than the metadata and it’s not feasible to have a full copy on every device. What can we do to make it work?

Transcoding

We can create lower-quality versions of the original audio files to save on storage space. It’s nice to keep the original/lossless/archival-quality files around, but for day-to-day listening, we can get away with lower quality. Most people also aren’t listening on high-end equipment and won’t be able to hear the difference.

Opus is the default codec for this. The threshold for “transparency” or “perceptually lossless” quality (indistinguishable from the original full-quality file) is highly debated (you can try an ABX test yourself somewhere), but Opus 256kb/s is probably overkill and is still much smaller than FLAC.

128kb/s is perceptually lossless to some people, and you can fit ~300 songs per GB. 64kb/s is worse, but it’s still pretty good, and you can fit ~600 songs per GB.

This makes it more feasible to have large subsets of your library on each device, but if you have a large library or want higher quality, you’re still looking at tens of gigabytes on each device, which isn’t ideal.

Stream from another online device

In this hypothetical software, all your devices are communicating already. If a device wants to play a song, but doesn’t have the file, it can ask the user’s other devices whether they have it. If another device has the original file, or even a transcode of it, we can stream it in real time pretty seamlessly for the user.

To reduce reliance on other devices, we could cache the file after streaming it. We could also pre-download songs, either because the user requested to keep them available or because we somehow predicted that the user will want to play them later.

If you have a device that’s always online and you instruct it to keep a transcode of every file, you’ve won! There’s always a device available to fetch missing files from. Some users will have a desktop computer that they leave running which does the job. The hypothetical software also includes a headless version for users that are technically-inclined and open to self-hosting.

However, some users shut down their desktop computer at night, or they use a laptop which isn’t always running. Even worse, laptop and phone use tends to not overlap1. We switch between one or the other, making it less likely for both to be online at the same time, which we need in order to sync metadata or stream audio.

Pay for cloud storage

If you don’t have an always-online device, you could pay someone else to host one. They’d probably implement it on top of object storage, so to save on bandwidth, the software could just have the ability to access object storage directly. You would need to coordinate which device uploads the transcodes, but afterwards, any device that can reach the cloud storage service can retrieve the file without other devices being online.

Nobody wants to pay for another service, but object storage is pretty cheap. Assuming a price of $0.03 per GB per month and 300 transcoded songs stored per GB, a library of 10,000 songs would cost $1 per month to store. The software could allow users to switch object storage providers to prevent lock-in.

It’s a less pure incarnation of local-first, but it seems practical. You’d still have your files and metadata stored on your devices, and the software would implement device-to-device streaming so that paying for cloud storage is only for convenience and not strictly necessary. You can avoid cloud storage if you can fit your full library on every device, or self-host an always-online device, or live with manually pre-downloading songs when other devices are reachable.

Buy an appliance

A more interesting direction is an appliance that you buy once and plug in at home. Ideally, appliances just work (compared to the skills and effort required to self-host) and are reliable (compared to the skills and effort required to self-host). This is very hard. The device should be fault-tolerant, there shouldn’t be an admin panel that’s occasionally needed to unbreak things, and even if the software was perfect, hardware eventually fails and needs to be replaced. But if it worked well, it might be more palatable than subscribing to cloud storage.

This is similar to a NAS server. A company called Roon also seems to sell a music server appliance.

Inter-user file storage

Another direction is communally-hosted software. Someone with the skills and inclination to host a service could also share it with family and friends, and maybe others could pitch in to cover the costs.

The software could make this really easy, without even needing to explicitly host or manage anything. If you have free space on your device, you could share it out to friends to store and serve transcoded files. If this is an always-online device, your friends will be very pleased. If not, it’s still a bit more reliability for them, and if they’re swapping storage space with many people, there’s a good chance a copy will be available. To be efficient, we should probably deduplicate the shared files, so if your friend happens to already have the same song, you don’t need to upload another copy.

I’m not a lawyer, but transmitting music files to devices belonging to other people seems like it might be legally dubious. Maybe it would be more convincing if the files were encrypted and somehow required possession of the unencrypted file in order to read it? Maybe the software not allowing you to easily access files that you don’t “own” in your original library is enough? I don’t know.

If that wasn’t a concern, there could be a shared index of metadata and audio file hashes and a peer-to-peer network of who has what files. Then you’d have a good chance of being able to stream a song even if your other devices are offline, because someone in the world probably has a copy of it. And you’d be able to share and acquire music, integrated directly in the music player. Maybe.

Footnotes

  1. I’ve borrowed this observation from b5’s talk at LoFi/34.