That said, I think we have reached the point in growth with various projects including a commercial product in Micro.blog that it is time to develop 1 (or 2, for plurality sake) turn-key IndieWeb CMS solutions. I think by building and producing such projects now, it is unlikely that it will overtake the current plurality of options. This is also true because even the most simple one click install will never be as easy as Micro.blog, which means we will always have many options for the IndieWeb.
It's coming along nicely. So far, I've imported all existing webmentions from webmention.io and stored them locally alongside my post storage. So if my post is stored in
/2018/11/15/5/post.md then my webmentions would be stored in
/2018/11/15/5/mentions/ each webmention is stored as a
.json file with the source url being the filename. This allows for one webmention per file and if I want to load all the webmentions for a specific post, I just open up all the files in the mentions directory. So far, I'm really liking this and how well it's working.
If it's a homepage mention, it will save the webmention in
/mentions/homepage/ and if it's not a known post, right now it will collect the webmention in
/mentions/unknown. Again, all of these webmentions are stored as individual files. If I recieve an updated webmention, it overwrites the file, so I get the updated information.
Besides just downloading all existing webmentions, I have also added support so that when webmention.io receives a new webmention, it pings my server and my server will go ahead and download that webmention and save it locally. This means that I am now only relying on webmention.io to deliver my webmentions, not for any long-term storage.
Finally, I've added support for displaying webmentions on post pages. I used to have this when my website was powered by Jekyll, but when I moved to a dynamic website, I didn't bother adding that functionality back until I could do it the way I wanted it. Now that I have my local storage I was able to go back to displaying them. Below is a screenshot of the webmention displays on one of my posts:
I'm still trying to tweak exactly how I want things, but I am pretty happy with things for a first pass. I am avoiding "metrics numbers" so instead of display any totals, I am trying to just display the content. Instead of showing 5 "likes" I would just display 5 👍 and of course each reacji will display on it's own as well.
I am not currently displaying mentions for posts when they display on feed pages. I am thinking I might just display a row of emoji representing that last 10 responses. If they are reacji, it would display the reacji, for the rest I would translate the response types to the following emojis: likes 👍, replies 💬, repost ♻️, bookmark 🔖 , listen 🎧, mentions 💭. It would show a recent snapshot of activity on a post without giving in to numbers.
I also am not doing any moderation of posts currently, every webmention automatically gets added and displayed. I can delete a webmention, of course, but there are protections against spam appearing until I delete it. I outlined how I want to deal with moderation, the 2nd level connections are going to be a bit tricky so my goal is to first just start with immediate connections as always accepted, others unlisted until I moderate. Then I'll need to create a mute/block list and have incoming webmentions check that list and respond appropriately.
Finally, if someone sends a webmention delete (a HTTP 410 Gone response from a webmention source url) right now I don't think my website will do anything, in fact, I don't even know if webmention.io supports them. I would like to be able to accept and process webmention deletes. My plan is not to actually erase a webmention that is "deleted" but instead, to set the visibility to private. I can of course, manually delete any private webmentions that I don't want any more.
Today, I've rolled out all of these changes on my website. I also altered the way my audience parameter works. Previously it embedded h-cards within each post with an audience. Now, all audience and person-tag h-cards are stored in my nickname cache first, and then I just put the h-card's uid within the audience array. This change was suggested by Sven in the IndieWeb chat and it was a smart move so I decided to go with that approach.
All in all, I'm very happy with how this turned out. I already added an h-card for a previous post's audience over Micropub and then added that url to the post so that it displays. It worked great! I also added support for retrieving a list of h-cards from the nickname cache by sending a
GET request to my Micropub endpoint with
This will allow me to build into my Micropub client a request to fetch my nicknames cache and display it to the user. The user will then allow me to select which cards I'd like to attach to a post's audience. The uids of those cards would then be added to the audience of the Micropub post. Feels like a pretty seamless experience to add audiences to my posts which is important because in the future I'll be utilizing audiences more as I begin to add support to my site for private posts.
I took a look at my IndieWeb goals and made a list of the things I want to have live on my website by January 1, 2019.
I used to display webmentions my posts received on the previous Jekyll incarnation of my website, but now that I've shifted my website to being dynamically rendered, I haven't rebuilt the webmention display code. I'd like to finish that.
I want to import all existing webmentions I've received to date and store them as JSON files in my post storage folders alongside my posts.
I also want to make sure that whenever my site receives a webmention that I immediately add that new webmention to the JSON files in my post storage folders.
Finally, I want to display webmentions on post pages. I'm not sure if I'll include them on feed pages or not.
✅ Completed November 20, 2018
h-card based nickname cache: Currently my nickname cache is some random storage code and has to be edited by hand. I want my nickname cache to be saved h-card files and to be able to save new people to nickname cache by sending an h-card via Micropub.
Subscribe page: Add a Subscribe page like Aaron Parecki so that people can more easily choose what feeds they want to follow from my website.
If I am able to actually complete all the above goals, I'm going to shift my focus to owning my reading and figuring out if i can leave Goodreads behind.
In fact, there has been conversation lately about how nickname caches are really just h-cards. If you take that and the conversations around collections, you can make private collections of h-cards to essentially create lists. This would be an h-card with children h-cards. You could even use this to say represent your co-workers if you had an h-card collection with the info of your employer and then it had children h-cards of the employees of the company, you could then easily share certain items with your co-workers.
This means I can post a code snippet, select some specific lines and then share the resulting url with fragment to someone and the code snippet will automatically highlight the specific lines to them. Also, the possibility exists that someone could include a code line fragment in the url when sending a webmention to my code snippet and like media fragment, I would then be able to consume the code line fragment and associate the webmention with the specific code snippet lines.
One more step towards owning my own data AND replacing GitHub functionality through distributed means.
They came to the conclusion that there are four groups of people that you want to treat their responses differently:
These are essentially your friends on Facebook or your follow list on Twitter. These are people that you have chosen to connect with in some way and this logical conclusions can be drawn around the level of interactions you're willing to have.
My plan is to display these responses completely (name, photo and content of response). This list will be generated for me by adding anyone I follow, as well as anyone I have sent a reply to. This will NOT add people to whom I have liked, emoji reacted, quoted, or bookmarked. Those are lower level responses that do not indicate a deeper level of a desire to connect with that person.
These are "friends of friends". You can assume they won't do anything TOO bad, but you might not want them posting all over your site. There is a deeper level of trust here because of mutual connection but still some care should be taken. This can be determined through different ways. One way that has been brainstormed in the IndieWeb is Vouch.
I don't currently track 2nd level connections but I liked how Tantek thought this through, so my plan is for replies to display their photo and name as "other people that have responded to this post", but not display the content of their reply. I also think if they send a like, emoji reaction or quote, I'll display it just like I would an Immediate Connection.
This is the World Wide Web, and anyone could send anything to my website via webmention. So this is a category you likely want to moderate.
My initial thought is I will accept likes, quotes and emoji reactions from them but I won't list attribution of who did it while moderated, just the reaction itself. For replies I am considering potentially listing the url of the author of the post under "other people who have replied" but no name, photo or content while moderated.
These are people who you do not trust for whatever reasons have happened for you. You don't want to associate with them in any way.
Responses are not displayed from these people and they are not listed in the moderation queue.
This means I'll need a moderation queue. Anything from a 2nd level connection or from the Everyone group will enter the moderation queue. Responses from 2nd level connections should appear higher in the queue than responses from the Everyone group. From there I can choose to:
All in all, it was a great session that I really enjoyed and I'm looking forward to actually working on implementing some of these features into my site.
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.
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.
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.
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.
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?