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?

Boris wrote that iA Writer has support for Micropub now. That sounds interesting, as it would allow me to write locally, and publish to several of my sites, both online and on my local system.

Somehow I can’t get the iA app to talk to my IndieAuth endpoint yet. Not sure what the issue is, but duckduckgo-ing the error message seems to indicate it has to do with some system settings on my laptop?

The resource could not be loaded because the App Transport Security policy requires the use of a secure connection

Read Private posts: the move of the checkins by Sebastiaan AndewegSebastiaan Andeweg
Recently, the call for private posts became louder again. Aaron Parecki is trying to get a group of people together to exchange private posts between Readers. I would like to be one of them...

Private posts is something I’d like to have too. In WP it is possible, by having posts you need a login for. Finding a way to smooth that, which doesn’t require me to have other people having an account here, would be great. Automating IndieAuth access looks like a viable path.

However, private posts is just a first step in my mind. On my wish list is a deeper form of allowing selective publishing: private elements in otherwise public postings. Where one site visitor might read ‘my daughter’, friend might read her name. Where other read ‘a client’, colleagues would read the organisation’s name. Building a smooth spectrum from fully public to fully private. Along the lines of how we in conversations also continuously switch between different degrees of disclosure, and not just between conversations.

A great effect of spending a day in the same room with 20 or so more geeking inclined others, is you get a lot of examples, tools and services mentioned. And geek is as geek does, I try them out on the spot. Today this helped me become aware that something is wrong on my server with the OAuth authentication I run. I thought that it was working fine, as it is no problem to actually use it, for instance to log in with my own domain name at the IndieWeb wiki. But when interacting with my micropublishing endpoint not all goes well.

Today I noticed that:

  • When I try to post from Micropublish.net, I can log in at micropublish.net, but when I try to post I get an ‘unauthorized’ error
  • When I try to use the Omnibear Firefox add-on it authorises ok, but then endlessly tries to load the list of syndication targets
  • When I use Quill to post, it posts fine, but does not load the list of syndication targets

Those missing syndication targets (now that I understand what they are from todays sessions) was what first caught my eye. Testing the micropublish endpoint on my server myself I got the correct response, but Quill turned out to get ‘unauthorized’ as response for that request, just like micropublish.net got for posting.

The endpoint gives a correct response

In WordPress my IndieAuth plugin has a diagnostic tool, and running that, it turns out an authorisation header is not send out.

Which seems to be causing the problems. Reading in the links provided it seems like with XML-RPC, my hoster is actively blocking that header. [UPDATE: It is not, it’s just not available in the way the server currently runs PHP] Resulting in exactly the same experience as I had with XML-RPC, that it seems to be only half working (namely the ‘safe’ uses work, while the rest fails). There’s a work around, renaming the headers that get send out, and implementing that work-around is a thing for me to do tomorrow. To see if I can get around being unauthorised. [UPDATE: That workaround did not work until now]

I plan to dedicate some learning time in the coming 12 weeks to better understand the protocols that drive the independent web, or IndieWeb. During our STM18 birthday unconference Frank Meeuwsen presented his experiences on the IndieWeb. Frank, Peter and I have formed an impromptu triade to explore the IndieWeb in the past months. In one of his slides Frank conveniently listed the relevant protocols. I’ll plan for 24 hours to explore 6 protocols. Some of them I already understand better than others, so I’ll start with the ones I feel less knowledgeable about.

The ones I want to explore in more detail, in planned order, are:

  • ActivityPub / OStatus, a decentralized networking protocol (as this ties into my Mastodon experiments as well, this comes first)
  • Micropub, publish on your own domain with 3rd party tools
  • Microsub, own your feed-subscriptions (although I already run my own TinyTinyRss instance)
  • Microformats, markup for data, text, people, events (already used on my blog, but curious to see how I can extend that to more types of data)
  • Indieauth, federated login protocol to sign in with your own domain on other services (already active on my blog, but interested in where else I could use it)
  • Webmentions, respond to a blogpost through your own site (already active on my site, but strongly wish to better format and style it on my site)

In the discussions during Smart Stuff That Matters last Friday, I mentioned a longtime demand I have of social media. The ability to on my blog have different levels of access, of presenting content. But not in the shape of having accounts on my site and corresponding overhead, but more fluid like layers of an onion, corresponding to the social distance between me and a specific reader. Where I write an article, that looks different to a random reader, compared to what e.g. Peter or Frank sees. Maybe even mark-up the content in a way that controls how specific parts of a posting are visible or not. We mused if IndieAuth might be useful here as a first step, as it at least spares me from the maintenance of accounts.