Should large feeds have a way to be served in parts?

[hhkaos]

The spec is explicit today, and deliberately so:

The feed is an interchange format, not an API: no pagination, no filtering, no authentication, no federation. — spec/v0.4/README.md

This issue is not a proposal to reverse that. It is to record the first real evidence that pushes on it, so the decision is re-made on data rather than drifting.

The evidence

https://eventos.wiki/events.json, a registered adopter feed, valid 0.4: 551,915 bytes, served in 26–51 s (measured three times today). Nothing about it is invalid, and the publisher is doing nothing wrong. But:

• The daily health check needed its timeout raised to 60 s with retries to stop reporting it as broken (fix(health): validate feeds against their own spec version, class failures #43).
• The online validator cannot check it at all today: its fetcher gives up at 5 s per hop / 10 s total, and the badge reads "unreachable" (The fetcher's timeouts call a healthy adopter feed unreachable ote-tools#70).
• Every consumer re-downloads all 550 KB to learn that one event changed. There is no conditional or incremental path other than HTTP caching of the whole document.

One feed is not a trend. But it is the largest adopter we have, and it is the shape the format encourages: a feed carries a community's whole history, and history only grows.

The tension

The "not an API" decision is a good one and buys a lot: any static host can serve OTE, no server code, no negotiation, one URL to remember. Pagination is the single thing most likely to erode that — the moment a consumer must follow links to be correct, "download the file" stops being a complete implementation, and every downstream tool grows a loop plus its failure modes.

So the question is not "should feeds paginate" but: is there a mechanism that helps large publishers without making the simple case harder?

Options worth weighing

1. Do nothing. Feeds are allowed to be large; consumers get generous timeouts. Costs nothing, and the pressure is real but so far comes from one publisher.
2. A non-normative convention for splitting by time, e.g. a feed per year plus a small index, using the existing extension mechanism instead of new core fields. Publishers with history opt in; consumers who ignore it still get a valid document.
3. An optional next link, RFC 5005 / JSON Feed style. Standard, well understood — but it is the option that changes what "consuming a feed" means, because a consumer that ignores next silently gets partial data. If this is ever adopted, the archived-vs-paged distinction matters: an archive link (older, immutable pages) is far safer than a paged one.
4. Recommend serving updatedAt-scoped subsets without any spec change — the publisher's choice of what to include, which is already allowed.

Options 2 and 4 need nothing from the schemas. Only 3 is a real spec change, and it is the one with the sharpest downside.

What would help decide

• How many adopters exceed, say, 200 KB or 5 s? Today the answer is: one of three. docs/data/feed-health.json could record size and response time so this stops being anecdote.
• Do any consumers actually struggle, or is it only our own tooling's timeouts?

Not a v0.5 candidate yet — a decision that should be made with a second data point, not a first.