Replied to Hovercards by Joseph DicksonJoseph Dickson (
A Hovercard also known as a h-card is a bit of content that’s shared about you on your website kinda like a visual/interactive business card. Implementation looks like Gravitar. It can contain far more information and is self-hosted.
Joseph, I thought I caught you say it during the demos, but wasn’t 100% sure. Reading this, confirms it. You’re conflating two different but very similar ideas.

h-card is a microformat class around the mark up of data about identity elements like names, addresses, cities, countries, and often including an avatar or photo. Hovercard is a UI element that creates a visual card when one hovers over a name or similar element that would contain h-card details. 

Gravatar serves some of these functions for WordPress from a centralized perspective. The data you would imput there would be wrapped with the h-card class, while Jetpack would give you the ability to display Gravatars as hovercards, so that when you hover over an avatar it will display more detail about the person in a small card-like UI.

For your experimentation purposes, you should be able to use just one post to test against my site. Once you’ve modified your theme, you can simply resend the webmention to my site and that will automatically update your original post. You don’t need to create new posts each time to test it out.

If you haven’t gotten it cleared up, do join us in the IndieWeb channel, or catch us at an upcoming HWC event.


An h-card for my TiddlyWiki

I’m still spending lots of time trying to figure out how TiddlyWiki works, so some of this may seem hack-y, but it seems to get the job done. I’d love it if others who are using their TiddlyWikis as their primary website (and who have more experience than I) weighed in with their expertise or experience.

One of the core IndieWeb building blocks is having an h-card on your website to establish one’s identity, either for others to read or for computers and parsers to know who you are.

A valiant first attempt

To start out, I created an About Tiddler with the appropriate h-card and other microformats mark up and then put it into a tab in my right sidebar to make it easy to find.

Naturally, I ran into a problem when trying to throw this into Since TiddlyWiki websites are generated primarily by JavaScript and thus suffer from the js;dr problem, figuring out where to put and display an h-card was going to be an issue. I even tried throwing it into the Site Title in the control panel and hoped for the best, but in the end, the site title is really the shadow Tiddler $:/SiteTitle and like all the rest of the page is generated by JavaScript.

I muddled around a bit and even tried to add an h-card using a <link> in the <head>, but nothing seemed to work.

A hackable solution?

Ultimately, in frustration, I simply threw a simple h-card into the <head> just to see what would happen. It wasn’t terrible—the parser found it and displayed it as a success. Unfortunately I discovered that TiddlyWiki displayed my photo and name at the bottom of my page in the browser. I didn’t expect this, but at least it was a start.

Since this method seemed to work, I thought I’d continue the cheat and just throw in some in-line CSS so that the muddled h-card wouldn’t actually show on my page. I’d use this coded h-card in my <head> for computers and keep the somewhat more elaborate one for people in my about page.

What I did

So, for those who’d like the entirety of the solution, here’s what I did:

  1. I created a plugin tiddler entitled $:/plugins/indieweb/core/rawMarkup and gave it the tag $:/tags/RawMarkup
  2. I added the following lines of code to it and saved the Tiddler
    1. <a style="display:none" class="h-card u-url" href="">
      <img src="" alt="" style="display:none" />Chris Aldrich</a>
  3. Profit!

Again, this works, but seems very hack-y to me. If you’ve managed to get a h-card into your TiddlyWiki in a different or more elegant way, I’d love to hear your thoughts.

Thoughts on delegated h-cards

Given the difficulty and trouble of all this, I’m sort of left wondering why–particularly since I’m using this site as a secondary one to my primary site–I couldn’t just throw in a link to the h-card for my primary site and call it a day? Unless I’m missing something, for some reason the way that representative h-cards are defined, they expect the h-card to point to the site they’re actually on.

Why couldn’t/shouldn’t I delegate my h-card on subdomains or other personal sites to point to the representative h-card on my primary site? What if parsers could follow other rel=”me” links on my site to find/intuit a representative h-card from one of those? While I could have lots of domains to better differentiate my online identity, why couldn’t I do that, but still have the same primary identity?

Replied to One Avatar To Rule Them All by Terence EdenTerence Eden (
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.

I like the idea of the microformats web extension. I suspect it could do with an update to microformats v2 though. The idea of being able to parse a page and add contact information or events directly to my address books or calendars is pretty awesome.

I could also appreciate it parsing a page and allowing me to use an h-card to quickly create a follow post and automatically add a page’s feed to my feed reader.

👓 I decided to work on my website theme for a bit. | David Shanske

Read a post by David ShanskeDavid Shanske (
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.

🔖 ❤️ vilhalmer tweet

Liked a tweet by vil vil (Twitter)

Reply to Aaron Davis about images in h-cards

Replied to a post by Aaron DavisAaron Davis (
@chrisaldrich did you document anywhere how to change the default image associated with posts? At the moment it is using my profile pic, which does not work. Also on: Twitter
Associated how? In the webmentions you send? Typically the receiving site will parse your page to find the h-card and pull out the u-photo for it, so depending on your theme or a custom marked up h-card, that will dictate the photo that shows up.

I have been noticing some issues recently with a lot of photos not showing up in webmentions I receive. Typically they’re for WordPress or sites which may mean issues for Gravatar-based images.

If you want to fix them manually, a recent update allows this.

Setting up WordPress for IndieWeb use

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 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):

A reply to Aaron Davis about h-cards

Replied to A Further Reply to Chris Aldrich in regards to the IndieWeb by Aaron Davis (
I know that I have provided my perspective [already](, but I have been doing a lot of thinking about it of late. There are so many elements that just feel so foreign. Take for example H-Cards.
Aaron, thanks for your continued thoughts on my post. These are some good observations. Interestingly, on November 9th of this month I had noticed that the h-card page on the wiki was one of the few around that had absolutely no section heading for IndieWeb Examples which is nearly ubiquitious on most other pages. (Examples of what others have done is not only a helpful guide, but helps to push the limits of what might be possible next.) I naturally added a section for them and added myself and made a call in the chat for others to do the same. One of the bits of feedback that resulted there was that the wiki had a large number of examples and that was one of the reasons that the IndieWeb wiki had none. Naturally, for people in generation two and beyond this may be an issue as they’re potentially less likely to go looking for this information on another website. As of this afternoon, there’s now at least a link on that page that also points to the microformats wiki page for those other examples. I’ve also added a few other bits which may be helpful with regard to h-cards for the beginner.

As the IndieWeb continues onward, part of the underlying foundation is that “Each generation is expected to lower barriers for adoption successively for the next generation.” – from the Generations page on the IndieWeb Wiki.

To date, the majority of people in the movement are developers or programmers by trade, but increasingly there are people from generation 2, 3, and even many from generation 4 who are starting to take a look at what is now possible on the web that wasn’t just ten, twenty, or even thirty-six months ago. Many are not only just looking, but, like you, are spending the time, effort, and energy to implement what they’re able to and simultaneously spreading the word to larger circles.

As someone who personally identifies as being on the border of generations 1 and 2, I’m finding more and more people seeing what is happening and wanting the fruits and benefits of these tools for themselves. It’s the raw value they find in these methods and processes that spur them on even when they find themselves in deeper waters than they may have expected. Fortunately there are a large number of giving and helpful developers in the generation 1 crowd who are watching and listening to those coming after them. They’re taking up the mantle to not only improve things for just themselves, but to improve things for their fellow netizens.

All of this to say that there is currently a slow reworking and refining of material that’s on the wiki. It was only just earlier this week that a self-identifying fourth generation member asked about the word POSSE, which many would rightly consider jargon, and inquired about its relation to the more commonly known term of “cross-posting“. Surprisingly, cross-posting didn’t really exist on the wiki yet, but it was quickly added, and then later expanded to bring the ideas of POSSE, PESOS, PESETAS, and PASTA within it and then tied into the broader idea of syndication.

Your questions about h-card are very similar. Yes, the wiki page on the idea is certainly very generation 1 specific and perhaps a bit over-burdened by jargon. While I don’t think the concept of microformats is very difficult, I also realize that saying that is the result of having spent no less than ten hours reading about it, looking at examples, and implementing pieces of it by hand myself. So how can we make it simpler and easier for the next generation? The page needs a bit of overhaul and work for the next generations. Some of this is my goal in writing an IndieWeb book, though it’s geared toward an audience that is less likely to get their information from a wiki or contribute back to one in practice.

While h-card is a specific type of microformat, in practice most instances of it on the wiki are really referring to an object on a webpage that conveys identity. I’d suggest that it’s far easier to look at an h-card as an online version of a business card that contains some basic information about a person (or even a business or other entitiy) online. It has things like their name, their address, their email, their phone number, perhaps a photo, or even other very basic information about them. Each of these pieces of data has its own microformats to indicate to machines what they specifically represent.  While some h-cards are human readable (like mine), some could be hidden in a web pages’ header and are meant to be machine readable.

While h-cards can convey data in other use cases, in most IndieWeb instances they’re conveying information about either the owner of a website (and thus found on the site’s homepage), or they’re found on individual posts as indicators of the authorship of the content on that page.

Depending on how they’re nested into a web page, they can have different meanings. As possibly the most common example on a traditional WordPress article post, the main h-card for the page would indicate information about the author of that post. However, these article posts will often contain comments sections at the bottom and each individual comment will have it’s own separate author and author information and thus its own h-card. Because these comments are properly nested, they only indicate the authorship of each particular sub-section of a page.

For most IndieWeb use, having an h-card on your homepage tells parsers (code run by other computers) who you are and some basic information about yourself. Generally this extends to your name, your avatar, and your homepage URL.

In your case Aaron, when you’ve generally been sending me webmentions from your primary website (, I’ve often been missing your avatar in your comments because you didn’t have an h-card available on them. (I typically remedy this on my own website by hand because I’ve been able to guess the email address/”key” you use for your Gravatar account which then automatically fills in that missing data for me on those comments.)

In the particular case here, for your reply you’ll notice in looking at the source for the page with your response that your ZenPress theme smartly and kindly includes an h-card for you automatically. Here’s what it looks like in code:

<div class="entry-meta">
<address class="byline"><span class="author p-author vcard hcard h-card" itemprop="author" itemscope itemtype=""><img alt='' src='' srcset=' 2x' class='avatar avatar-40 photo u-photo' height='40' width='40' itemprop="image"/> <a class="url uid u-url u-uid fn p-name" href="" title="View all posts by Aaron Davis" rel="author" itemprop="url"><span itemprop="name">Aaron Davis</span></a></span></address> <span class="sep"> | </span> <a href="" title="10:06 pm" rel="bookmark" class="url u-url"><time class="entry-date updated published dt-updated dt-published" datetime="2017-11-22T22:06:22+00:00" itemprop="dateModified datePublished">November 22, 2017</time></a>

You’ll see that it includes (and I’ve highlighted them in red with the relevant microformats classes) your name, your website URL, and it also pulls in your Gravatar avatar using the WordPress back end, since you’ve provided your WordPress installation this data. This is the benefit of a smartly built and designed theme! Thus it would seem that for your “Collect” site, you needn’t worry about an h-card because your theme is already handling the details for you to a great extent. Ideally all themes would do this using standard data fields within a WordPress install. But until then…

Anticipating your next question, what about There, your theme isn’t doing this work for you, so you’ll need to do it yourself. The easiest way to pull this off quickly is to use the IndieWeb Plugin for WordPress. The plugin adds a bunch of additional fields to the page under the “Users” menu located at /wp-admin/profile.php within your admin UI. By filling them in you’re providing the details you’d usually add to an h-card or for rel=”me” uses. The IndieWeb plugin then also makes an h-card widget available at /wp-admin/widgets.php. You can drag and drop it to any of the available pieces of your theme which often include sidebars, footers, and sometimes headers.

The widget does a relatively good job, but some will want more control over what and how things are presented and designed. For those, another option is to create your own HTML-based widget and put the code/data for your h-card into it. This is essentially what you’ve seen on my homepage at While mine is entirely handcoded, it may be easier for most to use the microformats website which has a fill-in-the-blanks h-card generator that will allow one to input all of the data they’d like to display and it will automatically mark all of it up properly so that one can cut and paste the semantic HTML directly into a web page or a widget.

There are a bevy of other options for dropping an h-card into your site which will work. You mentioned doing something via a child-theme and that’s an option as well as any one of dozens of plugins that will allow you to drop arbitrary code into your header and/or footer. (Incidentally a child-theme is an excellent way of doing small customizations of your theme without preventing future (security) updates of your theme from overwriting them. If you’re not using one, I recommend following one of the tutorials on the wiki to create one. I would hope it shouldn’t take you more than an hour to implement based on what I know of your skill level.)

As I think you’ve mentioned, there are a few simple validators that will accept a URL which they can parse to show the h-card data they find. These include:

People can use these to see if their h-cards are working as they generally expect them to.

Naturally, there are some additional subtleties in h-cards which are noted on both the IndieWeb wiki and the microformats wiki pages, but most of these aren’t of huge consequence to average users or are experimental features which aren’t widely distributed or supported. If it makes you feel better, I’ll also note that it’s not always the case that experienced theme builders or even WordPress core maintainers will properly use microformats as there are frequently cases where they’re wildly misused, abused, or mistreated in the extreme. We can only do our best I suppose…

Hopefully some of this helps put things into perspective. Now that you’re able to sign into the IndieWeb wiki, I invite you to add or modify parts you feel could be clearer or improved as you use and implement them yourself. Surely doing so will help make things easier for those that follow us both.