fluffy rambles: RSS: there’s nothing better

RSS: there’s nothing better

June 27, 2019 12:19 PM (4 years ago)

David Yates wrote a great defense of RSS which I completely agree with. To summarize the salient points:

RSS is open
RSS works
RSS is very well-supported by a lot of things
RSS is a suitable name as shorthand for “RSS/Atom” because the name “Atom” is overloaded and basically anything that supports Atom also supports RSS and vice-versa

(Note that there’s one inaccuracy in that since that article was written, Twitter has moved over to algorithmic manipulation of the timeline. This can currently be disabled but who knows how long that’ll last?)

Most IndieWeb folks are also really gung-ho about mf2 and h-feed, and while I don’t see any reason not to support it (and it certainly does have some advantages in terms of it being easier to integrate into a system that isn’t feed-aware or convenient to set up multiple templates), I’ve run into plenty of pitfalls when it comes to actually adding mf2 markup to my own site (for example, having to deal with ambiguities with nesting stuff and dealing with below-the-fold content, not to mention a lot of confusion over things like p-summary vs. e-content), and so far there doesn’t seem to be any real advantage to doing so since everything that supports h-feed also supports RSS/Atom, as far as I’m aware.

For me the only obvious advantage to h-feed is that you can add it to one-size-fits-none templating systems like Tumblr where you don’t have any control over the provided RSS feed, but in those situations there’s not really a lot more added flexibility you’re going to get by adding h-feed markup anyway. I guess it also makes sense if you’re hand-authoring your static site, but that just means it becomes even easier to get things catastrophically wrong.

Granted, it’s also easy to get Atom and RSS wrong too! In working on FeedOnFeeds I’ve had a lot of experience with both trying to correct existing feed bogosity and undo overcorrections that only make the general case even worse. Fortunately, Atom and RSS both have mechanisms for strict validation, so it’s possible to point to exactly what went wrong. Here are some common errors I see:

Not properly encoding their content chunk; easiest way is to put it in a CDATA segment
Not properly escaping &s in URLs (even in <a href="..."> you need to escape them!)
In Atom, providing the wrong content-type for the <content> block (xhtml instead of html, most commonly)

And then of course there’s things that feed authors often get wrong, which has a tendency to make life more miserable for feed readers (meaning both the software and the people using the software):

Not providing an item UUID/GUID
Not providing an item date
Using the wrong <link rel="self">
Using relative links for href and src
Providing content as an image that’s got strict hotlink prevention (which is why FeedOnFeeds has a built-in referral-preserving image proxy now…)
Trying to embed stylesheets into the feed items (which reminds me, I should try adding scoped CSS to FoF…)
Self-bumping an item by making a new one with a new UUID/GUID to get around the follow/subscribe dichotomy

There’s also a bunch of stuff I wish were better about feeds in general (both RSS/Atom and the newcomers to the field like mf2/jf2/etc.). One big one: I wish items themselves could provide some sort of folder structure. Atom kinda-sorta provides this with the <category> tag but it’s not particularly well fleshed-out, and the spec is confusing and vague enough that it becomes pretty much impossible to understand how to use it effectively. As best as I can figure it’s just a mechanism of providing arbitrarily-structured tag-style filtering, and there’s no way of providing, say, an IMAP-style folder structure. But an IMAP-style folder structure would be really neat for UX; imagine being able to subscribe to a feed like mine and being able to client-side focus on a specific comic, or ignore chatter by muting the folder, or whatever. <category> kinda supports that, I guess, but it doesn’t do anything to provide a top-level folder structure aside from what can be sorta intuited from the tag.

Okay so I guess it would be cool if people could simply set up rules to map <category> things to folders in their reader, and that doesn’t require any change to Atom so much as changes to readers and an ecosystem where people are better at providing <category> tags. Add that to the list of things I want to do in Subl.

For now I plan on adding a granular feed customization UI to my own site feeds but that’s not a great solution; even the best UX requires people to unsubscribe/resubscribe to my feed if their preferences change, for example, although it’ll be helpful when I finally get around to adding private entries (and feeds).

On that note, I keep thinking I’d like to just do Subl as a Microsub client, but it doesn’t seem like Microsub provides all the features I’d like to make that possible. There’s also the whole pile-of-endpoints problem that’s endemic to IndieWeb right now which makes it kind of a mess to set anything up. I think it’s great for things to support Microsub, but I feel like that should be a common API that’s used on top of a fully-fledged reader of its own, and not the specific way to access things. (And of course snarfed has written a bridge for that.)

Gah, there are so many things I want to build (or see built), but I have so little time and energy to do it with…