Architecture

Kolofon · 14 August 2026

23 · The feed as an output

found in someone else's reader, not in our own site

23 · The feed as an output

Text: Kolofon

Content leaves Kolofon by three routes. As a page — rendered by a browser, where everything relative resolves against the address the reader is standing on. As a book — typeset by Typst, where everything must be settled before compilation, because paper has nowhere to reach. And as a feed — read by a program we do not know, on a device we cannot see, in a context we do not control.

The third route is the easiest to neglect, because the author never travels it. The page they see after every deploy. The book they download when they publish it. The feed they never open — and even if they did, they would see valid XML and learn nothing. A fault in a feed shows up only in somebody else's hands.

First rule: no relative addresses in a feed. On the page `/images/frames/2026/rock.jpg` is fine, because the browser knows what to resolve it against. Lifted out of the page and dropped into a reader, it leads nowhere. A reader given no image in the feed will fetch the page and try to extract one itself; that is exactly where it hits this problem, and it draws an error glyph. It looks like a broken photograph and it is a broken feed.

Second: a feed may not assume the reader will do anything beyond reading the feed. It will not fetch the page, run a script, or unfold any abstraction. Whatever is meant to be seen must be in the file — image, text, author, date. A feed that is only a list of links delegates the work to the page and loses control of it.

Third: the same fact is written down several times over, because readers read different fields. The image goes out at once as Media RSS, as an enclosure and inside the content. This is not redundancy from indecision — it is the only way not to choose the reader's reader for them. The cost is a few hundred bytes per entry.

The fourth rule is less obvious and only emerged from use: the length of a feed is not a performance question but a question of how much history a new subscriber receives. Whoever subscribes today gets exactly as much past as the feed happens to carry — and never more, because readers have no way to reach backwards. Twenty entries, at a daily writing pace, is a fortnight. The whole archive had vanished for anyone who arrived later.

The answer is a length parameter in the address, not a permanently higher number. Two different consumers with contradictory needs sit on the same address: a human with a reader wants the archive once, on first sync, while a distribution automation wants a narrow window of the newest entries and treats everything it sees there as material to push onward. A feed lengthened for the human would push half a year of archive onto Facebook as fresh posts. One address, two contracts — the parameter separates them.

The last point concerns not the format but the door to it. A link straight to the feed file is technically correct and practically harmful: someone clicking it without a reader gets a wall of XML and closes the tab convinced something has broken. So the link opens an explanatory sentence and an address to copy, and the file itself gets a separate exit for those who know why they are opening it.