In a previous article, I described why RSS is not perfect and has issues to solve. Please see Why I need RSS 3.0 for more details. In this article, I will try to describe how RSS can be improved and what can be done to make it better.

Current state

Existing RSS solutions do not change the basics and follow pretty simple specification published in 2009. Unfortunately, the majority of apps and services add functionality on top without fundamental modifications. A few solutions added full-text search and filtering/grouping by categories. Other paid solutions like Feedly added AI aggregation and categorization while allowed 3rd party integrations for outsourcing flexible rules back to users. Opposite to solutions-services, there are tremendous amounts of small and/or open-source alternatives that are much more flexible and functional-rich but could be much better at scale and long-term support. Rumors say that every software engineer should build their own RSS app. Only a small amount of people invent and build something new or interesting like Awakari

Atom and RSS formats are simple and pretty similar under the hood. Both can be extended by adding optional custom XML tags. Unfortunately, custom tags are ignored most of the time and everyone sticks to only the required fields. I would not expect any updates from RSS advisory board any time soon as the popularity of RSS is decreasing over time.

JavaScript and TypeScript

I want to make a very technical and controversial analogy, that I will probably regret later. I feel that the RSS format is very similar to JavaScript. It's simple, mature and it works. People are building apps and services based on it, others use those. The bad part is that it's hard to extend and hard to build complex solutions. TypeScript added types to JavaScript. TypeScript is not perfect and has its flaws, but reduces complexity and saves time a lot. It allowed developers to extend existing solutions and integrate different packages in a much more efficient way. I want a TypesScript for RSS/Atom.

Domain

To improve the current state of things, we need to create our specification as an alternative. The issue is that I'm not good at writing specification papers, but a bit better at building things. So let's skip the boring part and jump into defining a domain and hope that it will be extendable and comfortable to work with and will result in a specification eventually in an empirical way.

Post concept

First of all, we need to introduce a post, that will be similar to the RSS item. It should have metadata to identify what channel it belongs to and simplify management. Opposite to the RSS item, the post should have no required fields. Post should have a list of values that can be presented in key/value format, similar to a plain JSON object. More about keys/values is described later in a content concept paragraph.

Channel concept

The channel is a basic block for the domain. It should have information about content, owners, and contacts similar to the RSS channel. Opposite to existing solutions, the channel should also define fields and sections. Fields should define a list of expected, but not mandatory, values in the post. Sections should define how post values should be displayed to the user. More about fields and sections will be explained in a content concept paragraph.

Subscription concept

Users interested in a channel can subscribe to it. Subscriptions should have information about the channel and a list of filter rules that will be used to filter posts. Filters can be built based on fields defined in the channel. Once the channel is updated, subscription filters will be re-validated and notify the user if needed. Users should be able to enable notifications for subscriptions to get notified about new posts if needed. Multiple subscriptions can be created for the same channel with different filters.

Content concept

Content is a key concept in the domain. A new set of data types with corresponding metadata/logic should be introduced. While RSS/Atom have documentation about field content and how app/service should treat them, content fields/values/filters/sections should work with a set of real-world types that the creator will use to form channels and posts. Data types should be self-explanatory and easy to manage and understand.

For example, the number type is a valid type that can be used for giving absolute values, but money\length\speed\etc. types should be introduced to provide more details and abilities. For example, the money type should contain currency metadata in a channel field definition. Currency metadata will allow the consumer to auto-convert values to a desired currency on UI. On the other hand, the length data type should provide the ability to convert the value from metric to imperial system and backward.

Post representation can be simplified by splitting it into multiple sections. The user interface evolved into a set of common and well-known building blocks that are used on all major platforms. For example, a Markdown section can display a markdown value from a post field that is defined in a channel. Another example of a section is Gallery which can display images. Sections will use field metadata from the channel and values from the post. User settings and modifications, like font and colors, can be injected into sections to represent information in a more friendly way.

Filters can be constructed from channel fields and provide the ability for users to exclude unwanted posts from the feed. Filters setup can be stored as part of the subscription, providing the ability for users to quickly change filters by switching subscriptions. Subscription with filters defines user interests accurately, it allow to send notifications immediately.

Extensibility and configuration

By using channels, posts, subscriptions, and content concepts, the solution can be extended for a variety of different purposes: news sites, personal blogs, auctions, rental agency listings, car-for-sale listings, etc. A set of unique sections can be introduced to provide integration and functionality from partners. Consumers on the other hand can consume data in the way they want: custom filters and notifications, adding/hiding post sections, unified UI, and experience.

AI features can be applied on top with greater accuracy than to RSS posts. LLM (Large Language Model) is not a silver bullet, that will solve all problems, but an extremely useful tool. The more detailed structured information is there, the better results LLMs can provide. Meanwhile, LLMs can be used to structure existing data, simplifying the way how data is organized.

Notidar

Dear reader, in case you made it to this part and liked the idea, let me present Notidar to you. Notidar is an early-stage prototype solution that implements the mentioned earlier concepts. Right now I'm working on Notidar as a pet project: making mistakes and solving those, adapting new ideas, and shaping solutions in progress. I apologize in advance in case you find it broken, buggy, or working slow. I would appreciate any feedback, suggestions, or advice in the comments. Feel free to create an issue on GitHub or post on Reddit.

TypeScript was developed by Microsoft and shared only after two years of internal development but can be considered a success now. I don't have even a fraction of those resources or time, but I have a gut feeling that this has huge potential long-term.

RSS with types