Rssdirectory.org publishes Downread's library of feeds and offers it as a category-based directory. The site works with any feed reader and supports one-click following in several popular readers. You can even customize the Follow button with your own URLs to add unsupported readers. Besides the directory itself, it has a section for publishers where feeds can be claimed and edited.

In the next few weeks, I plan to add a number of tools for publishers to the site, and will, if there is interest, publish the raw catalog on GitHub.

I have set up a second RFC: Feed HTML defines an HTML set for RSS readers and similar applications.

This addresses a long-standing issue with RSS: it allows HTML, but no one defines which HTML features you can use. Many simple RSS readers support some semantic features like <strong>, <h1>, or <table>, plus <img> and social media embeddings, and little else. Some add support for a limited set of CSS styles, like Inoreader does, but only for very basic styles.

Publishers, on the other hand, put everything into their RSS feed. I have seen forms, complex layouts, external CSS styles, JavaScript. There is no limit.

Realistically, not everything can be supported by an RSS reader. It still needs to control the rendering to some degree, and it can't allow interactive elements like forms and JavaScript. But I believe far more can be supported than most readers do today.

So this proposal is basically what I consider the maximum you can do in a web-based reader with its own GUI. More may be possible in apps or when using complex (but slow) iframe constructs, but we need to go with the least common denominator.

Not really coincidentally, this is also what my reader Downread supports. But what I am trying here is

• establish a baseline for publishers so they can see what's possible.
• encourage the creators of other RSS readers to allow more HTML and styles
• get feedback. Quite likely I have overlooked issues, or forgotten HTML features that would be useful and should be added.

All feedback is welcome.

Just a few days ago I stumbled upon the <podcast:location> element in the Podcasting 2.0 spec, and wondered whether anybody uses this.

Today, I found radar.rss.io on Hacker News, which is the first time I've seen the location element actually being used. The Podcast Radar allows you to find podcasts near you, or any location you select on a globe. I was surprised how many were produced near where I live. Hopefully, a feature like that will soon be added to one of the podcast directories.