Eddie Hinkle

Following in the IndieWeb: The Next Frontier

From IndieWeb Summit 2017 to IndieWeb Summit 2018 (both of which happen in June), there was a lot of focus and effort into developing structures around what we call "Social Readers", apps and services that allow you to following different website feeds, responding and interacting on your own website within the same app. It's the dual-nature that Facebook and Twitter provides but this time centered around individual websites. For more information on how social readers work, Aaron Parecki wrote a great article.

(Yesterday, Greg and I were talking about subscriptions and follow posts. I told him I had more thoughts that should be fleshed out in a blog post. This is that blog post.)

So where do we go from here? Now that we can read and interact with people quickly and easier the question is how we manage those people? I think that is one of the next large hurtles for the IndieWeb community to overcome.

There are a couple aspects to this:


The first step following someone is that you end up on someone's website and you want to subscribe to their content. Currently that involves:

That's at minimum 5 discrete steps and it prevents me from subscribing to new feeds all the time. Most of the time I use my iPhone's share sheet to send the url into my task manager with a task "Follow this site". Then, I get lazy and I never sit down and actually follow them until something significant happens and reminds me, then I will eventually do it.

There are two ways we can and should solve this problem, in Native Apps and on the Web.

Native App Subscriptions

One of my open source projects is Indigenous for iOS, which is a native iOS social reader. Native Apps can make this a lot easier by integrating subscribing to feeds in the share sheets.

In this scenario, you would visit the page you want to subscribe to, tap the share sheet, tap your native app and tap Follow. It would then allow you to select a channel and a feed type if there are multiple available. You could also preview the different feeds before selecting if you aren't sure which one you want. There are several taps but they are all pretty easy and intuitive without having to open new browser tabs or apps.

Web Subscriptions

Option 1: Follow Buttons Before the social readers got going, Aaron experimented with a subscription workflow on his website. At the bottom of his feed pages he includes a button that says "Follow".

When you click that button it takes you to a new page that allows you to select one of three feeds to subscribe to (the current page, his home page and all posts) while providing information on how many posts that feed has received in the last 30 days. Then you enter your url and click follow.

Aaron's website will look at your website for a rel="subscribe" link, then it will forward you to that url with a query parameter at the end (?subscribe-to=http://url.com/of/feed). This would then allow the social reader of your choice to bring up a subscribe screen with the url already pre-filled. This allows the web interaction to then mirror the native app interaction very similarly. One downfall is that not every website will end up providing follow buttons. What is an alternative?

Option 2: Browser extensions While I think it would be useful for many websites to implement that type of interaction, some just won't and others can't (for example: static-sites).

Another option is adding Microsub support through browser extensions. For example, Omnibear could add Microsub support for scanning the current website for feeds and allowing a user to subscribe to a feed from their current page. This would allow following functionality similar to a native mobile app but from any desktop browser that has the extension installed. One added benefit compared to the follow button is that you don't have to enter your url into a website, because you will already be logged in to your browser extension.

Subscribing vs. Following

So now you've made it easy to be visiting a website with a feed and to subscribe to that feed within a channel of your social reader. What is missing when compared to social silos today? Well typically you can notify that person that you are following them as well as their information gets added to your website so you can communicate with them more easily, and more. I think the two missing pieces there are the (optional) notification issue and storing their information in your website for easier communication.

Follow posts

Because of the way that social readers enable two way communication, most of them will not only have access to your Microsub server but also your Micropub server. This means that with your permission when you subscribe to a new feed, a Microsub client could also create a follow post through your Micropub server. Your micropub server would of course handle this anyway it saw fit (making them public posts, private posts, sending webmentions, etc).


The other missing piece is the fact that when you follow someone, often times this is also an indication that you want to communicate with them. So far, brainstorming on easing communication has come in the form of a nicknames cache. They haven't taken off too much, and I think one reason for that is there is no easy way to add and maintain a nicknames cache unless you build an interface for it, and who enjoys manually maintaining contacts anyway?

One interesting use case of following is that when you subscribe to someone's feed and begin "following" them, the Microsub client could ALSO parse the author information and then send a Micropub post to your server of an h-card as opposed to an h-entry or h-event. When your Micropub server receives an h-card object it can know that this should be stored in your nicknames cache instead of as a post on your website.

Nicknames caches provide support so that a Micropub client can help to auto-complete personal contacts as well as potentially dealing with @-mentions across services or silos.

When you combine this with the experimental Micropub extension for Querying for post list, you could potentially maintain your nicknames cache through Micropub, retrieving existing entries by using q=source&post-type=card.

Of course, once this is all done it would be super useful to create a Micropub Card <-> CardDAV bridge so that without everyone having to worry about the CardDAV spec, nicknames caches could also become our phone's contact list. Maybe card.brid.gy, Ryan?

62.99 ℉☀️techindieweb
posted using indigenous.abode.pub



@EddieHinkle Very interesting post, thank you!

Please note: This site is in an active redesign. Some things might be a little off 🧐