Your Notes Are Already a Feed: A Folder of Markdown Is an RSS or Atom River

An Atom or RSS feed is a tiny XML wrapper around a list of files. The IETF specification asks for seven required elements; your folder of Markdown already has every one of them in the file path, the H1, and the date. You do not need a publishing platform to put a feed online.

The Atom specification was published as IETF RFC 4287 in December 2005 by Mark Nottingham and Robbie Sayre, and its first sentence is precise: "This document specifies Atom, an XML-based Web content and metadata syndication format."¹ The shape it specifies is small. The wrapper element needs four fields. Each item inside needs three. That is the contract. Everything else in the spec is optional extensibility you can ignore until you want it. Twenty years on, the contract has not moved, and your editor's .md files already meet it.

What does a feed actually require?

A feed requires exactly seven elements at minimum: four on the wrapper and three on each item inside. The wrapper needs an id, a title, an updated date, and an author; each entry needs an id, a title, and an updated date. That is the whole contract. Everything else in the spec is optional extensibility.

Section 4.1.1 of RFC 4287 spells the wrapper out: "atom:feed elements MUST contain exactly one atom:id element," "atom:feed elements MUST contain exactly one atom:title element," "atom:feed elements MUST contain exactly one atom:updated element," and one or more atom:author elements unless every entry carries its own author.² Section 4.1.2 names the entry contract in the same shape: "atom:entry elements MUST contain exactly one atom:id element. … atom:entry elements MUST contain exactly one atom:title element. atom:entry elements MUST contain exactly one atom:updated element."³

Read those two sentences together and the spec collapses to a checklist. An id, a title, an updated, an author on the outside; an id, a title, an updated on each entry. The rest of the 41-page RFC is extensibility — alternate links, summaries, categories, content types — and you can leave it for later.

RSS 2.0 is even smaller. The RSS Advisory Board's current specification says the channel needs title, link, and description; for an item, "All elements of an item are optional, however at least one of title or description must be present."⁴ The two formats are different ways of saying the same thing — name the river, name the items, date them, and put a stable URL on each.

A folder of Markdown already has every field by accident. The folder name is the channel title. The site URL is the channel id. The file's H1 is the entry title. The file path is the entry id. The file's modification time — or the date in the YAML frontmatter — is the entry's updated. Nothing about the substrate had to change.

Why is a feed coming back into focus right now?

Feeds are coming back into focus because the readers of the web are changing again — from people clicking links to agents pulling them. The same affordance a human reader wanted in 2018 is what an AI agent needs in 2026: a predictable, structured, chronological list of files at a known URL.

The 2018 Wired piece "It's Time for an RSS Revival" named the moment when the open syndication layer started to re-matter to humans; eight years on, the same shape applies to a different reader. Julien Reszka's May 2026 essay names what the current trajectory rests on: "The clearest evidence that RSS was never really dead is podcasting. Every podcast app (Spotify, Apple, Overcast, Pocket Casts) pulls episode files and metadata from RSS feeds. The $25 billion podcast industry runs on a protocol published in 2002. Nobody disrupted it because there was nothing to disrupt: open, free, no middleman, nothing to negotiate access to. The episode is at the URL in the feed, always has been."⁵ He is not claiming agents have arrived. He is naming what a pull-based interface looks like when it works, and asking why a writer would not put one on their own folder.

This piece is the syndication-mechanism companion to Your Notes Are Already Publish-Ready, which covered the same folder of .md going to the browser through a static-site generator. Together they are a diptych: the website is how a person finds your writing; the feed is how a reader or an agent comes back for the next file. The substrate is one folder.

What does a feed look like, written by hand?

A feed written by hand is twenty lines of XML that walk a folder, read each file's H1 and modification time, and print one <entry> per file inside one <feed> wrapper. There is no magic. The script below is a minimal Atom builder; drop it next to a folder of .md and pipe its output into feed.xml.

#!/usr/bin/env bash
set -euo pipefail
SITE_URL="${1:?usage: build-feed.sh https://yoursite.tld}"
SITE_TITLE="${2:-My Notes}"

cat <<HEAD
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>${SITE_TITLE}</title>
  <id>${SITE_URL}/</id>
  <updated>$(date -u +%Y-%m-%dT%H:%M:%SZ)</updated>
  <author><name>${SITE_TITLE}</name></author>
HEAD

for f in $(ls -t *.md); do
  slug="${f%.md}"
  title=$(awk '/^# /{print substr($0,3); exit}' "$f")
  updated=$(date -ur "$f" +%Y-%m-%dT%H:%M:%SZ)
  printf '  <entry>\n    <title>%s</title>\n    <id>%s/%s</id>\n    <updated>%s</updated>\n  </entry>\n' \
    "${title:-$slug}" "$SITE_URL" "$slug" "$updated"
done

echo "</feed>"

