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:
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?
@ton other than being formatted in micro formats, it’s not clear to me what microsub gets us over RSS.I do think micropub integration is key: curation & comments posted to your own space right from your reading practice. I suggested this pattern for comments here https://blog.bmannconsulting.com/2021/01/30/feedback-to-ben.html
Feedback to Ben
@bmann for me key thing in microsub is it separates feedfetching the feedreading, so that I can point different microsub clients to the same collection of fetched postings on the microsub server (e.g. for each device its own preferred client / viewer). Or point the same client to a diff server. 2nd interest is that the microsub server, afaik, processes differently formatted feeds where there’s no RSS, e.g. h-feed, or a chunk of json api output, and pass it on to the client as if no difference
I’ve lost track, Ton. What are you using now as your feed reader?
I am using FreshRSS currently. I’ve dabbled a bit with Aperture/Monocle, with Yarns on WordPress and with using a TinyTinyRSS instance. My TinyTInyRSS instance kept bumping into some ‘bad bot’ filters my hoster has in place (the same is true for FreshRSS btw). The upside to me for both Tiny and Fresh is that I find their php and mysql tech accessible, and have no trouble running it locally. Or at least more accessible than any of the IndieWeb stuff. I’d like to get to a working locally run Aperture/Monocle combo but can’t and haven’t figured out why. With Yarns, which has as a pre above Aperture it lives in the WP ecosystem I am at least more familiar with, I have issue with it storing all feeds in the WP content tables, even though everything in a feed reader is/should be ephemeral imo, just providing enough time to do something with whatever gets fetched (respond, bookmark, download to notes etc). Ideally I’d run yarns in a separate WP install to prevent it polluting my blogs database, but then you’re back to how to ensure my ‘reader’ WordPress instance can post to my ‘blogging’ WP instance.