Tag: feedreader

I read lots of RSS feeds, for which I use a FreshRSS instance that is hosted on a VPS I rent from Hetzner.
To read I can use the FreshRSS’s own web interface, but on my laptop I use a personal interface.
That personal interface allows me to not just read, but respond while reading.
This is the original vision for the World Wide Web, in which you don’t just read, but write too, and where reading and writing are part of singular experience.

What my personal interface does / allows:

  • Show me my folders of feeds (the folders are in FreshRSS, and named / sorted according to my ‘reading by social distance‘)
  • Click open a folder to load unread items in that folder (using the FreshRSS API)
  • Click open an unread item if the title catches my eye.
  • Clicking on a ‘Respond’ button reveals a (larger) response form to fill out
  • Submit the response form, calling a processing script on my local machine in the background, and continue reading
  • Mark a folder or all feeds as read (using the FreshRSS API)

The response form allows me to do several things, both individually or simultaneously

  • Post a bookmark, favourite or reply to my blog, my company’s website and other WordPress sites I control (using IndieWeb micropub)
  • Create a note in my Obsidian vault (by writing to the filesystem directly)
  • Create a page annotation in Hypothes.is (through the Hypothes.is API)
  • Post to one or both my Mastodon accounts (through the respective Mastodon instance API)

I am in the process of slowly adding additional features from my list of ideal feed reader capabilities. Currently I am working on being able to tag feeds (readers usually only allow adding tags to items), so I can not just have folders but also subsets based on tags (e.g. coders in Berlin).

Screenshots (status February 2026):


The general overview of my reader, listing the folders in my FreshRSS instance. Clicking one reveals unread items.


Every unread item has a Respond button beneath it.


The response form allows various texts, and has a selector for bookmark, favourite or reply type of responses.


A response can have one or more destination: blogs, local notes, hypothes.is annotations, or Mastodon accounts.

Posted on
by

For some time I have been able to directly post things to this blog from my feed reader. My feed reading client is connected to a simple feed server, the Yarns WordPress plugin. Now I have connected my feed reading client to the API of the FreshRSS instance I use for feedreading daily.

The Yarns feeds server works, but it requires a WordPress install to run in and is somewhat limited. I could run it in this here WordPress, but then the many feeds I follow would pollute my blogs database. So until now I ran it in a separate WordPress install. All a bit hacky, and more proof of concept than really a smooth fit for my daily routines.

I do however daily use FreshRSS, which I run as a self-hosted instance on a VPS. FreshRSS has an API, or rather it has two API’s, meaning that I could run my feed reading client on top of FreshRSS by talking to its API.

FreshRSS has two APIs, one is the Fever API, the other is the Google Reader API of old. Both aren’t very well documentend w.r.t. their implementation in FreshRSS, because they assume you’d use it for a mobile client using a local database. I don’t want to replicate the database, I want to only directly talk to the API to fetch the things I need. After some experimentation in Postman I could talk to the Fever API, but haven’t worked out how to talk to the Google Reader API of FreshRSS.
The Fever API doesn’t support calling items by feeds and feeds by groups, the way I actually read in my ‘reading by social distance set-up‘. It can give me groups, feeds and items, but not cross-referenced. In terms of content it can basically only give me a bunch of feed items, at most limited by the item number of the oldest unread item. But it works. The previous post was created directly from my feed reading client, while fetching the item itself from FreshRSS.

Now, I need to figure out how to use the other API, so I can do more of the things that I want from my ideal RSS reader.

In reply to Social Readers by James G

Over the years I’ve blogged about what would be an ideal feed reader to me, and also mapped it to how IndieWeb standards might help realise it. In the end it all goes back to how I in 2005 described using feed reading as information filtering, and the inputs, reading and resulting actions it is built out of. That is still my approach, and it is as high friction as it was back then in terms of how well existing readers and tools cater to those needs. Plenty of space for feed reader evolution as you mention!

I would particularly love to hear parts of web readers you like and dislike. If you could build a social reader tomorrow, what features would it have?

James G

Posted on
by

Two years ago I wrote about the features I’d like to see in an ideal feed reader. Today I’ve tried to sketch out the various components, based on the various IndieWeb protocols, and then match the features I listed previously to the component that I think should provide it.

Separating feed reading into IndieWeb components