Read the receipt sitting inside the script. The file's H1 line becomes <title>. The file path becomes <id>. The file's modification time becomes <updated>. Section 4.1.2 of RFC 4287 is satisfied by three Unix tools and a for loop.³ No database, no CMS, no platform login — the folder is the source, and the script is the build. A YAML date in your frontmatter would replace date -ur if you prefer the author's intent over the filesystem's record; the yaml-frontmatter post covers the syntax, and either way the spec is met by a date.

If you have already adopted a static-site generator from the publishing companion, you do not need the script at all. The generator emits a feed for you. The point of writing the script down is to show that the wrapper is small enough to write by hand, and that nothing about the format depends on owning the wrapper to own the contents.

What do the popular generators do automatically?

The three most-used Markdown-folder generators emit a feed by default or with one plugin line, and each is open source. Hugo ships it as a built-in template, Jekyll loads it through a default plugin, and Eleventy adds it as a one-package install. Their own documentation is the receipt.

Hugo's RSS templates page says it plainly: "By default, when you build your project, Hugo generates RSS feeds for home, section, taxonomy, and term pages."⁶ No plugin to install; the feed is part of what the build does.

Jekyll's default Atom path is a 882-star MIT-licensed plugin called jekyll-feed, whose own README describes it as "A Jekyll plugin to generate an Atom (RSS-like) feed of your Jekyll posts" and notes that "The plugin will automatically generate an Atom feed at /feed.xml."⁷ The plugin ships in the minima theme that GitHub Pages serves by default, so a Jekyll site on GitHub Pages has a feed without any manual wiring at all.

Eleventy's official RSS plugin is a one-package install that emits all three formats from the same folder. Its docs read: "A pack of plugins for generating an RSS (or Atom or JSON) feed using the Nunjucks templating syntax,"⁸ with a type option whose values are "atom" (default), "rss", or "json".⁸ One folder of .md. Three valid syndication targets. The choice between them is reader and agent compatibility, not file format.

JSON Feed exists precisely so that the file-as-feed-entry idea is not held hostage to XML. The Version 1.1 specification, authored by Brent Simmons and Manton Reece in 2020, names the trade in one sentence: "The JSON Feed format is a pragmatic syndication format, like RSS and Atom, but with one big difference: it's JSON instead of XML."⁹ The required fields are the same kind — id, title, date_published, content — under different keys. Different language; same underlying contract.

Where Obsidian Publish sits in this landscape

Obsidian Publish is the convenience path on this axis: you click a button and a public site appears. The product page lists $8 USD Per site, per month, billed annually and $10 USD Per site, per month, billed monthly — a serious price for a serious convenience.¹⁰ The trade is what the convenience is paid for.

The listed features are hover previews, graph view, stacked pages, backlinks, themes, custom domains, password protection, and analytics — RSS or Atom is not named among them.¹⁰ That is a factual gap on the product page as it stands today, not a verdict on the company; if a feed feature ships there in the future, this paragraph will need updating.

The villain in this story is not a vendor. The villain is the shape — a folder of Markdown trapped behind any publish product whose contract you do not own. Steph Ango, the CEO of Obsidian, has written the clearest line on the right side of that trade himself, on his own domain: "In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last."¹¹

The post is called "File Over App," and the point of this essay is that feeds over apps is the same sentence one layer down. Your folder already produces a feed; whether a vendor's button produces one too is a separate decision.

The publishing pattern broadens How to Grow a Digital Garden in Plain Markdown at the substrate layer, and Your Hyperlinks Survive the App at the link layer. The feed is the same idea at the update-stream layer.

The honesty caveats nobody mentions until the feed breaks

Five caveats sit underneath the "your folder is already a feed" claim, and a writer who ships a feed without reading them will see at least one of them in the first week. Read them once. None of them break the pattern; all of them break specific assumptions about what a feed will do for you.

• A feed is XML well-formedness, not magic. A stray & in an H1 or an unescaped < in a body breaks the file. Feed readers either fail loudly or, worse, silently skip the entry. The build step has to escape special characters before writing the entry, which is the only thing the twenty-line script above leaves to you to add for a production feed.
• Discovery is still the unsolved half. A feed at feed.xml is publishable, but readers and agents have to find it. The accepted method is a <link rel="alternate" type="application/atom+xml" ...> tag in the site's HTML — Hugo's RSS docs document the convention out of the box⁶ — but a hand-rolled feed needs the same line. The feed file exists; the discovery line is what tells readers it does.
• AI-agent readers are nascent, not arrived. The "agents need RSS" trajectory in Reszka's 2026 essay is a demand signal, not proven adoption.⁵ Podcasting is the precedent and the proof that pull-based, file-over-platform syndication scales; agentic feed-reading is the next test, and it is still being built. Ship a feed because humans read feeds today; the agent layer is upside.
• Wikilinks will not render in <content>. If you put your raw notes into the feed body and the notes use Obsidian-style [[Page]] links, those will render as literal text in a reader. CommonMark [text](url) links survive because they are part of the spec; wikilinks are not, as covered in Wikilinks Aren't Plain Markdown and the link-substrate piece Your Hyperlinks Survive the App. The fix is either to convert wikilinks at build time or to write CommonMark links in any note you intend to syndicate.
• The RSS 2.0 spec is frozen at version 2.0.1. The RSS Advisory Board page is explicit: "the RSS spec is, for all practical purposes, frozen at version 2.0.1."⁴ That is a feature for a syndication target — a stable contract that will not change underneath you — not a bug. But it does mean active format evolution lives elsewhere: in JSON Feed, in IndieWeb h-feed, in Atom. Treat RSS 2.0 as the lowest-common-denominator reader compatibility, not as where the format is going.

