Who owns the catalog?

Nintendo closed the 3DS and Wii U eShops in 2023 and thousands of digital-only games stopped being things you can buy. Letterboxd is in early sale talks with Netflix, Sony Pictures, and Paramount: twelve years of member-built lists and reviews, reportedly floated at $250m. Cory Doctorow has a name for this more insidious type of failure, use rights without tool rights: you're allowed to leave, but building the tools to actually do it is off limits. I won't be recommending any Alternative Methods here, lest the copyright police come knocking. It's the same pattern under two headlines and an essay: a collection is pointers into a catalog somebody else governs, and that catalog can close, get sold, or cut off access.

I'm of the Very Left persuasion that likes personally owning a toothbrush and collectively owning the housing, the factories, and the means of computation; what the headlines describe is neither.

The way out has good writeups already: Dan Abramov's a social filesystem and Paul Frazee's atmospheric computing both describe the same move, lifting the data out of the app so no single vendor is holding everyone's pointers, this post is my attempt to follow up and start my personal Blog Summer.

@chrisshank.com framed the general version of this while I was writing: digital spaces keep getting enclosed as long as identity, data, and distribution stay packaged inside an app. Building crate on atproto is a bet that they don't have to be.

Discogs publishes data dumps and MusicBrainz publishes CC0 dumps, so the data was never the scarce thing. What you can't download is the living edit process: twenty years of submissions, votes, style guides, and moderation that keep 19 million releases coherent, owned by one company.

I've been building a record collection app on atproto, working name crate: sign in with your handle, scan a barcode, the release lands on your shelf. Letterboxd for records, or Discogs with the account system swapped out for the atmosphere. Building it walks you straight into the question: on an open network, who governs the shared data everyone leans on?

And it's not just records: I'm a fairly active user of Cardmarket, Untappd, and TopLogger, and I spend a lot of time around the Merlin birdwatching crowd. Every one of them should have an atproto version, because atproto already solved the cold start that usually sinks a new app: the users. You bring your identity and your graph, so you're not launching to an empty room. What it doesn't solve is the catalog, and really not even the catalog data: any API or private database can hand you that. The important part is everything built on top, the curation, the provenance, the collaboration on one shared reference out in the open, where any app speaking the same lexicon can read and write it too, instead of inside somebody's private table. Trading cards, beers, boulder problems, bird species: each leans on a shared catalog that one company built and now owns, and an open replacement still starts cold, with an empty catalog and no trusted way to fill it.

The catalog is the moat

The (virtual) shelf of (music) records is the easy half. Shelf items are records in your repo, on your PDS, portable like everything else here. If crate dies your collection doesn't, because that part the protocol just hands you.

On screen, that looks like this:

After doing personal data management, which a lot of atproto native apps already do, the catalog is the hard half, as from what I've seen a lot of apps just have you write your own copy of the 'shared' data. Within the (current alpha of) Crate when you shelve a copy of Nevermind, your shelf item points at "the release": one shared entity that you, me, and every other collector reference. Somebody has to say what that entity is: the pressing, the year, which of four near-identical 1984 entries is the same record. A collection app without a shared catalog is a private spreadsheet.

teal.fm, the scrobbler in the atmosphere, gets to sidestep this. A play is a pointer to a recording, so teal leaves catalog truth to MusicBrainz and carries its ids along, which to me feels like a reasonable approach for scrobbles. A collection app can't outsource that: pressings, the gap between two represses are exactly what collectors care about, and exactly where a borrowed catalog has a risk of breaking down. So crate needs an answer for who owns the catalog, and @mokkenstorm.dev is not an acceptable one.

A moat is the thing that keeps a competitor from cloning you outright: the asset one company owns while everyone else rents access. Here it's the catalog, but by design Crate's bet, worked out over the rest of this post, is that you can lower the drawbridge and keep the moat: defensible because anyone can leave, not because they can't.

How it works today

The model, after a lot of staring at the ceiling: the catalog is seeded cold from the open dumps or manual entry by enthusiasts, so nothing is minted up front. The first time anyone touches a release, they mint its at:// record in their own repo, the same way they host their own posts, which is what via @alice.test means on a record page: the catalog data lives with whoever brought it in, and your shelf item strong-refs that uri, nothing is ever edited in place.

There's one move: mint a new record that supersedes an old one, with a strong ref back to it. Fixing your own entry supersedes your own; suggesting a change to someone else's mints your version superseding theirs. A suggestion isn't a special record type, just a superseding copy someone made, so the edit inbox is only a render over those copies: it diffs an incoming version against what you have, shows the fields that changed and hides the rest, and adopting one re-points your shelf. Nothing gets approved; you adopt a version or you don't.

The useful property: provenance is decentralized and signed. Every version lives in its author's repo, timestamped, attributable, and queryable: through crate's own appview, or through Constellation, the community-run backlink index that works for any app. "Show me every version of this release" is a public question with a public answer. No private moderation database.

Nobody picks the canonical record

No worker or policy of mine combines everyone's edits into one blessed value, because records supersede rather than merge. A version gets adopted and rises in the tally, or it doesn't; you mint your own and it competes, or you don't.

So which record is "the release"? When superseding chains fork there are several, and no one decrees a winner. "Canonical" is whatever your query returns. Each variant carries public stats: how many shelves point at it, how recently it was touched, how complete it is, where the indexers rank it. All of it computed from signed records anyone can re-tally.

The appview's job is to expose those stats and offer resolution strategies: most-adopted, most-recently-updated, most-complete, or defer to a particular indexer you trust. Switch strategies and the catalog re-resolves: same records, different answer. The closest thing to editorial power, whoever computes the tally, dissolves too: the inputs are public, so anyone can run the numbers.

What happens when it breaks

The obvious failure is crate itself dying: I lose interest, or the funding, or the plot, or somebody shows up waving $250m. Minted records and every proposal already live in user repos, and because the strategies are just functions over those records, a new appview can pick them up and recompute the same stats without anyone handing it the data first. Carrying on where I left off doesn't need my permission.

The other failure is an edit war. Nobody can overwrite your version, because edits don't merge: a disputed release forks into competing superseding records, and which one surfaces depends on the strategy the viewer chose. Losing under the default costs you the top slot, not your data: your fork stays live, and anyone whose strategy favors recency or completeness can still surface it over the popular one. And if a referenced record vanishes from its repo entirely, shelf items carry an embedded snapshot alongside the strong ref, so your collection keeps rendering exactly as it did, even if the original never comes back.

As a bonus the 'centralized' infrastructure pieces like the aforementioned constellation back-links and relay moderation decisions ride along on community infrastructure.

Why write this down now

Crate is a hobby. It has approximately one user, and they're typing this. That's the correct time to write governance down: the cost of being wrong is a markdown edit, and every rule exists before anyone has an incentive to bend it.

This is the friendlier end of the problem, too. Convergence here happens between repos: competing records for the same release, all speaking one lexicon, resolved by whichever strategy you point at them. The harder kind is convergence between apps: schemas that never agreed and never will, holding records that still ought to correlate, maybe a nice topic for a follow-up post.

If you're building where users lean on each other's records for core data, I'd like to compare notes: crate's lexicons are public. The protocol hands us signed, portable, queryable provenance for free. This post is one more proposal for what to build above it, and an invitation to collaborate on that sweet cross-app data use.