Hello, I'm Luiz. I am a software engineer from São Paulo. I still prefer a feed over an algorithm that rents my attention.

This is not a walkthrough of one blog, one framework, or one host. It is the idea: syndication as a contract. A publisher offers a document that changes when there is new work. A client pulls that document on its own schedule. Nobody needs an account on the originating site. Nobody needs the originating site to send mail.

Once you see it that way, readers, directories, and “email from RSS” are just different clients of the same contract.

The contract

A feed is a small, boring file. XML is the usual shape (RSS or Atom). JSON Feed is the same idea with a different costume. The format is not the point. The point is a list of items with enough metadata to stand alone:

• a title
• a summary or a body
• a date
• a permalink that will still work next year

The publisher’s job is to keep that file true. The client’s job is to poll it and show what is new.

There is no session. There is no ranking. There is no “for you.” If the file is valid and the URL is stable, any client can subscribe. That is why the same feed can land in a desktop reader, a phone app, a directory, and an inbox bridge without you building four products.

Pull, not push

Social platforms and most newsletters are push. You hand them an identity. They decide when you see the work, and they can change the rules without asking.

A feed is pull. The reader fetches. If you stop fetching, the publisher does not keep a relationship with you. If the publisher goes down, the last copy you have is still readable. If you change readers, you take the URL with you.

That is the theoretical reason RSS survived every “RSS is dead” cycle. The contract is smaller than a platform. Small contracts are hard to kill.

Autodiscovery is a pointer, not a brand

Humans are bad at remembering /rss.xml versus /feed versus /atom.xml. Machines do not have to guess if the HTML of the site points at the feed:

<link
  rel="alternate"
  type="application/rss+xml"
  title="The name of the publication"
  href="https://example.com/feed.xml"
/>

That tag is the idea: the document advertises its own syndicate. Good clients use it. Bad clients still accept a pasted URL. Either way, the feed URL is the identity of the channel, not the homepage, not a tracking redirect.

If you run more than one channel (changelog vs essays vs podcast), you have more than one contract. Do not smash them into one file to look simpler. Clients think in feeds, not in your sitemap.

What “valid” means

Clients are picky in boring ways. The theory is: the file is data, so it must parse.

• Escape XML (& is &). A title with an ampersand can take the whole feed down.
• Dates have a grammar (RFC 822 for classic RSS, ISO-8601 for Atom and JSON Feed). A pretty date in your UI is not a feed date.
• Permalinks are absolute and public. An item that points at a login wall or a temporary campaign URL is not syndicated. It is advertised.
• Titles and summaries in the feed should be the same facts you show on the article. Three different summaries (card, SEO, feed) is how you get three different lies.

Validation is not ceremony. If a reader “cannot add the site,” assume the file is wrong before you assume the reader is stupid. A public validator is enough.

Readers are just clients

A reader is software that stores URLs and polls them. Folders, search, and rules are UX on top of that.

Some clients live on a server (Feedly, Inoreader). Some live on the device (NetNewsWire, Reeder, quite a few Android apps). Some render the original site next to the item (NewsBlur). The product differences do not change the contract.

The only test that matters after subscribe: open an item. The link should be the permalink. If you land on an interstitial, a signup, or a different story, the feed failed the contract even if the XML was valid.

Pick one client and stay there. The switching cost is supposed to be low. The habit cost is not.

Directories are indexes of contracts

A directory is not growth hacking. It is a list of feeds grouped by topic. Crawlers and bored humans still use them.

The theory is the same as a search index: they need a live origin, a fetchable feed, and enough items to prove the channel is real. Empty and single-item feeds look like spam because they often are.

Two honest listings beat a paid blast into four hundred junk indexes. If a human reviews the submission, give them the feed URL. Autodiscovery should make that unnecessary. In practice, notes fields exist because sites forget the <link>.

Email is a client you do not control

A newsletter is a push channel you operate. An email bridge is a client that turns pull into push for someone who only opens mail.

Blogtrottr, Follow.it, and similar tools poll the feed and send a message. The subscriber is trusting that third party with an address. The publisher is not running SMTP.

That is a legitimate consumer of the contract. It is not a reason to skip the feed and go “email only.” Email-only means you own the relationship and the deliverability problem. A bridge means the feed remains the source of truth and mail is optional.

If you already send a newsletter, the clean model is still: the feed is canonical, the letter is a view. When those two drift, you have two publications.

Why this is not a frontend topic

A feed is an HTTP resource. It can come from a static file, a CMS, a database view, or a job that writes XML on publish. The stack does not matter. The invariants do:

1. Stable URL. Moving /rss.xml to /feeds/main.xml without a redirect breaks every client that already stored the old path.
2. One item per work. Do not emit drafts, internal IDs, or locale duplicates as if they were different stories unless they are different stories.
3. Idempotent polling. Fetching twice should not create two “new” items. Guids or permalinks must be stable.
4. Cheap to fetch. Clients poll. A 2 MB feed with full HTML for five years of posts is how you get rate limits and dropped subscriptions. Summaries plus permalinks are enough for most channels. Full text is a choice, not a requirement.
5. Same facts as the origin. If the site title and the feed title disagree, directories and readers will look like they are listing two publications.

Podcasts, changelogs, status pages, and release notes are the same pattern. A “blog” is only the most common noun.

A checklist that is only theory, applied

Before you tell anyone a feed exists:

1. The URL will not move, or the old URL redirects forever.
2. The origin document points at the feed (rel="alternate"), on the whole site, not only on an index page.
3. The file parses. Dates and escapes are correct.
4. Each item’s link is the public permalink.
5. Title, summary, and date are the same facts you already publish.
6. There are enough real items that an indexer can tell you from a parked domain.

Distribution then has three optional fans-out: people add the URL in a reader, a directory lists the contract, a bridge turns it into mail. You did not build three systems. You kept one honest file.

Closing

RSS is not nostalgia and it is not a growth hack. It is a small contract: a list of work, a stable address, clients that pull.

Keep the contract boring. Let readers, directories, and email be views. When the file is true, you do not need a platform’s permission to be followed.