Someone took a nice photo of me recently. I'd like to use it as my avatar photo everywhere to present a consistent image. This is not easy to do.
I've had to manually change it on a dozen different Slacks, a bunch of social networks, a few forums, all my email accounts, and I'm still not done.
I jus...
Gravatar has some not-so secure issues relating to privacy that allow reverse lookups which isn’t good and could potentially leak information people don’t necessarily want to release.
My favorite solution to this problem and a few related others (like updating my bio and where you can find me on social media) is the meta data route using something like Microformats. Since I provide an h-card on my website’s homepage, it should be relatively easy for any service to take my URL as my identity (rather than one of my thousands of email addresses) parse my page and find my name, photo, bio, etc. and display them.
Nearly every social silo on the planet wants all of these details, so why should I need to incessantly have to input them manually much less keep them up to date? And I’ve yet to see a social service in the wild that hasn’t asked for my URL, so it’s obviously pretty universal.
Jeremy Keith‘s Huffduffer is a great example of something that already uses this data nicely. It doesn’t pull in my photo (though I think at one time he did have a set up that would poll Flickr avatars?) or my bio, but the “Elsewhere” section of my Huffduffer account lists where you can find me on dozens of social media accounts as well as my own websites. Huffduffer can do this because I gave it my domain name and the service parses my page looking for the rel="me" tags on my homepage. It could easily pull in my other provided data.
Incidentally Kevin Marks has also proposed a distributed verification system (remember the problem that Twitter had of attempting this?) that uses the rel="me" idea.
I’ll note that my own website will parse yours to pull in the author name, URL, and avatar to display a reply context for this response on my website! So hooray for microformats! (Though I’ll note that I did modify them a tad for my own idiosyncrasies.) My site does this with David Shanske‘s excellent Post Kinds plugin uses Parse This, which parses for microformats, JSON-LD, and then, if nothing is found it falls back to Open Graph Protocol. He’s been extending it lately to cover a handful of the bigger snowflake services like YouTube, IMDb, etc. to cover some additional edge cases that don’t have good mark up. Incidentally Aaron Parecki has a version of something like this called X-ray, which he uses for various things including microsub readers, not to mention the variety of other parsers available.
I’m sure there may be other versions of this in the wild, but it would be cool to see more social services provide functionality like this.
Jacky has built a cool little tool here. It looks like it’s keyed off of rel=”me”, so the word “intended” is carrying some extra weight. I have rel-mes on my site, but I’d prefer people followed my site directly and not my social silos.
After I wrote about the hoops I had to jump through to get Amazon’s API to output JSON (via XSLT), Tom detailed a way of avoiding JSON by using XML-RPC. That’s very kind of him but the truth is that: I like dealing with JSON and the XSL transformation is done by Amazon, not me; that wouldn’t b...
So when I wanted to find a Last.fm user’s profile picture—having figured out through Google’s Social Graph API when someone on Huffduffer has a Last.fm account—it made far more sense for me to use hKit to parse the microformatted public URL than to use the API method. ❧
So the secret to having one’s image appear in their Huffduffer account is to add a rel=”me” to one’s home page? What triggers the reparsing? I’m not seeing it pop up…
— Annotated on December 06, 2019 at 10:37PM
Those big time motivational speakers who talk about starting to learn with a problem you want to solve have never really accounted for serendipitous learning. Is everything as simple as problem
In these times of centralised services like Facebook, Twitter, and Medium, having your own website is downright disruptive. If you care about the longevity of your online presence, independent publishing is the way to go. But how can you get all the benefits of those third-party services while still owning your own data? By using the building blocks of the Indie Web, that’s how!
I decided to work on my website theme for a bit. In order to support it, today I shipped(with a minor bug, sorry), a new Indieweb plugin that adds the ability to add the rel-me links inside the h-card widget instead of by themselves. I’m now using it. In my theme, I added support for a dedicated h-card page. I’ll be turning it on on my site likely in future as I experiment with moving my feed off of my main page.
Some more details about a proposed solution for MoodleNet that could solve some problems around decentralised identity.
Doug, the sound of this is interesting, but it seems to be a lot harder than it might need to be, not to mention the pitfalls of being assigned emojis one wouldn’t want representing them in addition or the centralized nature of the provisioning source.
It also sounds very much like Kevin Marks’ Distributed Verification scheme using the rel=”me” attribute on web pages for which he built a chrome browser extension to actually implement it. Kevin also recently reported that Mastodon now actually supports this verification scheme in one of their most recent updates which should be used by instances that are regularly updating. The benefit is that this scheme already exists, is relatively well supported, there are parsers available for it, and it’s actually working on the open web. It’s also truly distributed in that it doesn’t rely on any central provisioning authorities that require ongoing maintenance or which could provide a monopoly on such a service.
(Mind you, since you can self-host Mastodon, you should really verify links yourself instead of relying on a cosmetic feature as I could have just faked that via a bit of CSS.) ;)
In these times of centralised services like Facebook, Twitter, and Medium, having your own website is downright disruptive. If you care about the longevity of your online presence, independent publishing is the way to go. But how can you get all the benefits of those third-party services while still owning your own data? By using the building blocks of the Indie Web, that’s how!
I spent some time this morning doing a dry run through setting up a suite of IndieWeb plugins on a fresh WordPress installation. Going off of a scant outline I talked for almost two hours describing IndieWeb functionality as I set it all up. Hopefully it will provide a useful guide to newcomers to the space until I can write up a more solid outline and take a more polished approach. Apologies in advance for the roughness of the audio, lack of quality, and even live mistakes. Hopefully folks won’t mind suffering through until we can come up with some better tutorials.
As prerequisites, I assume you’ve already got your own domain and have installed WordPress on a server or other host. I actually finish setting up the WordPress install as I start the video and then sign in for the first time as we begin.
While many of the core plugins are straightforward, there is a huge amount of leeway in how folks can choose (or not) to syndicate to sites like Twitter, Facebook, and others. Here I make the choice to use the Bridgy Publish plugin and only demonstrate it with Twitter. With one example shown, hopefully other silos can be set up with Brid.gy as well. The IndieWeb wiki details other options for those who want other methods.
At the end I walk through creating and syndicating a post to Twitter. Then I demonstrate commenting on that post using another CMS (WithKnown) from a separate domain.
I do my best to provide verbal descriptions and visual examples, but these can certainly be supplemented with further detail on the IndieWeb wiki. I hope to come back and add some diagrams at a later date, but this will have to suffice for now.
For those who would like an audio only version of this talk, you can listen here (.mp3):
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.
Post away
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.
Kinds meta box with “Issue” option chosen.
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.
The “Response Properties” meta box.
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.
Bridgy Publish meta box with GitHub chosen.
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.
Syndication Links Plugin will display the location of your syndicated copies 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.
An example of a comment sent via webmention from GitHub via Brid.gy. It includes a permalink to the comment as well as a link to the GitHub user’s profile and their avatar.
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.
Other options
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.
Help
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.
I ran my domain through IndieWebify.me. Almost all of the rel=“me” links either don’t link back or couldn’t be fetched. The following work perfectly and can be used with the IndieAuth authentication plug-in.
GitHub
Flickr
Goodreads
Twitter
That’s 4 out of 43.
Khürt , The majority of them don’t link back because the silos (like Keybase, Instagram, and Medium which you mention) aren’t putting the rel=”me” microformat on the URLs in your profile like Twitter, Github, and Flicker do. If you view the page source for those silos, you’ll see that they list your URL, but don’t have rel-me’s pointing back at you. Sadly, you can’t control these, though you could file issues with the sites that don’t to encourage them to.
The indiewebify.me site has a parser that is looking at the two sites to see that they not only point at each other, but it requires that the two links have the rel=”me” microformat on them. Most don’t, but this doesn’t mean too much in practice. Whether or not they both have rel=”me”, the only way both sites could point at each other indicates that you “own” or control them both. Kevin marks has proposed/built an interesting decentralized verification service based on them. His version is certainly much better distributed than Twitter’s broken verification set up.
Other than having a stronger two-way ownership indicator, what do you get out of them? As you mention, some have the ability to be used with IndieAuth. Those that can be used with IndieAuth are relying on the service (like Twitter or Github) having a OAuth implementation for signing into their services. This allows an indie site to piggyback on another services’ OAuth implementation without having to go through the trouble to build one themselves, which can be a lot of work to do, much less do correctly (securely). Most of the services you see not linking back not only don’t add the rel=”me” tag, but they also don’t support OAuth, so you wouldn’t get too much more out of having the correct reciprocal link anyway.
Incidentally, one of the benefits the rel=”me” links do have is that they allow you to use your website to log into the IndieWeb wiki to participate directly in that part of the community. (Give it a try!)
Some services like Brid.gy get around services like Instagram or Facebook not having a physical rel=”me” microformat because they’re relying on looking at the appropriate data (usually via API) on your profile page to see if it links back (either in your website field or typically in your bio).
Don’t be overly concerned that the vast majority of sites appear not to link back even if you’ve got links on both pointing back. (And if you think your batting average is bad with only 4 of 43, just imagine how many of my 200+ sites do?!)
If you want to see an interesting tech-forward application of rel=”me” and the XFN friends network, take a peek at Ryan Barrett’s Indie Map which he unveiled over the summer:
Some of these building blocks will likely add a lot more value later on as more and more sites explicitly indicate their relationship to and from each other.
I wrote in the morning again with one or two small snippets later in the evening. I focused mostly on the topic of rel=”me” for profile equivalence and identity-consolidation with about 1,882 words.
I added a couple of new chapter ideas that will need to be fleshed out as well–I’m surprised I’m still coming up with outline pieces.
Rel=”me” is a microformat tag put on hyperlinks that indicates that the paged linked to is another representation of the person who controls the site/page you’re currently looking at. Thus on my home page the Facebook bug has a link to my facebook account which is another representation of me on the web, thus it has a rel=”me” tag on it.
His data is a bit old as I now maintain a page entitled Social Media Accounts and Links with some (but far from all) of my disparate and diverse social media accounts. That page currently has 190 rel=”me”s on it! While there was one other example that had rel-mes pointing to every other internal page on the site (at 221, if I recall), I’m proud to say, without gaming the system in such a quirky way, that each and every one of the rel=”me” URLs is indeed a full legitimate use of the tag.
I’m proud to be at the far end of the Zipf tail for this. And even more proud to be tagged as such during the week in which Microformats celebrates its 12th birthday. But for those doing research or who need edge cases of rel-me use, I’m also happy to serve as a unique test case. (If I’m not mistaken, I think my Google+ page broke one of Ryan’s web crawlers/tools in the past for a similar use-case a year or two ago).
The Moral of the Story
The take away from this seemingly crazy and obviously laughable example is simply just how fragmented one’s online identity can become by using social silos. Even more interesting for some is the number of sites on that page which either no longer have links or which are crossed out indicating that they no longer resolve. This means those sites and thousands more are now gone from the internet and along with them all of the data that they contained not only for me but thousands or even millions of other users.
This is one of the primary reasons that I’m a member of the Indieweb, have my own domain, and try to own all of my own data.
While it seemed embarrassing for a moment (yes, I could hear the laughter even in the live stream folks!), I’m glad Ryan drew attention to my rel-me edge case in part because it highlights some of the best reasons for being in the Indieweb.
(And by the way Ryan, thanks for a great presentation! I hope everyone watches the full video and checks out the new site/tool!)
Terence Eden (shkspr.mobi)
Jeremy Keith
Jeremy Keith
David Shanske
Doug Belshaw
Aral Balkan
Reply
Repost
Like