RSS is still my prefered feed format

I started to build a habit of opening an RSS reader back in January as part of my bucket list, and it has been a nice experience so far.

Having all of my favourite blogs and news websites on one app inside my phone is very convenient, since I don't have to open 50 tabs worth of bookmarks and check if anyone has posted anything new on their sites. And best of it all, it runs locally, because RSS is just a file format!

Well, XML is the file format, not RSS. But it builds on top of it.

However, being based on XML comes with a couple of limitations, mainly the fact that it's XML.

It's unnecessarily hard to parse, and nowadays the amount of developers willing to deal with the file format is shrinking (despite a huge chunk of us still doing HTML, which is semantically close to XML.) Which naturally brings me to what I really don't like about XML, and is that no one seems to agree on what a feed item should look like.

To be fair, the RSS standard doesn't either. It's very generic by design, but provides recommendations for developers to implement depending on what their feed is serving.

But it's a problem, because RSS is primarily used by news websites and blogs.

There is also ATOM (also known as RFC-4287), which is similar to RSS, but with a few deviations. The format is more usable for news and blogs because it's more catered to them, rather than being a catch-all format like RSS.

But let's step back from the technicalities for a bit and talk about the main driver to using RSS and an RSS reader, which is it's ecosystem.

It's a format that has been in circulation since at least 1999! So naturally, there is going to be a good chunk of the web using it to syndicate content.

A lot of "reader" apps have also been developed to gather these files to organize and display them in various ways, such as the beloved Google Reader, NetNewsWire, Inoreader, and my personal favourite, Twine.

My routine goes as follows:

Whenever I scroll through Bluesky and see someone an article from a blog, the first thing I do is add it to my reader so that, later, I can read it more calmly. Maybe while drinking a homemade frappuccino.

But of course, there are a bunch of things that constantly annoy me. But the most egregious one is that some readers don't handle the description field properly!

Despite the spec saying that the description field is the synopsis of the current item, most readers actually display the synopsis as if it were the article's content. A lot of feeds actually put the content of the article inside this field, and while convenient, it would be a lot better if the reader just scraped the website.

When I was building a standard.site feed builder, I was thinking: "Parsing HTML is hard, so why not point to Markdown, or any easily-parsed content format instead?" And apparently, I wasn't the only one that thought of this.

There is a add-on namespace to RSS called "source", that allows the author to put Markdown inside of it, using the <source:markdown> item-level element.

But what if we didn't have to build on top of RSS? What if… and hear me out, what if we used atproto for this!

And turns out, we can! In fact, many are doing this already.¹

My main issue is that, there isn't a good-looking native application² that ingests these, though. The most featured one is a progressive web app, but it provides an API, so maybe it's possible to build an application on top of it?

"But Amelia", I hear you say, "a web app is just like a native app!"

Well, not quite. I would prefer if the app looks like it belongs on my system rather than using its own design. But that's a topic for another time.

Maybe if Twine starts supporting Standard Site records, or better yet, I make a fork of the app to add this functionality, I'll start using it as a replacement (or at least, as an extension to RSS.)