Where MNMNOTE fits in the substrate

In a note app that writes plain .md files locally, the feed step is the same as anywhere else. The file the editor saves is the file the build step reads; there is no vendor-specific export between the two. The substrate is one folder, shared between writing tool and syndication tool.

CommonMark links survive the trip; the H1 becomes the entry title; the file's date becomes the entry's updated. The folder is shared between your editor and your syndication tool the same way a folder of photos is shared between a viewer and a print service — the files are one source, and the tools are two readers of it.

That is the same shape covered in the publishing companion. There the folder reached a browser through a static-site generator; here it reaches a feed reader or an agent through the same generator's RSS output. Both pieces are the case for keeping the file at the center: the editor is the writing surface, the generator is the publishing surface, and the folder is the contract between them.

Frequently asked questions

How do I publish my notes as an RSS feed? Point a static-site generator at the folder of .md files; the generator writes a feed in its build output. Hugo emits an RSS feed by default for home, section, taxonomy, and term pages.⁶ Jekyll's jekyll-feed plugin auto-generates an Atom feed at /feed.xml.⁷ Eleventy's RSS plugin emits Atom (default), RSS, or JSON from the same folder.⁸ If you do not want a generator, the twenty-line script in this post writes a valid Atom feed from a folder of .md. The folder is the source either way.

Do I need a static site generator for a feed? No, but it is the easier path. The Atom specification needs exactly seven elements at minimum — four feed-level (id, title, updated, author) and three entry-level (id, title, updated) per RFC 4287 §4.1.1 and §4.1.2.²³ A small shell script that walks a folder and emits one <entry> per file is enough to be conformant. The static-site generator is the convenient automation around that loop, not the format itself.

Can I get an Atom feed straight from a Markdown folder? Yes. Eleventy's official RSS plugin is "A pack of plugins for generating an RSS (or Atom or JSON) feed using the Nunjucks templating syntax,"⁸ with type defaulting to "atom". Hugo and Jekyll do the same with their own conventions. Or write your own builder — the file's H1 supplies the entry title, the file path supplies the id, and the file's modification time (or YAML date) supplies updated. The spec is met by mapping three fields per file.

Do I need a publishing platform like Obsidian Publish to get a feed? No. Obsidian Publish currently lists $8 USD Per site, per month, billed annually and $10 USD Per site, per month, billed monthly,¹⁰ and the product page features list does not name an RSS or Atom feed.¹⁰ The same .md files render via Hugo, Jekyll, Eleventy, or any builder you write yourself, and the feed comes out the other side. The choice is between the convenience of a click and the permanence of a folder you own.

Why is RSS getting attention again in 2026? Because pull-based syndication is becoming the polite interface for both humans and AI agents. Julien Reszka's 2026 essay names the precedent: "The $25 billion podcast industry runs on a protocol published in 2002. Nobody disrupted it because there was nothing to disrupt: open, free, no middleman, nothing to negotiate access to."⁵ Whether agents will rely on RSS the same way podcast apps have is still being built; what is settled is that an open syndication layer scales when nothing about the substrate is owned.

What is the difference between RSS, Atom, and JSON Feed? They are three formats expressing the same idea. Atom is IETF RFC 4287 from December 2005¹ and is the stricter standard. RSS 2.0 is the older shape — the current specification is, per the RSS Advisory Board, "frozen at version 2.0.1,"⁴ which is a stable target rather than a moving one. JSON Feed Version 1.1, by Brent Simmons and Manton Reece in 2020, is the same contract in JSON: "a pragmatic syndication format, like RSS and Atom, but with one big difference: it's JSON instead of XML."⁹ Pick one, or emit all three; the file in your folder does not change.

Is RSS the same as podcasting? Podcasting is one specific application of RSS — the protocol the audio industry settled on. Reszka's piece names the scale: "Every podcast app (Spotify, Apple, Overcast, Pocket Casts) pulls episode files and metadata from RSS feeds."⁵ Your notes feed is the same shape applied to text. Wherever an entry's content is a URL to a real file (an MP3, an HTML page, a Markdown source), the wrapper is doing its job: name the river, list the items, date them.

A folder of Markdown was always a feed in waiting. The IETF specified the wrapper in December 2005 and asked for seven fields; a folder of .md on your own device, like the ones in mnmnote.com, already has all of them in the file path, the H1, and the date.