Scoping XFN and identifying authoritative hcards

Before I can write up my proposal for transcending social networks, I need to clarify the originating and destination scopes of XFN links.

It’s currently understood that links describe personal relationships between two URLs.

Typically the endpoints of XFN links are URL-centric personal blogs (i.e. or, but not always. And because we can’t always assume that the outgoing linker speaks for the whole URL, or that the destination linkee is all inclusive, we need a set of standard criteria to help us determine the intended scope of the originating linker.

Put another way, how can we better deduce who is XFN-linking to whom?

Let’s take a concrete example.

The established XFN protocol states that when I XFN-link from my blog at to, that I’m describing the relationship between me and Tara Hunt, and our blogs act as our online proxies. Readers of our blogs already know to equate with Chris Messina and with Tara Hunt, but how can computers tell?

Well, if you check our source code, you’ll find an hcard that describes our contact information — marked up in such a way that a computer can understand, “hey, this data represents a person!”

If only things were so simple though.

If I linked to Tara and there were only one hcard on the page, you could probably assume that that single hcard contained authoritative contact details for her since knowing that Tara blogs at there’d be a good chance that she put it there. Sure enough, in her case, the hcard on does represent Tara.

Now, flip that around and let’s have Tara XFN-link back to my blog. This time instead of one hcard, she’ll most certainly find more than one hcard, and, most perplexing of all, most are not me, but rather people for whom I’ve marked up as hcards in my blog posts.

So, if you’re a computer trying to make sense of this information to determine who Tara’s trying to link to, what are you to think? Which relationship is she trying to describe with her link?

Well, as a stop-gap measure that I think could be easily and universally adapted to add definitiveness to any arbitrary hcard at the end of an XFN link, I propose using the <address> tag. Not only has this been proposed before and not been overruled, but it is actually semantically appropriate. Furthermore, there are already at least a few examples in the wild, notably on my blog, Tara’s blog, and most importantly, Tantek’s.

Therefore, to create a definitive an authoritative hcard on any page, simply follow this example markup (note the self-referencing use of rel-me for good measure):

.code { border: 1px solid #ccc; list-style-type: decimal-leading-zero; padding: 5px; margin: 0; }
.code code { display: block; padding: 3px; margin-bottom: 0; }
.code li { background: #ddd; border: 1px solid #ccc; margin: 0 0 2px 2.2em; }

  1. <address class="vcard" id="hcard">
  2. <a href="" rel="me" class="fn n">Chris Messina</a>.
  3. </address>

At the destination URL, include a fragment identifier (#hcard) for the hcard with the complete contact information and add rel-self in addition to rel-me (as per John Allsopp’s suggestion):

  1. <address class="vcard" id="hcard">
  2. <a href="" rel="me self" class="fn n">Chris Messina</a>.
  3. </address>

This practice will primarily help identify who XFN-linkers intend to link to when pointing to a blog or URL with multiple hcards. In the event that no definitive hcard is discovered, the relationship can be recorded until later when the observing agent can piece together who owns the URL by analyzing secondary clues (rel-me or other hcards that point to the URL and claim it).

Oh, and I should note that from the standpoint of multi-author blogs, we should be able to scope XFN links to the author of the entry — with entry-author making this infinitely easier.

Author: Chris Messina

Head of West Coast Business Development at Republic. Ever-curious product designer and technologist. Hashtag inventor. Previously: (YC W18), Uber, Google.

5 thoughts on “Scoping XFN and identifying authoritative hcards”

  1. ADDRESS is of course optimal, but the fact remains that it cannot contain block level elements without triggering quirks mode in browsers, so you couldn’t ever mandate it for all hCards.

  2. Good point. I wonder if simply wrapping the “FN URL” object (linked name) would be sufficient — since at least you’d have the person’s name and URL.

  3. Well, in my hCard I have ADDRESS elements with it — wrapped around each contact address (IM, email and so on). In my experience that’s the best that can be done. Whether that’s of any help to parsers I’m not sure. It’s not as easy to imply meaning about the parent from its children.

    What’s more, rel=me> is relative to the page, so in terms of identifying the definitive hCard for the addressable owner of the page, rel=me implies the relevant part of the same semantic even without ADDRESS.

  4. Chris,

    I think self actually suffices for a definitive reference as per the Atom spec from which it is reused by hReview and hAtom.

    See my recent post to uf-discuss for more detailed reasoning.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: