This document preserves the development history of the project. It is not technical documentation for the current scraper worker and must not be used as instructions for writing data into RSS Watch. Historical endpoint names below are preserved as archive references only and are not guarantees about the current API contract.
The earliest preserved RSSWatch material from 2010 describes the project as a privately built, web-based RSS reader. It was partly inspired by desktop readers of the time, but its distinguishing feature was that RSSWatch would not only display new entries. It would also detect when already published material changed.
RSSWatch 2.0 was rebuilt from scratch during the spring of 2010. The project covered readable diffs, version history, removed or changed posts and comments, and automatic discovery of RSS links from ordinary web pages. Preserved runtime logs from 2010 also show the service operating through /rsswatch/, accepting monitored URLs and reporting LOST items through an #rsswatch.monitor channel. That idea - following what changes after publication - survived into later generations of the service.
A 2019 retrospective describes how the older RSSWatch environment died after a power failure around Christmas 2015. By the time the systems were being restored, parts of the old PHP code and infrastructure had become obsolete. The original service therefore did not return in the same form.
Some of the technical experience lived on in other libraries and tools, including HTTP and feed handling that could later be reused when the RSS project was revisited.
Archived Confluence material from the period between the original RSSWatch service and the 2021 rebirth preserves an important part of the design direction: the RSS service was not only about reading a single upstream feed. Documentation describes a feed-fetcher that could expose a monitored source by id or name and merge several feeds into one larger compilation.
This material also documents the idea of controlling which feeds were visible through a specific API host. The later Confluence examples use Earth616 as a concrete case: some feeds could be available through the Earth616-facing API while not necessarily being part of the globally supported Tools feed list.
These older behaviors are useful historical context, but they are not current operational documentation.
In 2019, plans to resume RSS monitoring with modernized code were documented. The description returned to the 2010 core: fetch feeds, monitor sites, and detect changes in material that had already been published.
NetCurl development became part of the new foundation and was used for experiments with more robust fetching and parsing.
In October 2021, RSSWatch was described as coming back after several years away. An important new direction was to avoid depending on a website providing a proper RSS feed. DOM parsing experiments made it possible to locate content on ordinary web pages and turn it into a feed-like representation.
The new generation was also tied more closely to ToolsAPI. Multiple secondary collectors could fetch material and deliver it to Tools for central storage and presentation. A separate Earth616 article from the same period described the goal as making sites without RSS easier to follow without trying to replace the original source.
The former Confluence documentation contains a page named "RSS Feeds", page id 329305, created in October 2021 and last updated on November 14, 2021. It explicitly says that RSS Feeds had its "rebirth" and describes the project as a way to:
The archived page documented public read resources under /api/rss and /api/rss/feed. A feed could historically be selected by numeric id or by a name/domain selector. For example, the documentation used MovieZine as an id-based feed and Marvel as an example of a selector that could return a compiled view containing several matching feeds.
A related Confluence API page explains the model in more detail: feed agents fetched content, the fetched material was collected and merged into an RSS container, and selectors could therefore produce a merged list from several sites or feeds. The same documentation also described RSS-less sites as a supported case when their page structure was consistent enough to parse.
The Confluence notes also preserve an HTTP host restriction idea. Earth616 was given as a real example of a consumer of the RSS resources, and the proposed model would allow different API hostnames to expose different feed selections. This is historical architecture context, not a description of the current authorization model.
The worker protocol was not presented as a public mechanism for creating arbitrary normalized entries. The public examples were reader/feed endpoints.
The modern RSS Watch service in Tools has grown from the same basic idea. It now includes public feed browsing, categories, full-text search, version history, subscriptions, analytics, and AI-assisted features on top of the collected material.
Collection remains a separate operational function. The public integration surface is for reading and using material published by Tools, not for posting custom normalized entries into the internal ingestion pipeline.
Primary Tornevall sources documenting the development:
/rsswatch/, monitored URL registration and LOST change-monitor events.329305, version 3, last updated 2021-11-14.For current user documentation, see RSS Watch.