What "local-first" actually means for a music player
Local-first is not the same as offline mode, and not the same as having no internet features. Here is the distinction that matters when the thing being stored is your record collection.
“Local-first” gets used as a synonym for “works on a plane.” It isn’t one. A streaming app with an offline mode works on a plane, and it is not local-first in any sense that matters.
Local-first software treats the copy of your data on your own device as the primary copy. Servers, if there are any, hold secondary copies to help with access from somewhere else. Offline mode is the reverse: the server holds the real copy and your device holds a cache, which is encrypted, tied to an account, and expires on a schedule somebody else controls. That difference is the whole of what owning music gets you that streaming it does not, and vice versa.
For a music player that distinction has a specific consequence. Either your record collection is a folder of files that happens to have a player pointed at it, or it is an entitlement that happens to have some bytes cached on your disk.
The test: what would you still have tomorrow?
Ask one question of any piece of software that holds your music:
If the company behind it shut down tonight, what would you still have tomorrow?
Three architectures, one question
On your disk A transient buffer.
Authority The server, entirely.
After the shutdown Nothing, immediately.
On your disk Encrypted files tied to an account.
Authority Still the server — it renews the licence.
After the shutdown Nothing, after a delay. The licence lapses and the cache stops opening.
On your disk The audio files themselves, in ordinary formats.
Authority Your filesystem. The app's index is derived from it.
After the shutdown Everything, exactly as it was. Point another player at the folder.
That is the whole idea. A local-first application treats files on your disk as the source of truth and treats itself as a lens onto them. Everything the application knows about your library — the artists, the albums, the play counts, the artwork — can be rebuilt by reading those files again.
Where the term comes from
Local-first is not marketing vocabulary. It was named in a 2019 essay, Local-First Software: You Own Your Data, in spite of the Cloud, by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan at the research lab Ink & Switch, presented at the Onward! conference.
The essay sets out seven ideals. Three of them do most of the work in an argument about a music collection:
- The network is optional. Not “degrades gracefully” — optional.
- The Long Now. Software should keep working for as long as you need it, which means it must not depend on a company continuing to run a server.
- You retain ultimate ownership and control. No third party can revoke your access to your own data.
The essay is largely about collaborative documents, and the machinery it proposes for them — CRDTs, conflict-free replicated data types — is not something a single-user music player needs. The ideals transfer anyway, and a music library is an unusually clean case: the data is already a pile of files in open formats, so the hard part of local-first has been done for you by the filesystem.
What local-first buys you
The player is replaceable. This is the strange part to say on a website that would like you to use its player: a good local-first player should be easy to leave. If Digr’s index is derived entirely from your files, then deleting Digr costs you an index you can regenerate, not a library you cannot. Software that is easy to leave is software you can trust to stay.
Nothing is uploaded. Not the audio, not the tags, not the artwork, not a list of what you played at 2am. There is no server to upload it to. This is a property of the architecture rather than a promise in a policy document, which is the only kind of privacy claim worth much.
There is no account. Accounts exist to connect you to a server. With no server, an account is a login screen standing between you and your own files.
It keeps working when the network doesn’t. Not as a degraded mode — as the normal mode. The network is for casting to a speaker in another room, and for nothing else.
What local-first costs you
Honesty about the trade is part of the argument.
You do the acquiring. Nobody hands you a hundred million tracks for a monthly fee; you buy, rip and collect, and that is slower and more deliberate.
You do the organising, or at least you live with the organisation your files already have. Folder structure, album artist tags and artwork are yours to get right — which is a solvable problem with a boring system, but it is a problem.
You handle your own backups, because there is no cloud quietly holding a second copy. One external drive and a habit will do it; a scheme sized to a real collection is better.
You get no algorithmic discovery. Some people read that as the cost and some read it as the point.
Local-first is a spectrum, not a badge
Very few applications are purely local. The useful question is not “does this touch a network?” but “which parts touch a network, and what happens when they can’t?”
Digr, as an example of drawing that line: the library index is a SQLite database on your machine, built from your files. Playback reads the files directly. Casting to a Google Cast speaker is a network feature by definition — but it works by running a small HTTP server on your machine that streams your original file to the speaker over your LAN, rather than uploading anything to a service. No part of the library is reachable from outside your network, and nothing leaves it.
That is the shape to look for: network features that extend what you already have, rather than network dependencies that own it. The rest of how Digr is built follows from the same rule, including the parts of it that are still missing. On a Mac specifically, the practical path from a folder of files to sound shows where the operating system helps and where it stops. A useful question to ask of any player is where its database lives and what happens if you delete it — if the answer is “you lose your library”, the files were never the real copy.
Why this keeps mattering
Every few years a service that hosted a lot of people’s music changes its terms, its catalogue, or its existence. The tracks that vanish are usually the interesting ones — the regional pressing, the label that folded, the mix that was never licensed properly in the first place. A collection is not a feed, and the difference only becomes obvious on the day the feed changes.
Local-first is a bet that the files you already have will outlast the software you play them with. It is not a nostalgic bet. It is just an accurate one.
Which application to make that bet with is a separate question, and it turns on architecture more than on features: the local player comparison sorts the field by what has to be running before you hear anything — a server, an account, or nothing at all.
Sources
- Local-First Software: You Own Your Data, in spite of the Cloud — Kleppmann, Wiggins, van Hardenberg and McGranaghan, Ink & Switch, Onward! 2019: the definition of the local copy as primary, and the seven ideals
- Digr — features and roadmap — what Digr does today, including the SQLite index as a derived cache and Google Cast as the only network feature
Common questions
Is local-first the same as offline mode?
No. Offline mode is a cache: the files a streaming app downloads to your device are encrypted, tied to an account, and licensed for as long as the licence lasts, and the server remains the authoritative copy. Local-first inverts that — the copy on your disk is the primary one, and any server holds a secondary copy at most. Both work on a plane; only one of them still works if the company stops existing.
Does local-first software mean no internet features?
No. Local-first describes where authority over the data sits, not whether the network is used. A local-first application can sync, cast, look up metadata or check for updates. The test is what happens when the network is gone: a local-first app keeps working normally, because the network was extending something you already had rather than delivering it.
Where does the term local-first come from?
From a 2019 essay by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan of Ink & Switch, presented at the Onward! conference. It sets out seven ideals for local-first software, including “the network is optional”, “the Long Now” — software that outlives its vendor — and “you retain ultimate ownership and control”.
What happens to my music if a local-first player is discontinued?
Nothing happens to the music. A local-first player stores its library index separately from your audio files and never becomes the place the music lives, so an abandoned player costs you an index another program can rebuild by reading the same folders. This is the practical difference from a service, where discontinuation and loss of the catalogue are the same event.
Does Digr upload my music library anywhere?
No. Digr has no account, no server and no cloud library. The index is a SQLite database on your own machine, built by reading your files. The one network feature is casting to a Google Cast speaker, and that works by serving the original file from your machine over your own local network — the file never leaves it.
- local-first
- ownership
- architecture
- streaming