ModuleDraft 0.2, for comment

On this page
  1. Feeds
  2. People's feeds
  3. Follows
  4. Example: an app that collects new releases
  5. Recommendations are a feed
  6. Open questions
  7. Prior art

Feeds module (draft 0.2)

Status: draft for comment. Namespace: org.openmusiccollection.feeds. Needs: Core 1.0.

Feeds cover two things the core leaves out: who a person follows (artists, labels, other people), and what they publish. A feed is what RSS has always been, a document a publisher hosts listing what's new, with one addition: each entry carries an OMC record, so an app can add it to a collection in one step and recognise it when the person already has it.

The module reuses existing feed formats rather than inventing one. Any feed reader can subscribe to an OMC feed and shows plain entries; an OMC app reads the same feed and gets releases it can keep.

Feeds

JSON Feed 1.1 (jsonfeed.org) is the main format. JSON Feed allows extensions as members starting with _, so each item carries its OMC record in _omc, and the feed says who publishes it:

{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Mira Holt",
  "home_page_url": "https://mira.example",
  "feed_url": "https://mira.example/feed.json",
  "hubs": [{ "type": "WebSub", "url": "https://hub.example/" }],
  "_omc": { "version": "0.2", "kind": "artist" },
  "items": [{
    "id": "night-drive-ep",
    "url": "https://mira.example/night-drive",
    "title": "Night Drive EP",
    "content_text": "Four tracks for the drive home. Out now.",
    "image": "https://mira.example/night-drive.jpg",
    "date_published": "2026-10-10T08:00:00Z",
    "_omc": {
      "type": "item", "id": "night-drive-ep", "kind": "release", "title": "Night Drive EP",
      "artists": ["Mira Holt"], "release_date": "2026-10-10", "label": "Lumen Records",
      "ids": { "upc": "0123456789012" },
      "copies": [{ "platform": "bandcamp", "ref": "3170425711", "url": "https://mira.bandcamp.example/album/night-drive-ep", "ownership": "none" }]
    }
  }]
}
  • _omc.kind on the feed is artist, label or curator (a person sharing what they like).
  • _omc on an item is a core item (a release or a recording), with copies naming their platform instead of a source id, since a feed has no sources. Ids are the publisher's and, as everywhere, local: an app matches what it reads by copies and identifiers.
  • An entry without _omc is still a feed entry: an app MAY guess a release from its links (marking what it adds with provenance origin inferred).

Atom and RSS 2.0 feeds MAY be published alongside, for readers that know only those. Each entry carries the same record as JSON, in an element of the namespace https://openmusiccollection.org/feeds/0.2:

<entry>
  <title>Night Drive EP</title>
  <link href="https://mira.example/night-drive"/>
  <updated>2026-10-10T08:00:00Z</updated>
  <omc:item xmlns:omc="https://openmusiccollection.org/feeds/0.2">{"type":"item","kind":"release","title":"Night Drive EP","artists":["Mira Holt"],"copies":[…]}</omc:item>
</entry>

Push. A feed that lists a WebSub hub (hubs in JSON Feed, <link rel="hub"> in Atom) is pushed to subscribers when it changes; otherwise apps poll it, respecting HTTP caching.

Discovery. A publisher's pages link their feed the usual way: <link rel="alternate" type="application/feed+json" href="…">.

People's feeds

A home MAY publish one of the person's lists as a feed (_omc.kind: curator), at a URL the person chooses to share: their picks, a radio show's playlist, a shop's staff favourites. The newest additions come first; each entry is the item as the home has it, without the person's private data (via, the item's note, other apps' data). The list entry's note is the exception: it is the blurb the person wrote for this list, so it travels, in content_text. Following a person is then the same as following a label. The person can stop publishing at any time, and the URL stops working.

Follows

Who the person follows MAY travel with the collection, as module records:

{"type":"org.openmusiccollection.feeds/follow","id":"f1","kind":"label","name":"Lumen Records","feed":"https://lumen.example/feed.json","ids":{"musicbrainz":"…"},"followed_at":"2026-03-01T10:00:00Z"}

kind is artist, label or curator. Consumers that don't implement Feeds keep these records, as the core requires. An app can also keep follows itself: they belong in the collection when the person wants them to move with it.

Example: an app that collects new releases

An app that brings music into the person's collection, built only from public pieces:

  1. The person connects it to their home with library:add (Access); the app makes its list, "New from labels I follow", and, to keep follows in the collection, asks for a view with "records": ["org.openmusiccollection.feeds/follow"] and library:write. ("Add music to your collection. Only: New from labels I follow, your follows.")
  2. It follows labels and people the person chooses: in its own screens, or as follow records written to the home, which the person keeps when they change apps.
  3. It reads those feeds (JSON Feed, Atom or RSS), pushed by WebSub or polled.
  4. It adds each release the person keeps (or every new release, if they say so) with POST /items?list=<its list>. The home answers existing for a release the person already has, and the app shows it as already kept, or held while the person decides.
  5. Its list is an ordinary list. Any other app the person uses shows it, and it moves with the collection.

The same shape fits other apps that bring music in. An app that reads the person's email (with its own access to their mailbox, granted by the mail provider) finds Bandcamp receipts, label newsletters and links friends send, and adds what it finds the same way, marking guesses with provenance origin inferred. It never sees the collection. Music sent to the person, rather than fetched by an app, is the Share module.

Recommendations are a feed

Recommendations are music the person doesn't have, so they aren't items until the person keeps one. An app that finds similar-sounding tracks, or what other buyers of a record bought, publishes its suggestions as a feed (_omc.kind: curator), one per seed or per person. The person follows it, and what they keep becomes an item. Their collection never fills with music nobody chose.

Open questions

  1. Should publishers sign feeds, so an app can show "published by the artist"?
  2. Should a feed entry carry offers (prices), or link to the Catalog and Commerce module?
  3. A people's feed publishes what someone adds: should it also say what they removed?

What was decided, and when, is in the changelog.

Prior art

RSS and Atom, JSON Feed, WebSub, the Podcasting 2.0 namespace (which extended RSS rather than replacing it), Bandcamp's following and fan feed.