Sub-feeds

Discussed in https://github.com/PlaidWeb/Chorus/discussions/21

^{Originally posted by fluffy-critter July 30, 2026}
The purpose to pagination was to have a means of incrementally updating a feed, but with the Chorus rewrite and trying to explain how the incremental updates would work algorithmically I've come to the conclusion that it's a lot more difficult than just having "here is the next page of data."

Right now I feel like a better approach is to have the ability to discover additional feeds from the current feed, and then those can be split up in whatever way makes sense to the publisher. For example, a sufficiently-large distributor might want to make sub-feeds for each artist.

There's a few shapes that could take, and I think one of them is having an entity declare a link to the collection, so a distributor's top-level feed could be like:

{
    "$type": "collection",
    "$items": [{
        "$type": "artist",
        "$id": "artist-fwiffo",
        "name": "Fwiffo the Great",
        "url": "https://mecagorp.com/fwiffo",
        "links": [{ "rel": "alternate", "contentType": "application/chorus+json", "href": "https://mecagorp.com/fwiffo.json" }]
    }]
}

or something. Then it would be up to receivers as to whether they want to automatically start ingesting all the related feeds, and each of those feeds would be subject to their own HTTP conditional transfer rules.

Having more feeds to check would slightly hinder performance, but the much simpler update algorithm would be worth it IMO.

Start with Discussion #21, which contains the proposal and examples for discovering additional feeds. No files, tests, or implementation entry points are named; the issue is not actionable until the feed model, receiver behavior, and acceptance criteria for sub-feeds are decided.