Some of my friends had mentioned adding RSS to their static site generators was hard; how about turning your index page into the RSS feed, and letting browsers generate the HTML for you?

This feed indeed has some interesting things, related to SCP, sci-fi (especially time traveling), or programming. I bookmarked the Perl introduction, if I ever want to learn Perl and scare my fellow Python developers at work.

Some of my favorite things with Pale Moon include turning it into Netscape, sync support, and built-in RSS preview and subscription support via Live Bookmarks. I however have an issue with the RSS preview: it allows you to subscribe not only via Live Feeds but also with other desktop applications that you might have installed, such as Thunderbird, or Yahoo. My issue is that I wanted to add a button to quickly subscribe on envs.net's TinyTinyRSS instance, and after various attempts I could not add it in the user interface.

Here comes the trusty about:config to the rescue! Looking up yahoo in the configuration values pointed me to two keys in the configuration:

browser.contentHandlers.types.0.title

Initially set to My Yahoo!, I changed it to TinyTinyRSS.

browser.contentHandlers.types.0.uri

Initially set to https://add.my.yahoo.com/rss?url=%s, I changed it to https://rss.envs.net/public.php?op=subscribe&feed_url=%s. I found this URL by looking at the bookmarklets configuration in TinyTinyRSS and reading the short JS code that redirects you to TinyTinyRSS.

I initially tried to add a button next to the My Yahoo! one by creating two new keys, .types.1.title and .types.1.uri, but that failed. I did not yet look into the Pale Moon source code to see why this could have failed.

With this change, instead of Yahoo, I can quickly subscribe to anyone's RSS feeds faster than ever. This will definitely not help my backlog of 2600+ articles…

<xsl:value-of select="description" disable-output-escaping="yes" />

disable-output-escaping is optional according to the W3C specification since version 1. libxslt, Chromium and Internet Explorer do support it, but Firefox chose not to, and a Bugzilla ticket for it will celebrate its 20th birthday this year. They do say themselves that this causes issues for RSS support, so I chose to just not care about it. If you are a Firefox user and are seeing raw, unparsed HTML tags in there, I can only suggest using another browser, or just subscribing to this feed and reading this in its home, a RSS aggregator.

https://www.bbc.com/weather/2644080

Take this integer suffix, which is the ID of the location, and put it in one of these two URLs to get some RSS feeds:

• 3-day forecasts: https://weather-broker-cdn.api.bbci.co.uk/en/forecast/rss/3day/2644080
• Latest observations: https://weather-broker-cdn.api.bbci.co.uk/en/observation/rss/2644080

This procedure is documented exactly like so on the BBC help pages!

Replace rss2 with atom for an Atom feed, and with rdf for an RSS 1.0 feed.

I added a distinction between RSS 1.0 and RSS 2.0 in ITSB and used it to provide more official feeds from the Antigua and Barbuda Department of Marine Services and Merchant Shipping Inspection and Investigation Division and the mongolian Air Accidents Investigation Bureau.

Most people just make blogs on there, called gemlogs. Those gemlogs are frequently practicing a habit that has been disappearing from blogs faster than the blogs themselves disappeared in favor of social media: posts that reply to other people's posts.

I like email as a discussion method because it works like letters, just with some faster delivery and cheaper postage cost; no typing notifications and no expectations of a very fast reply like on instant messaging platforms, so you have less anxiety and more time to write out your thoughts. the UI of most email clients encourage you to write more, to not just send one line; the text length limit probably exists due to technical limitations, but you wouldn't be able to reach it without writing book after book in a single email. twitter is probably the worst place to debate on, since having much less space to explain yourself means your thoughts immediately get misinterpreted.

Replying to other people's posts on your own blog or gemlog is basically like e-mail, but the discussion can be read by a lot more people. you get all the benefits of long-form writing and asynchronous communication, combined with sharing with or receiving knowledge from your readers and other people's readers. However, you can hit an issue where the person who posted the text you replied to might be completely unaware of your reply, and might never read it, unlike email. some standards exist to help with this, such as Webmentions, or the trackback namespace for RSS.

I will let you click the link to read more about trackback; because I am posting today to show you an alternative, if you want to use something that approximatively nothing supports: mod_annotation, a proposed RSS 1.0 module. This, like most RSS 1.0 modules, never reached a status of standard module and disappeared from the Internet, so the only way to find them now is to use the Wayback Machine. I love the Wayback Machine.

To use this module, first add a new XML namespace to your feed: xmlns:annotate="http://purl.org/rss/1.0/modules/annotate/". Then, in the <item> tag, add the following tag to reference something else:

<annotate:reference rdf:resource="https://envs.net/~lucidiot/rsrsss/"/>

This module was only proposed for RSS 1.0, but most feed readers barely make any distinction between RSS 1.0 and 2.0, so if a feed reader ever supported this module, you could probably use it safely in RSS 2.0 too.

Turns out RFC 4685 defines an XML namespace one can use to define replies. It is rather similar to yesterday's mod_annotation.

To use this namespace, you will need to first add the namespace to your feed: xmlns:thr="http://purl.org/syndication/thread/1.0". You then have access to two new elements and two new attributes, and the spec also defines a new rel value:

• <thr:in-reply-to> to indicate what you are replying to using the ID indicated in the <id> tag;
• <link rel="replies"> to point to a page where some, or all, known replies to a post are listed;
• thr:updated to add on the above link the last date when the page was updated;
• thr:count to add on the above link the number of known replies listed in the linked page;
• <thr:total> to indicate the total number of known replies, as the linked replies pages might only contain a portion of them.

None of those are required. You can repeat the <link rel="replies" /> as many times as you might need, if you have multiple pages. The metadata given by the <thr:total> element and the thr:count and thr:updated attributes is non-authoritative, which means it does not have to be exact.

If you are using <thr:in-reply-to>, it is recommended to also include the post's link in a <link rel="related"> to allow a graceful fallback for feed readers that might not support the threading extensions.

The RFC includes a bunch of examples that should be enough to get you started should you ever want to try using this namespace.

Some other formats

Before I start writing posts on threading for just every single syndication format, here is some info for two formats I have experimented with in ITSB:

JSON Feed does not have support for threading in its spec, but you could just make your own extension for that. It does not use JSON-LD either, which would have allowed for a similar extension system as XML; but after experiencing the complexity of JSON-LD first hand at my day job and facing the numerous interoperability issues that causes, I can definitely understand that they wouldn't want to.

Channel Definition Format allows for nested channels, so you could at least create a structured representation of a thread as a tree if you, the original author of the post, knew about all the replies. You cannot, however, specify that you are replying to something yourself. The format does support XML namespace extensions, so you could use thr or mod_annotation.