Tag: feedreader

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.

Posted on
by

This is a quick exploration of my current and preferred feed reading patterns. As part of my activities, for Day 2, the hack day, of IndieWebCamp Utrecht.

I currently use a stand alone RSS reader, which only consumes RSS feeds. I also experiment with TinyTinyRSS which is a self-hosted feed-grabber and reader. I am attracted to TinyTiny RSS beacue 1) it has a database I can access, 2) it can create RSS from any selection I make, and it publishes a ‘live’ OPML file of feeds I track, which I use as blogroll in the side bar.

What I miss is being able to follow ‘any’ feed, for instance JSON feeds which would allow tracking anything that has an API. Tracking #topics on Twitter, or people’s tweets. Or adding newsletters, so I can keep them out of my mail client, and add them to my reader. And there are things that I think don’t have feeds, but I might be able to create them. E.g. URLs mentioned in Slack channels, or conversation notes I take (currently in Evernote).

Using IndieWeb building blocks: the attraction of IndieWeb here is that it makes a distinction between collecting / grabbing feeds and reading them. A Microsub server grabs and stores feeds. A Microsub client then is the actual reader.
Combined with Micropub, the ability to post to your own site from a different client, allows directly sharing or responding from a reader. In the background Webmention then works its magic of pulling all that together so that the full interaction can be shown on my blog.

The sharing buttons in a (microsub client) reader like Monocle are ‘liking’, ‘repost’ and ‘reply’. This list is too short to my taste. Bookmarking, ‘repost with short remarks’ and ‘turn into a draft for long form’ are obvious additions. But there’s another range of things to add about sharing into channels that aren’t my website or not a website at all, and channels that aren’t fully public.

To get things under my own control, first I want to run my own microsub server, so I have the collected feeds somewhere I can access. And so I can start experimenting with collecting types of feeds that aren’t RSS.