Let’s say I syndicate a thought to Twitter. I can use Bri.gy to backfeed ideas and interactions with my Tweet back to my original in my digital notebook (where it’s most useful). This helps outside ideas filter into and interact with my own ideas.
Forcing webmentions for conversations on websites that don’t support Webmention
Within the IndieWeb community there is a process called backfeed which is the process of syndicating interactions on your syndicated (POSSE) copies back (AKA reverse syndicating) to your original posts. As it’s commonly practiced, often with the ever helpful Brid.gy service, it is almost exclusively done with social media silos like Twitter, Instagram, Flickr, Github, and Mastodon. This is what allows replies to my content that I’ve syndicated to Twitter, for example, to come back and live here on my website.
Why not practice this with other personal websites? This may become increasingly important in an ever growing and revitalizing blogosphere as people increasingly eschew corporate social sites and their dark patterns of tracking, manipulative algorithmic feeds, and surveillance capitalism. It’s also useful for sites whose owners may not have the inclination, time, effort, energy or expertise to support the requisite technology.
I’ve done the following general reply pattern using what one might call manual backfeed quite a few times now (and I’m sure a few others likely have too), but I don’t think I’ve seen it documented anywhere as a common IndieWeb practice. As a point of fact, my method outlined below is really only half-manual because I’m cleverly leveraging incoming webmentions to reduce some of the work.
Manually syndicating my replies
Sometimes when using my own website to reply to another that doesn’t support the W3C’s Webmention spec, I’ll manually syndicate (a fancy way of saying cut-and-paste) my response to the website I’m responding to. In these cases I’ll either put the URL of my response into the body of my reply, or in sites like WordPress that ask for my website URL, I’ll use that field instead. Either way, my response appears on their site with my reply URL in it (sometimes I may have to wait for my comment to be moderated if the receiving site does that).
Here’s the important part: Because my URL appears on the receiving site (sometimes wrapped as a link on either my name or the date/time stamp depending on the site’s user interface choices), I can now use it to force future replies on that site back to my original via webmention! My site will look for a URL pointing back to it to verify an incoming webmention on my site.
Replies from a site that doesn’t support sending Webmentions
Once my comment appears on the receiving site, and anyone responds to it, I can take the URL (with fragment) for those responses, and manually input them into my original post’s URL reply box. This will allow me to manually force a webmention to my post that will show up at minimum as a vanilla mention on my website.
(Note, if your site doesn’t have a native box like this for forcing manual webmentions, you might try external tools like Aaron Parecki’s Telegraph or Kevin Mark’s Mention.Tech, which are almost as easy. For those who are more technical, cURL is an option as well.)
Depending on the microformats mark up of the external site, the mention may or may not have an appropriate portion for the response and/or an avatar/name. I can then massage those on my own site (one of the many benefits of ownership!) so that the appropriate data shows, and I can change the response type from a “mention” to a “reply” (or other sub-types as appropriate). Et voilà, with minimal effort, I’ve got a native looking reply back on my site from a site that does not support Webmention! This is one of the beautiful things of even the smallest building-blocks within the independent web or as a refrain some may wish to sing–“small pieces, loosely joined”!
This method works incredibly well with WordPress websites in particular. In almost all cases the comments on them will have permalink URLs (with fragments) to target the individual pieces, often they’ve got reasonable microformats for specifying the correct h-card details, and, best of all, they have functionality that will send me an email notification when others reply to my portion of the conversation, so I’m actually reminded to force the webmentions manually.
An Illustrative Example
As an example, I posted on my website that I’d read an article on Matt Maldre’s site along with a short comment. Since Matt (currently) doesn’t support either incoming or outgoing webmentions, I manually cut-and-pasted my reply to the comment section on his post. I did the same thing again later with an additional comment on my site to his (after all, why start a new separate conversation thread when I can send webmentions from my comments section and keep the context?).
Matt later approved my comments and posted his replies on his own website. Because his site is built on WordPresss, I got email notifications about his replies, and I was able to use the following URLs with the appropriate fragments of his comments in my manual webmention box:
After a quick “massage” to change them from “mentions” into “replies” and add his gravatar, they now live on my site where I expect them and in just the way I’d expect them to look if he had Webmention support on his website.
I’ll mention that, all of this could be done in a very manual cut-and-paste manner–even for two sites, neither of which have webmention support. But having support for incoming webmentions on one’s site cuts back significantly on that manual pain.
For those who’d like to give it a spin, I’ll also mention that I’ve similarly used the incredibly old refbacks concept in the past as a means of notification from other websites (this can take a while) and then forced manual webmentions to get better data out of them than the refback method allows.
Spent a few minute to finally set up my website with Brid.gy so that it’s now pulling responses back from Mastodon. It’s so nice to see all the interactions that were once “lost” to me coming back to live with their proper contexts on my website.
For those looking to tinker with their websites as it relates to interacting with Mastodon, the IndieWeb has a reasonable number of potential options in addition to your ability to roll your own.
This week, using the magic of open web standards, I was able to write an issue post on my own website, automatically syndicate a copy of it to GitHub, and later automatically receive a reply to the copy on GitHub back to my original post as a comment there. This gives my personal website a means of doing two way communication with GitHub.
This functionality is another in a long line of content types my website is able to support so that I’m able to own my own content, yet still be able to interact with people on other websites and social media services. Given the number of social sites I’ve seen disappear over the years (often taking my content with them), this functionality gives me a tremendously larger amount of control and ownership over my web presence and identity while still allowing me to easily communicate with others.
In this post I wanted to briefly sketch what I’ve done to enable this functionality, so others who are so inclined can follow along to do the same thing.
Setting up WordPress to syndicate to GitHub
I’ll presume as a first step that one has both a GitHub account and a self-hosted WordPress website, though the details will also broadly apply to just about any content management system out there that supports the web standards mentioned.
Register your GitHub account and your website with Bridgy
Ryan Barrett runs a fantastic free open sourced service called Bridgy. To use it you’ll need the microformat rel=“me” links on both your GitHub account and your website’s homepage that point at each other. GitHub will do most of the work on its side for you simply by adding the URL of your website to the URL field for your GitHub account at https://github.com/settings/profile. Next on your website’s homepage, you’ll want to add a corresponding rel=“me” link from your website to your GitHub account.
In my case, I have a simple widget on my homepage with roughly the following link: <a href="https://github.com/username">GitHub</a>
in which I’ve replaced ‘username’ with my own GitHub username. There are a variety of other ways to add a rel=“me” link to your webpage, some of which are documented on the IndieWeb wiki.
Now you can go to Brid.gy and under “Connect your accounts” click on the GitHub button. This will prompt you to sign into GitHub via oAuth if you’re not already logged into the site. If you are already signed in, Brid.gy will check that the rel=“me” links on both your site and your GitHub account reciprocally point at each other and allow you to begin using the service to pull replies to your posts on GitHub back to your website.
To allow Brid.gy to publish to GitHub on your behalf (via webmention, which we’ll set up shortly), click on the “Publish” button.
Install the Webmention Plugin
The underlying technology that allows the Bridgy service to both publish on one’s behalf as well as for the replies from GitHub to come back to one’s site is an open web standard known as Webmention. WordPress can quickly and easily support this standard with the simple Webmention plugin that can be downloaded and activated on one’s site without any additional configuration.
For replies coming back from GitHub to one’s site it’s also recommended that one also install and activate the Semantic Linkbacks Plugin which also doesn’t require any configuration. This plugin provides better integration and UI features in the comments section of one’s website.
Install Post Kinds Plugin
The Post Kinds Plugin is somewhat similar to WordPress’s Post Formats core functionality, it just goes the extra mile to support a broader array of post types with the appropriate meta data and semantic markup for interacting with Bridgy, other web parsers, and readers.
Download the plugin, activate it, and in the plugin’s settings page enable the “Issue” kind. For more details on using it, I’ve written about this plugin in relative detail in the past.
Install Bridgy Publish Plugin
One can just as easily install the Bridgy Publish Plugin for WordPress and activate it. This will add a meta box to one’s publishing dashboard that, after a quick configuration of which social media silos one wishes to support, will allow one to click a quick checkbox to automatically syndicate their posts.
Install the Syndication Links Plugin
The Syndication Links plugin is also a quick install and activate process. You can modify the settings to allow a variety of ways to display your syndication links (or not) on your website if you wish.
This plugin will provide the Bridgy Publish Plugin a place to indicate the permalink of where your syndicated content lives on GitHub. The Bridgy service will use this permalink to match up the original content on your website and the copy on GitHub so that when there are replies, it will know which post to send those replies to as comments which will then live on your own website.
You should now be ready to write your first issue on your website, cross post it to GitHub (a process known in IndieWeb parlance as POSSE), and receive any replies to your GitHub issue as comments back to your own website.
Create a new post.
In the “Kinds” meta box, choose the “Issue” option.
Type in a title for the issue in the “Title” field.
In the “Response Properties” meta box, put the permalink URL of the Github repopository for which you’re creating an issue. The plugin should automatically process the URL and import the repository name and details.
In the primary editor, type up any details for the issue as you would on GitHub in their comment box. You can include a relatively wide variety of custom symbols and raw html including
and with code samples which will cross-post and render properly.
In the GitHub meta box, select the GitHub option. You can optionally select other boxes if you’re also syndicating your content to other services as well. See the documentation for Bridgy and the plugin for how to do this.
Optionally set any additional metadata for your post (tags, categories, etc.) as necessary.
Publish your post.
On publication, your issue should be automatically filed to the issue queue of the appropriate GitHub repo and include a link back to your original (if selected). Your post should receive the syndicated permalink of the issue on GitHub and be displayed (depending on your settings) at the bottom of your post.
When Bridgy detects future interactions with the copy of your post on GitHub, it will copy them and send them to your original post as a webmention so that they can be displayed as comments there.
If you frequently create issues on GitHub like this you might want a slightly faster way of posting. Toward that end, I’ve previously sketched out how to create browser bookmarklets that will allow you one click post creation from a particular GitHub repo to speed things along. Be sure to change the base URL of your website and include the correct bookmarklet type of “issue” in the code.
The Post Kinds plugin will also conveniently provide you with an archive of all your past Issue posts at the URL http://example.com/kind/issue/, where you can replace example.com with your own website. Adding feed/ to the end of that URL provides an RSS feed link as well. Post Kinds will also let you choose the “Reply” option instead of “Issue” to create and own your own replies to GitHub issues while still syndicating them in a similar manner and receive replies back.
Given the general set up of the variety of IndieWeb-based tools, there are a multitude of other ways one can also accomplish this workflow (both on WordPress as well as with an infinity of other CMSes). The outline I’ve provided here is one of the quickest methods for beginners that will allow a relatively high level of automation and almost no manual work.
One doesn’t necessarily need to use the Post Kinds Plugin, but could manually insert all the requisite HTML into their post editor to accomplish the post side of things via webmention. (One also has the option to manually syndicate the content to GitHub by cutting and pasting it as well.) If doing things manually this way is desired, then one will need to also manually provide a link to the syndicated post on GitHub into their original so that Bridgy can match up the copy and the original to send the replies via webmention.
If you’ve followed many of these broad steps, you’ve given already given yourself an incredibly strong IndieWeb-based WordPress installation. With a minimal amount of small modifications you can also use it to dovetail your website with other social services like Twitter, Facebook, Flickr, Instagram, Google+ and many others. Why not take a quick look around on the IndieWeb wiki to see what other magic you can perform with your website!
I’ve documented many of my experiments, including this one, in a collection of posts for reference.
If you have questions or problems, feel free to comment below or via webmention using your own website. You can also find a broad array of help with these plugins, services, and many other pieces of IndieWeb technology in their online chat rooms.
Interestingly, Known had a lot of these features hidden in code under the hood. Sadly they weren’t all built out. It in fact, did have much of a reader (something which Ben indicated they were going to take out of the v1.0 release to slim down the code since it wasn’t being used). It also had a follow/following block of code (and even a bookmarklet at /account/settings/following) so you could follow specific sites and easily add them to your reader. Also unbeknownst to most was a built-in notifications UI which could have been found at /account/notifications.
It’s a shame that they put many of these half-built features on hold in their pivot to focus on the education market and creating a viable cash flow based company as this is the half that most CMSs lack. (If you think about what makes Twitter and Facebook both popular and really simple, I think it is that they’re 95% excellent feed readers with 5% built-in posting interfaces.)
I’ve managed to replace some of that missing functionality with Woodwind, a reader at http://woodwind.xyz, which one could connect with Known to do the reading and then integrate the posting, commenting, and replies to complete the loop. I do have a few very serious developer friends who are endeavoring to make this specific feed reader portion of the equation much easier to implement (and even self-host) to make the hurdle of this problem far lower, but I suspect it’ll be another 3-6 months before a usable product comes out of the process. For those looking to get more social into their feed readers, I often recommend Ryan Barrett’s appspot tools including https://twitter-atom.appspot.com/ which has instructions for extracting content from Twitter via Atom/RSS. It includes links at the bottom of the page for doing similar things with Facebook, Instagram and Google+ as well.
Interestingly there are now enough moving pieces (plugins) in the WordPress community to recreate all of the functionality Known has, one just needs to install them all separately and there are even a few different options for various portions depending on one’s needs. This includes adding reply contexts for social media as well as both the ability to syndicate posts to multiple social sites for interaction as well as getting the comments, etc. backfeed from those social sites back into the comments section of your post the way Known did. Sadly, the feed reader problem still exists, but it may soon be greatly improved.