Feeds from blogs, to the left in the sketch below, end up in a microsub server, whose function is to fetch and store feeds. A microsub client is what presents those fetched feeds to me. A regular feed reader usually does both these things, but splitting them like the IndieWeb does allows multiple clients to use the same collection of feeds and feed items. It allows a wider diversity of readers, if the fetching is dealt with separately.
The microsub client also contains a micropub client. This allows having action buttons underneath each item presented in your microsub client. Hitting a button posts your reply or remarks, or shares something to your own website, and through your site to e.g. Twitter or Mastodon. Ideally it would be possible to have different websites to share to, next to storing locally in a specified format. The website that receives such an action has a micropub endpoint, and may need authentication through IndieAuth.

Such a reader set-up should be able to run locally on my laptop, as well as on a basic hosting package, so likely php / mysql based. Locally because I want to run my stuff local first, but the same thing online, even if a home server, because I’m not always working on my laptop and would like access from my tablet too, and point my Android Indigenous app to my subscriptions. Locally I would not need authentication from the microsub client to the microsub server, but in all other situations I would.

The sketch above is completely congruent with how I sketched my information gathering and filtering process in 2005:

filter1.jpg

Matching the ideal functionality to IndieWeb components

When I match the features of my ideal feed reader to those various IndieWeb components I think this is what results:

Microsub server needs to be able to :
* use various kinds of feeds (rss, atom, json, h-feed)
* allow folders (so I can arrange feeds on social distance)
* recognize and store tags if feed items have them
* allow me to tag _feeds_, really meaning tagging authors
* keep track of posting frequency, last post seen of feeds
* keep track of tags or predefined topics mentions/frequency
* pull in machine translations by default for certain feeds and store them with the orginal item

Microsub client needs to be able to:
* present the feed items in the server’s folder structure as a long list (the classic feed reader view)
* present views based on patterns in current feed items: what’s hot, what’s unique? Also set against social distance. (Topics discussed in my communities today)
* present views based on feed tags (show me all Germany based blog items of this morning, show me every feed of from EU based coders)
* present views based on feed tags and item tags: show me Germany based blog items talking about topic X.
* show full text search results of all items mentioning a certain topic.
* store full text search queries
* present visually which topics seem to be hot in which community, or where the frequency of mentioning a topic has changed
* provide a search of feeds (not feeds content): do I already have this feed in my list, where’s the feed of author Y?
* pull in a machine translation on request

Micropub client needs to be embedded in the microsub client and should support:
* saving an article as markdown or as html, to disk, to Zotero
* creating a todo from it by amending a textfile,
* bookmarking it, either to my blog or some other target
* sharing something about it to my blog, to Mastodon through my blog
* replying to it, through my blog to Mastodon, Twitter, other blogs
* allow configuring new actions.
* choosing from multiple micropub endpoints

What do you think, should some of these features be provided by other components than they’re currently listed? Are features missing that you’d like to see in your ideal feed reader?

Posted on
by

A few weeks ago Kicks Condor released a major update of his Fraidycat feed reader. Like Kick Consor’s blog itself, Fraidycat has a distinct personality.

Key with Fraidycat is that it aims to break the ‘never ending timeline’ type of reading content that the silos so favour to keep you scrolling, and that most feed readers also basically do. Fraidycat presents all the feeds you follow (and it is able to work with a variety of sources, not just regular RSS feeds from blogs) in the same way: the name of the feed, and one line of titles of recent postings.
The pleasant effect of this is that it shows the latest postings of all your subscriptions, not just the latest postings. This means that regular posters, oversharing posters and more silent voices get allocated much the same space, and no single voice can dominate your feed reader.

For each blog you can toggle a list of recent postings.

It’s not just that Fraidycat doesn’t present a timeline, it actually only presents some metadata from each feed and does not fetch the actual content of a feed at all. So as soon as you click a link in a list of links, it will send you to your browser and open it there. This runs counter to my habit of reading feeds offline, which requires being able to automatically download content to my laptop. It does make for a clean experience though.

A neat addition is also that it shows sparkline graphs next to the name of a blog, so there’s a visual cue as to the frequency of posting. This is something I’d like to see in other readers too. It’s a functionality that might be extended with an alert of changes in the normal posting rhythm. E.g. someone falling silent, or suddenly blogging up a storm, or covering a live event could perhaps stand out with a visual cue (such as changing the color of the sparkline graph). The sparkline is the only cue concerning the number of postings, there’s no indication of how many ‘unreads’ there are because Fraidycat doesn’t know that (as it doesn’t fetch content). This is a good way of preventing any type of FOMO cropping up.

In the current times it is I think worthwile to follow blogs more, and social media timelines less, attenuating both the noise and the way stuff reaches you.