Tags: hcard

Sending your First Webmention from Scratch • Aaron Parecki

A nice little tutorial from Aaron.

Experimental Firefox and Chrome extensions to copy and paste contacts — Glenn Jones

More brilliant and useful code from Glenn: copy and paste contact details from one URL into a form on another URL.

FUMSI Article: Microformats: Digging Deeper into the Web

A nice, neat, short introduction to microformats from Ben.

Google LatLong: Finding Places on the Web: Rich Snippets for Local Search

If you aren't already marking up addresses in hCard, you really, really, really should start.

Any chance of adding hCards | Basecamp Answers

Basecamp is now chockful of hCards. Excellent!

Ident Engine

Glenn has taken Google's Social Graph API, YQL and various parsers, and he's wrapped it all up in one JavaScript library. The demos are mind-boggingly impressive.

The WWW Virtual Punchcard (Punch Card) Server...

A text to punch card translator. Who wants to be the first to pipe Twitter messages through this?

I’m in Seattle. Dopplr tells me that Bobbie is showing up in Seattle on the last day of my visit. I send Bobbie a direct message on Twitter. He tells me the name of the hotel he’ll be staying at.

I use Google Maps to find the exact address. All addresses on Google Maps are marked up with hCard. I press the microformats bookmarklet in my bookmarks bar to download the converted vcard into my address book. Thanks to MobileMe, my updated address book is soon in the cloud . My iPod Touch gets the updated information within moments.

I go to the address. I meet Bobbie. We have coffee. We have a chat.

The World Wide Web is a beautiful piece of social software.

Populating forms with YQL, jQuery and Microformats

Demo for a neat piece of code that will auto-populate form fields from an hCard-carrying URL.

Mosembro | lexanderA

A web browser for Android that detects microformats and allows direct actions with the data. The map integration is exactly the kind of thing I'd like to see on the iPhone.

SitePoint » 4 Easy-to-Use Microformat Tools to Beef Up Your Site

A rundown of microformat-extracting tools. "Ultimately, microformats are a bit like plumbing. They don’t do very much on their own, but if you make use of the data they provide, you can quickly and easily create useful functionality your visitors …

24 ways: A Christmas hCard From Me To You

A great 24 Ways article by Elliot on creating and styling hCards.

Our First Labs Project: A Microformats Toolkit Called "Oomph" - Lab - MIX Online

A handy microformats toolkit from Microsoft(!) making it easier for developers to write, style and find microformats (hCard and hCalendar in particular). Neat!

The microformats meetup in San Francisco after An Event Apart had quite a turnout. The gathering was spoiled only by Jenn getting her purse stolen. Two evenings earlier, Noel had been robbed at gunpoint. San Francisco wasn’t exactly showing its best side.

Still, the microformats meetup was a pleasant get-together. Matthew Levine pulled out his laptop and gave me a demo of the Lazy Web in action…

On the first day of An Event Apart, I twittered a reminder that my liveblogging posts were filled with hCards. Christian asked how I added the hCards and I replied that, while I just add them by hand, some kind of “wizard” for adding simple hCards to any textarea would be very welcome.

Less than 48 hours later, Matthew had whipped up exactly what I asked for. It’s a bookmarklet. Drag it to your bookmarks bar and click on it whenever you want to add a simple hCard. It uses JavaScript to create a faux window with a form where you are prompted to enter given name and family name. You can also add a middle name and a URL.

This is just a small subset of all the properties available in hCard so it isn’t suitable for detailed hCards. If you’re creating the markup for a contact page, for example, you’d be better off with the hCard-o-matic. But this little bookmarklet easily hits 80% of the use cases for adding hCards within body text (like in a blog post, for example).

This is a first release and there will inevitably be improvements. The ability to add XFN values would be a real boon. Still… that’s really impressive work for something that was knocked together so quickly.

If you want to use the bookmarklet (regardless of what blogging engine or CMS you use), drag this to your bookmarks bar:

hCard Wizard

hCard Wizard [Matthew Levine]

Words cannot describe how brilliant this is. In response to a whinging Twitter post I made, Matthew Levine created a bookmarklet to quickly and easily create simple hCards for easy adding to blog posts. It works beautifully.

Digital Web Magazine - Portable Social Networks, The Building Blocks Of A Social Web

Ben has written a superb article outlining the hows and whys of distributed social networks with hCard and XFN, finishing with an inspiring call to arms.

Lustro - milkcarton

A cute little Mac app that exports your address book contacts in multiple formats ...including an HTML file with hCards!

• Download the slides from this presentation.
• Listen to the audio recording of this presentation.

Hello. Fáilte romhabh go léir.

I’m going to talk about, supposedly, creating portable social networks with microformats. It’s a very grandiose title for something that’s actually very, very simple.

Hands up: who was in David Recordon’s keynote yesterday? He had about a two-minute segment there where he showed himself on his own blog having rel="me" in links, and then he showed the OpenSocial thing. That’s pretty much it, really. So, he did it in two minutes and I’ve been given 45. We’ll go into a little more detail, but there really isn’t that much to it. It’s pretty straightforward.

So what this is about is all these different social networks—and there are quite a few of them now. I’m on quite a few social networks myself, and I want to see which ones you guys are on as well. So, a show of hands for any of these:

Pownce, anybody on Pownce? Okay, one or two. Magnolia? Magnolia, a few—like del.icio.us, but with more of the whole social aspect going on. Anybody know a site called Edenbee? No? Social network site for environmental stuff. It’s based out of Dublin, which is why I thought I’d mention it. Upcoming, for events—who uses Upcoming? Okay, quite a few. Last.fm? Music? Okay, good, good, lots of Last.fm-ers. Twitter. Oh, I’m surprised not to see every single hand in the room go up for Twitter. But how about Flickr? Okay, most people are using Flickr.

Alright, so, we’ve got a lot of different social networks here, and on each one, you have to sign up, and you have to enter your details when you sign up—and then you have to go and find your friends on each one, and you have to say, “Yes, I know that person, yes, I want to share my photos with that person, yes, I want to share my music with that person.” And by the fourth or fifth social network, it gets a little bit tiring having to through all this, right? I see some nodding heads—yes, yes, we’re fed up with this.

So, this is one angle of the whole idea of portable social networks: this idea of social network fatigue. But, to be honest, that’s not really such a big problem. It’s kind of something that’s going to affect those of us who use a lot of these social networks, but maybe we’re sort of canaries in the coalmine, and this isn’t really an issue that’s going to affect the average user.

But it’s about much more than that. This isn’t really about the whole social network fatigue thing. It’s about being able to move freely. It’s freedom of travel, the idea that you should be able to seamlessly move between these social networks and not have to deal with the hassles of having to fill in another form or go through another process of finding all your contacts.

And when I talk about social network portability, I’m not talking about, “I’m leaving this social network, I’m taking all my friends with me, and I’m going over to this new social network that everybody’s raving about.” It’s not that kind of portability. It’s more about ease of movement. It’s the idea that I can have as many social networks as I want, and the ease of getting into it and setting it up is nice and simple, and it’s not complicated. So that’s the reason why there’s a lot of different people, very smart people, trying to tackle this problem. It’s really a question of interoperability more than portability.

The ways that people have tried to tackle this problem of trying to make it easy to sign up to a site and then to get all your contacts listed on that site… Well, something that people have been doing for a while is to ask you for your user name and your password—for instance, from a webmail client you might use, like Google Mail or Yahoo Mail or Hotmail.

…Short hiatus while Jeremy is rickrolled by Aral…

Aral just rickrolled me, the bastard!

Audience member: That was antisocial networking.

Jeremy: Yeah. It’s always me! Is everybody familiar with the concept of rickrolling? Okay. Sorry, I just got live-rickrolled, and I think it’s going to be on the Internets in a few minutes.

Where was I? Oh yes, user name and password for third-party sites. So you sign up to a new social network and it says, “Do you use Google Mail, Gmail? Do you use Yahoo Mail? Well then, why don’t you just give us your user name and your password.” Now, crucially here, they’re asking for your Gmail password not on Gmail, they’re asking for it on example.com. They’re asking on the latest social network site that’s probably disemvoweled and ends with the letter “r” without the letter “e” attached.

This is just wrong. This is something that gets referred to as the password anti-pattern, because essentially what you’re doing here is you’re teaching users how to be phished. You’re telling them that it’s okay for you to throw around your password on any site. So instead of saying, “Only ever enter your Gmail password on Gmail,” this is saying, “It’s okay to throw around your Gmail password willy-nilly.” And in the long term, this is really, really harmful.

And it’s just really, really insecure. How do you trust this site? How do you know it’s not going to spam all your friends? How do you know it’s not going to go into your inbox and use that account that is also the same account you use for Google Checkout, if you use Google Checkout.

To get around that, what people have been doing is using APIs, which is a much more secure way of dealing with this issue, where you can authenticate, give authorization to a site like, say, Gmail or Yahoo Mail or whatever. This combination of using an API together with some kind of authentication is much safer and much more secure, and this is why you see this combination of some sort of API and some sort of authentication, like OAuth, or like BBAuth, or AuthSub—there’s all these different kinds of authentication things.

Now, for instance, with Gmail you can do this; there’s a Google Contacts API. So in this case, you say, “Hey, do you have a Gmail account?” They say, “Yes.” “Well, okay, click this button to start importing friends.” And you get sent off to the Google domain—and there you might have to input your user name and password, but that’s an order of magnitude better than doing it on a third-party site. The flow works much better.

OAuth is aimed at making this flow work the same for all these different social networks and sites so that you don’t have to write a different API call for every different social network. And it’s pretty much based on the Flickr model. If you’ve ever used some desktop application that uses the Flickr API, you know that first you have to authorize it, and that involves going to the Flickr site and saying, yes, I give permission to allow this application to look at my photos, or maybe I give it permission to also upload photos. You set the permissions. So this is good. This whole combination of some sort of authentication, like OAuth, and some sort of API works really, really well.

But it is quite complex. That’s not a bad thing for us; we’re all pretty smart developers, and we can implement this kind of stuff. But there is a certain barrier to entry with getting this stuff done. It’s not something you can do overnight.

I would say this is generally the best way if you are trying to get, say, email addresses out of an address book. Whether that really defines who your friends are is another question again. I don’t know how it is for you, but for me, email is no longer really the defining factor of whether somebody is my friend, somebody I know. I’m very good friends with a bunch of people and I don’t even know their email addresses. I might know them on Twitter and Flickr and Last.fm and all these other places, and if I stopped and thought about it and I wanted to write them an email, I’d think, actually, I don’t even know their email addresses. So if you think of email as this way of getting at contacts, then this way works pretty well. But like I said, I’m not even sure that an email address is still an identifier for having a friend.

There’s this other way which kind of complements all these other methods like APIs, which is to use microformats. Microformats are not very full-featured, not a very complex way of transferring information or storing data. It’s really all about being lazy, frankly. There’s a couple of microformats principles, and they’re all pretty much based on being really quite lazy.

Hands up if you’re familiar with microformats. Okay, good, that’s good. I was kind of assuming that I wouldn’t have to go into much detail. But just to give a quick overview of the philosophy behind microformats, and this philosophy of laziness: They’re built on the idea of reusing. At all costs, avoid reinventing the wheel. If somebody’s already solved the problem and there’s some kind of standard out there, steal it. Just take it verbatim, use it. And they’re deliberately simple, they deliberately don’t try and solve every problem. “Avoid boiling the ocean” is one of the principles.

There’s this idea, the Pareto principle—which comes from economics, the Italian economist Pareto—also called the 80/20 principle. I think what he noticed was that 80 percent of the wealth was with 20 percent of the population. These numbers show up in quite a few different places, and the Pareto principle applies to microformats in the sense that if we can hit 80 percent of the use cases with 20 percent of the effort, that’s good enough. Because as soon as you get into that extra 20 percent, the edge cases, the effort required to cover those edge cases gets exponential. So whereas other formats will aim to hit 100 percent of the possible use cases—that you should be able to encode absolutely any possible, conceivable scenario—the formats tend to get kind of complex, because the effort required to design a format that can cover all those scenarios increases exponentially.

With microformats, the idea is, “You know what? There are some cases where this just won’t work.” There’s an event microformat, for instance—hCalendar—and you might have a situation where you say, “Aha, but what about this kind of event, where it starts here and it’s in a leap year on a full moon, and how does the hCalendar microformat cope with that?” Well, it doesn’t. Basically, we’re not even going to try. You’re falling into that 20 percent edge-case stuff, and you’ll need a different format.

Again, it’s kind of being lazy. There’s this whole idea—I think was Joel Spolsky who said that good programmers were lazy programmers because you just always look for the simplest solution, and that’s the sign of a good programmer. That’s definitely the philosophy behind microformats. It’s like, “Aww, you mean we have to work on this stuff? Can’t we just steal somebody else’s work?” Because that’s what we do: just reuse, borrow, steal, build on existing formats. That’s a key thing: to not try and come up with something brand new, to always build on what’s already out there.

Crucially, as well, when deciding what needs formatting, what should be a microformat and what shouldn’t, is look at what people are publishing. Not what we think people should be publishing—we’re not trying to encourage people to publish this kind of data or that kind of data. It’s much more about what kind of data are people publishing anyway that could do with being formatted a bit better.

If you look at the language that people are publishing in, the existing language, that is very much HTML on the World Wide Web. It’s far more popular. Theoretically, you can put a Word document on the Web, a PDF, you can put all sorts of things on the Web. But HTML is the lingua franca of the Web because it’s a good, simple markup language.

There’s this idea that microformats, because they’re in the HTML, people are coming to this idea that because we’re publishing these microformats in the HTML—and HTML on the World Wide Web is kind of like a RESTful interface because you’ve got a URL, and at that URL there’s a Web document which happens to be HTML rather than XML or JSON, but still, it’s an addressable document—could your website be your API? Could you point at a URL and say, “Extract this data.” And to a certain extent, you can with microformats, though it’s very much a read-only API, whereas with a fully-featured API you can read and you can write.

With microformats, it’s kind of possible to build a super-simple, almost dumb, read-only API. Because if you look at what’s being published inside the HTML, you’ll find there’s a bunch of different stuff. On a social network site, there will be a page that has my details. So that data is already being published. This isn’t something we need to encourage social network sites to publish; they’re publishing it already. Who my contacts are on a social network site—that’s already there, that’s already in the markup at a publicly available URL. And then the details of those contacts are also being published in the same way that my details are.

So each one of these is being published, but if they’re just being published in regular HTML, there’s some semantic fidelity being lost because there are no elements in HTML to say this is a human being and this is that human being’s contact. We’ve got a nice set of elements in HTML, but they don’t provide quite that level of semantic fidelity.

Let’s go through these. For my details, somewhere on a social network site—how do we identify a person? To do this, we have the hCard microformat, which is essentially an HTML version of vCard. vCard is the address book format that you’ll find on your desktop in Outlook Express, you’ll find it on your mobile phone in your address book there, you’ll find it anywhere where addresses are used. So that whole idea of being lazy and reusing existing formats very much applied to the creation of hCard, where, when we were deciding what values should be in hCard, it was every single value that’s in vCard—and that’s it, we’re done. Game over.

Let’s say on a social network site, I’ve got a link like this that’s linking off to my profile. This social network site, example.com, has got a profile page for me. My user name on this site is adactio, because my user name is adactio on pretty much every social networking site. I can wrap that with some kind of containing element—in this case it’s a span, but it could be any element, we don’t mandate what elements you need to use—and this is going to be an hCard. The reason it why says vCard rather than hCard is because, as I said, we took all the values from vCard verbatim. Because vCard begins with the root element of “vCard”, it’s always called vCard in hCard. And I say, “This is the formatted name and the nickname, and this is the URL.”

There’s actually a whole lot of optimization going on here, because technically in vCard, you must a formatted name—or “name” is the only required value, I think. There are all these optimization rules, like, if you see “fn” and “nickname” together, that means, “This is the nickname and it’s the formatted name because we don’t have the full name.” And for the URL, it knows to look in the href rather than in the text between the opening and closing tags.

There are just a couple of classes there, and, of course, the great thing about the “class” attribute is the fact that you can space-separate values. And I could be throwing on my own classes there and that would be absolutely fine; I could be putting in non-hCard values: fn, nickname, url, user name, profile—any of my own class names are absolutely fine.

What this does is that it basically says: this is a human being, these are the contact details for a person, and this is that person’s nickname, and this is a URL that represents that person—just with the addition of a few class names.

This is something that I think people sometimes forget with hCard. If you’re familiar with hCard, the usual way it’s sold or pushed is that, well, it’s like vCard, so you put up your contact details and then people can translate it to vCard. There are plug-ins for Firefox, there’s a Technorati service that will convert hCard to vCard. So people wonder sometimes: what’s the point of putting up an hCard that’s only got this much information? Because here you’ll see that there’s no email address, there’s no telephone number, there’s no street address—none of these kind of real contact details are in there. All this really does is identify one piece of string on a page as being a person as opposed to some other piece of string which is just a text.

So, there is value in using really, really simple hCards. If you converted this to a vCard, it wouldn’t be much use. You’d have that in your address book, but you couldn’t call me, you couldn’t email me—it’s not much use. But there is still value in identifying this piece of text as being a human being.

What we’re doing here is essentially making up for the fact that there is no “person” element in HTML. The elements I’ve had to use are things like “span” or “a”—like I say, use whatever elements you want. But the great thing about HTML is that we are provided with our own semantic building blocks, like the “class” attribute, which, as the spec said, is for general-purpose processing by user agents. So it there for you to add your own semantics. It kind of got co-opted by CSS for many years, where people thought that the only reason you ever used classes was for CSS. But that’s not true. There is a CSS class selector, but you can use classes as hooks for Javascript, as hooks for whatever you want. It’s for adding your own semantic data.

On this page on this social network site, it’s linking off to a profile page that represents me. And if we go to that profile page, I’d probably have another hCard there. In this case, the element might be h1, say, because now we’re on the page that is about this person. Like I say, you can use whatever element you want. And I’m saying, this is the URL, and it’s linking off to my other URL, my homepage, my blog or whatever. And here I’m saying “fn”, formatted name—here we’ve actually got my full name rather than just my user name, so there’s more information being added here. And this is the kind of stuff that a lot of social networks are publishing anyway.

So, this is useful; we’re getting a lot of different bits of data about me pulled together. But what’s really nice is to tie together the fact that, okay, this page we’re on, on example.com, this represents me, this is a page about me—but this other site as well, adactio.com, that’s also a URL about me. It’s a URL representing a person. So, by adding one value, rel="me", we make that explicit. We say, that URL is me also.

So, the rel attribute you’re probably mostly familiar with from using in the link element at the top of your pages when you link off to a stylesheet; you’ll say link rel="stylesheet". And what that is doing is saying, this document I’m linking off to is a stylesheet for the current document. So it’s the relationship—the relationship of the linked document is “stylesheet”. Here, what we’re saying is the relationship of the linked document—the value in the href—is “me”. There’s a relationship being established.

Audience question: Why do you need the URL in the class anymore?

Jeremy Keith: What’s happening here is the fn and the URL are for the hCard, and this rel=”me” is part of XFN. So now what we’ve done is that actually we’ve got two different microformats going on. So: fn, URL, hCard, rel="me", XFN. And that’s one of the other nice things about microformats: you can mash them up. You can have an hCard and an hCalendar and XFN. They lend themselves well to being built Lego-style and put together like this. That explains why they’re all there: there’s two different microformats here.

So, XFN is this other microformat. I say it’s a microformat, but it’s actually kind of a proto-microformat in that it existed before microformats did. Microformats have to go through this whole Process before you have a finished microformat. It takes a while and, like I say, it has to fulfil all these criteria, it has to solve a real problem, it has to be using stuff that people are already publishing.

XFN didn’t do any of that. XFN was kind of born fully-featured by a bunch of people who got together—it was Tantek Çelik, Eric Meyer, Matt Mullenweg who got together and said, okay, we want to have a whole bunch of values for defining relationships between people. They did base it on what people were publishing, because around that time—this was a good few years ago—blogs were taking off and getting very popular, and what you’d have a lot in blogs was you’d have a sidebar with a blogroll. It’s always Americans who call it blogroll. Nobody over here seems to call it blogroll because I think it sounds too much like bogroll. There it sounds like logroll, but here it sounds like bogroll.

Anyway, what that means is you’ve now got something for representing the idea of contacts, which was the second part of what we were talking about—the kind of data that’s already being used on social networks.

Let’s say that on my profile page, I might have a list—an unordered list, an ordered list, whatever—of people who are contacts of me. I’ll mark them up as hCards as well—might as well, there’s no harm in there—but I will also add an XFN value, in this case “contact”. So here the relationship is the linked resource has the relationship of being a contact of the current resource.

XFN actually has a whole bunch of values—13, 14 values I think—but really, contact is enough. This is something that Chris Messina talked about recently after we had a panel discussion at South by Southwest, that instead of trying to convince people that you’ve gotta use XFN, you’ve gotta use XFN, it was like, well, actually, you’ve gotta just put these few characters into a link, rel="contact". That’s actually enough.

There’s a whole bunch of XFN values like friend, sweetheart, crush, co-worker, colleague, all these things. But I think for social networks, you don’t need them. I think on a personal site, it’s still good to have that. When I’m writing a blog post and I link off to someone, I like to have the ability to say I’ve met that person and I consider them a friend and they work in the same industry, so they’re a colleague. I think that level of fidelity is nice to have on personal publishing sites, but for social networks it can actually be really dangerous to programmatically try and say, “You are friends with that person.” That’s something that a person should be deciding for themselves. So I kind of agree with Chris that, at least in the case of social networks, rel="contact" is plenty. That’s enough.

If you have a social network that’s, say, a dating site, then maybe you would want to use rel="crush" or rel="sweetheart". But that’s kind of an edge case. Or if you have a professional site like LinkedIn, then there’s a use case for rel="colleague", rel="co-worker", these kinds of things. But, mostly, rel="contact".

So, essentially, out of XFN, two really, really useful values are rel="me" and rel="contact". And that’s it. There are a whole bunch of other values, but you don’t have to worry about it, I would say. For the purpose of building a social network, at least, don’t worry about them.

I’ve probably got a whole bunch of friends like this, and I’m linking to all of them: this is a contact, this person is a contact, and they’d all be marked up as hCards and all that. What happens a lot of the time is that I’ll have so many friends ‘cause I’m so popular that it’ll go on to more than one page. It’ll paginate. This is how it works on Flickr and on Twitter; you’ve got a page full of twenty contacts, click “Next” to see the next twenty and the next twenty and the next twenty. What you can do there is that you can semantically attach some more data here to say, okay, we’re continuing on. So this is another page representing me, and we use the rel="prev" and rel="next" values that have actually been baked into HTML for quite a while. They’d be used more in the “link” element, but there’s no reason why you can’t use them in the “a” element as well. So this works really well for pagination. This is another page representing me, the next page, and the previous page representing me as well.

So, again, this rel="me" thing is very handy. And, like the “class” attribute, the “rel” attribute can take multiple values, space-separated. Very, very useful. So there are few little things in HTML that are incredibly powerful. Incredibly powerful.

Finally, you’ve got their details. And that’s really just the same as what you did for your own details. In the same way as I had my page that was marked up with hCard and XFN, any one of my contacts—in this case, my friend Brian—he’s got his own profile page, and that’s got his hCard on it, and it’s linking off to his URL, and that’s tied up using rel="me". So, if every one of my friends has something like this, that’s quite a large network of friends.

And that’s pretty much it as regards what you need to do to add that extra bit of semantic goodness in there, to make it clear that this is a person, this is a contact of that person, here’s another page of contacts of that person. It’s just using hCard and XFN. Not even a full hCard, a very simple hCard, and not even many XFN values. Two values we’re talking about here, really: “me”, “contact”. “Prev” and “next” aren’t even XFN values, they’re just values. And we’re talking about two attributes of HTML—not even elements, attributes. Not new, custom attributes that we’ve invented; these are attributes that have been in HTML for quite a while.

It isn’t a replacement for an API. I’m not saying you don’t have to worry about making an API. But this makes a nice complement: the fact that, until you get around to building that API, why don’t you just add a few class and rel values and you’ve got a nice, simple, read-only way of allowing people to get at that data.

And generally I would also say: allow people to get at your data in as many formats as possible. So if you are building an API, of course you’ll export in XML, say, but you’ll want to export in JSON as well because developers want to have that format. Well, why not do this as well, so that if that’s what they want, rf they want to get at it in this hCard or XFN format, give them that option too. Basically, you can’t have too many data formats as far as developers are concerned. Give them anything you possibly can.

As regards publishing this stuff, it is that simple. It is that two-minute thing that David showed in his keynote yesterday: rel="me", rel="contact", some hCard values where applicable.

What about parsing this stuff, though? What if you want to consume this information from a social network that is publishing XFN and hCard? That’s tricky, because that’s hard work. Parsing can be tricky, parsing an HTML page—you’d usually have to run it through something like HTML Tidy to get it all cleaned up so you can then parse it as a well-formed document, because most HTML is actually pretty messy out there. Then what’s even harder than parsing is spidering, having to follow all those links, all those rel="next", all those rel="contact". Following all of those, programmatically, that’s actually a lot of work to do.

Fortunately for us, Google have taken care of it for us. This is kind of exactly the thing that Google are good at, because to do this spidering and parsing, you kind of need to have a copy of the World Wide Web stored somewhere on you server—which they happen to have, which is really handy. There’s a video of Brad Fitzpatrick talking about how they did this, and it’s basically, “Well, we took all the links on the World Wide Web and threw away all the ones that didn’t have rel values.” But that’s pretty much what they can do.

So, we can use what they’ve done. They’ve provided an API, the Social Graph API, which, again, David was demonstrating yesterday. And this will spider rel values—it’ll spider rel="me", it’ll spider rel="contact", it’ll spider all that stuff, it’ll spider the previous and next values—and it will send back a JSON file of what it finds. You can also use this to parse FOAF files, and it will follow all the FOAF files. What it does is it actually takes the FOAF files and converts them to XFN, so it always ends up as XFN right before the end anyway.

Let’s say you’ve got a new social network site, and you’re trying to get sign-ups, you’re trying to get people to join your site, and you want to make it as easy as possible. Give them the option to provide a URL somewhere else, and then use this Social Graph API to spider that URL and look for contacts, and look for other URLs that represent this person, and look for contacts over there. And then you’ve got to try and do some matching and figure out if you’ve found a contact for this person. This isn’t a Boolean thing, this isn’t a one/zero kind of thing where you can say, “Oh, that person on that social network is the same person as this person over here on this social network.” We don’t have any kind of unique identifier for this, but you can use some fuzzy logic here, I think.

If you’ve got a formatted name, which is the fn name in hCard, and it’s the same value over here as it is over here, that’s a pretty good chance. Not 100 percent, as I say, there are edge cases. But if there’s a Jeremy Keith on that site and there’s a Jeremy Keith on your site, it could well be the same person.

You’ve got the nickname, because a lot of people use the same user names on a lot of different sites, so that’s something to check out. If you get a combination of the two, that’s looking really good. And actually, URL is something that people identify with a lot, so when you allow people to put in a URL on a website—it’s usually their blog or something—and if you find a match for that, that’s looking pretty good.

None of these are 100 percent, absolute certainty things to say, “Yes, that is definitely the same person as that person over there.” But with a combination of matching this kind of stuff, you could probably make a pretty good guess.

What you don’t get is email, generally, because this isn’t something that’s generally published on the public Web because of the spam we’ve had to deal with for years. So most social networking sites, on your profile page, they will not display your email. And rightly so; that’s information you wouldn’t necessarily want published. So when it comes to parsing this stuff and matching values, you don’t have access to email, usually, whereas you would if you were doing the whole address book API thing.

But I think you can get by pretty well with what you’ve got. And email is often used as a unique identifier, but I’m not even sure that that’s a safe bet to make.

So, what I’m saying here is, basically, you don’t get 100 percent accuracy, you get maybe, about, 80 percent. So we’re kind of back to this 80/20 principle. You’ll probably get about 80 percent of the people where you say, “I think they’re pretty much the same person,” and you might get some edge cases that fall through and it doesn’t match them up, or you get false matches and say, “Ah, that person isn’t actually the same person.” But that’s pretty much it as regards parsing.

To anticipate some of the questions you might have and pre-empt some of them, questions that get asked a lot include: what about trust? How can you believe the assertion that this person is that same person over there on another social network. I’m signing up to your social network and it says, “Give me a URL,” and I put in a URL. How do you know that’s really my URL? I could be putting in your URL or your URL. How do we trust this input?

Well, we can’t. Or at least, that’s not something that microformats can solve. But this question of trust is something that’s true of everything on the Web. How do you trust any piece of information you read on the Web? And it’s different for every person. You can try and solve this programmatically—you’ve got secure certificates and things like that—but generally, this is actually a problem of just publishing on the Web anywhere.

Some people will read a Wikipedia article and they will trust that source because it is on Wikipedia. Other people will read a Wikipedia article and they will not trust that source because it is on Wikipedia. What I’m saying is that it’s different for every person. So you can’t make any assertions about the veracity of a claim just using the format. However, there are other technologies out there that do aim to solve this. So, OpenID aims to solve this one, to say you can authenticate the fact that that person claiming to reside at that URL really does reside at that URL.

By mashing up microformats for the formatting and OpenID for the authentication, then you can be pretty secure. But the whole idea of trust and authentication is not something to be solved at the formatting level. That is something to be solved at the protocol level.

Now, what about walled gardens? Because everything I’ve been talking about has been publicly published information, and I would say that this whole idea of hCard and XFN does work best on public websites. If you are running a walled garden like Facebook—Facebook does not allow much in the way of public access to profile information or friends lists, contact lists, all that kind of stuff—what do you do in that case? Well, I still think there’s no harm in publishing hCard and XFN because it only takes a few seconds to edit a template and put in those values. But, of course, the Social Graph API or other spiders can’t get to that information because you’ve locked it up in a walled garden behind a user name and password.

Again, some kind of mashup with an authentication layer like OpenID or SSL or password authentication would allow access. But generally, for walled gardens, you’re probably going to be relying on a more complex solution to get at that data: an API together with something like OAuth, or we saw the Open Social building-new-widgets thing and doing all that. But generally, for walled gardens, things get more complex. It’s just the way it is. For stuff that’s public, it’s generally straightforward.

So, who is publishing this stuff on the public Web? Well, every single one of those sites that I asked you about earlier on, every single one of those sites is publishing hCard and XFN. And you could plug one of your profiles on those sites into the Social Graph API and get back a whole list of contacts that you could then suck into another website. So there are a lot of people publishing.

Who’s parsing this stuff? Not many. Surprisingly few, considering how relatively straightforward it is now using the Social Graph API. Although the Social Graph API has only been around since the end of February, start of March. So, okay, that’s not very long. It’s not that surprising. Dopplr is doing some nice stuff, where you enter a URL and it tries to find people who are already on Dopplr who are on some social network site over there. Get Satisfaction does something interesting; it doesn’t have a friends list, a contact list or anything like that, but it does have a single-field sign-up which is really nice. The first question—you can fill in the whole form, saying what’s your name, what’s your email address, all this kind of stuff, or you can fill in a form over here which is one field, which is: What’s your URL? And if that URL is encoded as an hCard, it will suck out the hCard data. But it’s not yet doing the whole friends list stuff.

So there is room for some innovation here, for you people to get in there and start doing this stuff and get a leap. So the future is looking good. Like I said, this idea of one form field for sign-up. And actually, David mentioned this yesterday, and I didn’t even realize that Plaxo and Pulse were doing this, that it asks you for an OpenID URL, a URL that represents your OpenID, and while it’s got that URL, it says, “You know what? I’ll just run this through the Social Graph API and see if I find any rel links that I can match against people who are on my social network and see if you’ve got any friends here.”

So it’s this idea that I can come to a new social network site, and instead of filling out a long form with my contact details and then going through the whole process of saying that these are my friends, I could least try at the start to say, look, here’s my URL, you do the work. Don’t make me do the work. You go find who my friends are, you go find my contact information. Again, you won’t get 100 percent accuracy, but you’d get maybe 80 percent and you’d do pretty well.

So what you can do, certainly, is start publishing this stuff. The parsing, like I said, is pretty hard, but certainly publish this stuff, because it’s so easy to add these rel values and it’s so easy to add these class names.

But I would say that the real challenge here—because from a technological point of view, it’s really simple—the real challenge is in design. How do you design this stuff to flow nicely, how do you design it to not be creepy? That you make this flow nice… Some of the things would be: don’t use jargon. Don’t ever mention microformats or hCard or XFN or any of that stuff. People don’t care, and nor should they. They shouldn’t know what the technology is.

And don’t make assumptions. You’ve got an 80 percent match, you think that person is the same person as this person, we’ll make them friends on my network—don’t assume that. Always allow people to explicitly make that connection. So you might provide a list of names with checkboxes and allow people to check or uncheck those names. Don’t assume anything like that.

Should you notify people? When you’ve stored their network from over here, and now when a friend of theirs from over there joins a week later, do you let that person know? Do you send out an email saying, “Hey, your buddy from Flickr just joined our new social networking site!” Or is that creepy? These are kind of design challenges.

And what about allowing people to subscribe to it: rather than a one-time import, store that URL. So you say, “Do you have a URL on some other social network?” “Yeah, here’s my Flickr URL.” Instead of throwing that away once you’ve spidered it for XFN values, hold on to it, and every couple of days, spider it again and see if there’s any new people? In other words, allowing people to subscribe to a contact list somewhere else rather than just import. Again, design challenges, trying not to be creepy, that can be tough.

What I would say is that the technological side of things is super simple. It really is just a couple of attributes. The real challenge here is design. Big “D” design thinking sort of stuff. But that’s why we have designers. They’re going to help us solve this.

So, my website is adactio.com, I’ll post these slides up there and blog about this later. And microformats.org is where you can go to learn more about microformats, but you pretty much got everything you need from that little session there.

Thank you very much.

• Listen to the audio recording of this panel.

Jeremy Keith: Welcome to the Building Portable Social Networks panel. I’ll be your moderator. My name is Jeremy.

A little bit of housekeeping first. Obviously you don’t have to switch your phones off, but if you could switch your phones to silent, please, so we don’t have any interruptions, because—don’t make me come down there. I swear to God, I will shove it up your orifice if I hear one ringtone during this panel.

[laughter]

Jeremy: So, we’re here to talk about portable social networks. I kind of want to know what social networks you guys use so I’m going to ask. I’m going to list some social networking sites, and if you have an account with this site, you should raise your hand. If you have built or are an employee of the builders of the site, then you’ve got to whoop and cheer, because there’s a good chance, at South by Southwest, that that’s entirely possible.

So let’s take a random sampling. Who has an account at Dopplr? Okay. And I don’t hear any cheering, but that’s a good amount.

Joseph: Dopplr’s broken out. That’s pretty clear.

Jeremy: Who’s got a Pownce profile?

[whooping from audience]

Jeremy: A bit of whooping? Great. All right. Cool. Last.fm?

[whooping from audience]

Jeremy: Yeah. And there’s some whooping. There’s some whooping. Excellent. Digg?

[whooping from audience]

Jeremy: Wow. Lot of Digg. All right. Let’s see how many hands we get for this: Twitter.

[loud whooping from audience]

[laughter]

Jeremy: Nice.

Leslie: Nice. [laughs]

Chris: Was that a howl?

[laughter]

Joseph: No werewolves…

Jeremy: Yeah, we’re not playing werewolf here. And finally, let’s see Flickr.

[loud whooping from audience]

[laughter]

Jeremy: All right. Now, on each one of those accounts, you had to enter your details every time. And on each one of those accounts, you had to find your friends, contacts—call them what you want—on those accounts, and you had to say, “Yes, I know this person; yes, I want to share my photos, trips, music, whatever, with those people” every single time. Please raise your hand if that got really annoying after a while.

[whooping from audience]

Jeremy: All right.

[laughter]

Jeremy: [laughs] that’s what we’re here to talk about today. And to talk about this, I have assembled a crack team for my panel. And I’m now going to ask them to introduce themselves…

Chris: Why’s it never a marijuana team?

[laughter]

Jeremy: Okay. We’re going straight to the crack. I’m going to ask them to introduce themselves. They’ve got about 60 seconds to introduce themselves. And points will be awarded for creative and interesting facts. Points will be deducted for blatant pimping of companies. So I’ll start over here. Chris, do you want to go first?

Chris Messina: Sure. So my name is Chris Messina. I won’t do any affiliations, but a couple of interesting facts. One is that I don’t like olives. The second is that I’m from New Hampshire. And third is that my alter ego online, Factory Joe, is actually from a “1984”-esque dystopian comic that I drew in high school.

Leslie Chicoine: Nice. Hello. My name is Leslie Chicoine. And let’s see, interesting facts. I was suspended from high school. I have a game design degree. And—oh, my God, everyone’s looking at me.

Jeremy: You can name your company. It’s Okay.

Joseph: Yeah. You should really say where you work for.

Leslie: Oh. I work for Get Satisfaction.

Jeremy: Minus one point.

[laughter]

Leslie: Oh! That was trickery! Did you see that?

Joseph: This is a tough panel.

David Recordon: I’m David Recordon. I’ll take the one-point hit right now. I work for Six Apart. But I’m repping two other companies right here. I’ve got the Blogger glove on, since the whole idea of portable social networks—like our blogging software, their blogging software—should connect, yeah?

[laughter]

David: But, on the other wrist, I’ve got the Facebook wristband. So, also pimping the Facebook. But it’s locked on; can’t get that off.

[laughter]

[applause]

Leslie: Har har.

David: Yeah. So, two interesting facts. I technically have five names, and I’m the only Fajuen that I know of.

Chris: Fajuen?

Joseph Smarr: Wow. So I’m Joseph Smarr, from Plaxo. And I’ve been working on trying to help open up the social Web, by helping you stitch together all the content you’re sharing on these different sites and helping find your friends. And in my spare time, I like to play electric guitar, as many of you may have found out through Valleywag.

Jeremy: Okay. Good. I think Chris is winning so far. He’s leading with the points.

Chris: Sweet.

Jeremy: All right. Down to brass tacks. We just got a show of hands there that people are a bit annoyed, it seems, with having to re-enter this data and having to reconnect with all these people on all these different services. But, let’s face it: this is a gathering of geeks here at South by Southwest. Is this even an issue for most folks? Are we the canaries in the coal mine? Who wants to take this one?

Leslie: Okay, I’m going to jump on that right away. I feel that this framing is actually taking away from this battle that’s being had. The idea that network fatigue is the reason that we need to connect all these networks? I don’t know. That’s such a small subsection of the people. There are so few people who have that issue; I actually think that you guys can be much more creative about your reasoning about why we need to connect our services.

I kind of see it that it’s not about network fatigue. It’s about this sort of burgeoning coalition of services, and making it easier for people to move between those services and pull what types of information they want, what kind of data from each service that they want, into the next service.

So it’s not necessarily even about friends lists. It’s about documents that I’ve created, photos that I’ve taken. And I just sort of don’t really think the framing is a positive way to get things done.

Joseph: Well, I do think we’re canaries in the coal mine, though, in the sense that I think what we’re seeing is that the whole Web is becoming sort of socially aware and socially enabled, and that we’re finding that it’s amazing the number of services that get better when they know who you know. Right?

So, if you think about the evolution of Web 2.0, you think about the evolution of social networks and Facebook platform and all of that, there’s all these things about: photos work better when they’re social; bookmarks work better when they’re social; travel works better when it’s social. And if you think about it, almost everything could be made better when it’s social.

But the problem is if you think about the explosion of the Web itself, once you sort of had those open protocols, everybody could just sort of build a great Website. But when you want to build a new sort of social experience, you don’t just need the protocols; you also need that data of who am I and who I know. And right now, because that data’s not flowing, people have to start over every time. And that’s where that fatigue is coming on.

And that is a universal problem, right? I mean, if you think about when we all came to this conference, those of us who knew each other beforehand didn’t have to re-meet each other at this conference, right? We already had that past relationship. And that’s why we’re able to build on our experiences over time. And right now, every Website acts like you’ve never used another Website before in your life. And that, to me, is a universal problem, and a universal opportunity to make everybody use all of this stuff a lot more.

David: Yeah. I think, combining what Leslie said and Joseph said, in terms of that idea that it’s not just about the people that you know and wanting to have portability in terms of who you’re interacting with, but that all of the things that you’re doing because of Web 2.0, of creating technologies, of community collaboration, that’s what really requires the social features.

And so far, it’s been really poor user experience and poor starting point of, you sign up for a service, and it starts out with: “Who do you know?” And being able to sort of lower that barrier—which I think is why the Facebook platform’s been so successful—of, all of a sudden, you create a new application, there are many people who can go and use it quickly, is important. But it’s also important to remember that the Web is really successful because it’s not siloed.

Chris: I would also add to that, one of the important ways to think about this—and David’s sort of getting to this point a little bit—is what you can take for granted when you’re building Web applications. And I think, more and more, people are taking the social component for granted.

But the experience is, first of all, not universal, and secondly, it has a lot of friction to it. So, insomuch as there’s a great opportunity to reduce friction in using a new application, that’s extremely important.

And so it’s not just about not finding your friends over and over again and having that process be really crappy, because it isn’t that you want all the same friends on all the different services that you use, but that when you actually want to reach out and touch someone, it should be as easy as that—as opposed to having to go through a whole process in getting them to be invited into the service which, we were sort of saying, if I even have 10 friends that I commonly invite to new services, and let’s say I use 50 services, if I’m berating them with 50 new invites every five days, they’re probably not going to be my friend for that much longer. So it’s also about the imposition that you’re putting on other people, the more services you’re using.

For example, I probably have 364 application invites on Facebook. I mean, it’s kind of stupid. So figuring out a way of improving that process, for me, so that I can play Scrabulous without having to worry about going through this arduous process, I think, is also important.

Leslie: Yeah. I think you actually kind of hit on it right there. It’s about being able to move between the services in sort of a free-flowing manner, because right now, everything is siloed around—every service has its own gateway. And so, if we can knock down those gateways, then that means that all these services can actually start working together, and we can have that kind of puzzle-piece, snap-together Web that we keep talking about.

Chris: Or even better, it’s sort of more about competition and choice, being able to, let’s say, have most of my friends really like Facebook, but then I have a number of friends who are on MySpace. Being able to message them between networks is sort of something that’s really important. I mean, email accomplished this a long time ago; you can go from server to server. Well, why can’t you do the same thing with social networks? It’s stupid. But that’s the way it is.

Joseph: And I think what you’re all hearing here is this is not about my ability to abandon one social network entirely and go somewhere else. It’s much more about me being able to have these different tools work together so that I can use them more so that the friction comes down so that more users can take advantage of them. Right? It’s about making each of these apps part of a rich social ecosystem, where hopefully the pie should get a lot bigger and everyone should be able to win. And I think that’s something everybody can get behind.

David: And from a future perspective, I think Facebook NewsFeed was probably one of the really successful other ways to frame this question of, you’re really interested in seeing what are your friends doing online. And this has shown to be really true by the number of startups right now who are going and trying to compete in this space. You had Socialthing launch yesterday, I think, and it dominated Twitter this morning.

And so I think that feature, even though it’s not necessarily the problem of “My data is all in one place,” or “My friends are in one place,” or “It’s hard to get started,” but allowing that feature of just the philosophy that people exist in multiple places around the Web, and are sharing things and creating things all around the Web, is really important.

Jeremy: So, what I’m hearing here is it’s all about reducing friction. So, social network portability is essentially the Vaseline of the World Wide Web.

[laughter]

Jeremy: Which is good.

Chris: You said it first.

Jeremy: But we are still the uber-geeks. And even Mark Zuckerberg, just today, in an interview at ReadWriteWeb, was talking about throwing open his API, and nobody’s particularly interested in using this feature. As he said, “We threw an API and nobody came.” So maybe we are still a bit niche.

Should the reasons for doing this be more business-related, rather than it’s good for the future, it’s going to build the next stage of the Web? Are there business benefits to opening up? Or is it the opposite, that, from a business perspective, you actually want to keep people locked and you want to keep people closed in?

Joseph: We’ve certainly seen a lot of positive business benefits from it because, like I said, as much excitement as there’s been with any of these services, you just think about it: we are just at the very beginning. I mean, most people out there are not sharing rich content with each other.

Think about how many people you know who have a digital camera but you’re not seeing their photos. Think about how many people are doing interesting things that you’re not hearing about, right? Think about how many of your parents are communicating with you in that kind of way, or your extended family.

And so, when you unlock barriers and you make things interoperate, everybody starts using everything a lot more. And we’ve certainly seen that in Plaxo and Pulse; everybody’s creating stuff and sharing it, from their blogs and their photos and everything else, right? And just by being able to go in and sync your address book and find all the people who are sharing this information and connect you to me, even though ultimately you’re going out to the other sites, just that ability to sort of reduce friction has been incredibly good for our business.

And I think for all the other businesses, too, we’re driving them traffic, we’re getting more users. So I certainly don’t think we’re at the stage yet where there’s a zero-sum game, where people have to fight over a piece of the pie, because the pie’s just going to get a lot bigger.

Jeremy: Now, you’re talking specifically about address books. You’re talking about getting people’s information out of their address books so they can move it around from service to service. Is that not kind of a special case? Because when we talk about data wanting to be free, we’re usually talking about “my photographs.” I want my photographs to be mine, even if I’m storing them on Flickr, “my music”, whatever my content is.

But the contact details of my friends, do I own that? I own the fact that I am friends with a person, but do I own their email address now? Does that give me the right to put email addresses around? So address book portability is—I don’t know.

David: And that was something that I think was really the crux of the issue with the Facebook-Scoble-Plaxo…

Jeremy: Debacle.

David: …debacle—thank you—earlier this year, where it was sort of like, what was that fine line there between the information that Plaxo and Scoble were taking out of Facebook, of “Did that belong to Scoble?” Was going and taking that step of having OCR images to get email addresses actually beyond what was socially acceptable or not?

Chris: That’s not even the point. I mean, I think the point there should really be about whether or not you have the ability to contact someone when you want to contact them. And I think that the whole matter was confused by data geeks who care about data and not so much about people who care about people who care about solving real problems or problems in the while.

So, if I’m out and about, and I have this person in my phone, and I want to contact them, I should have some mechanism to do so, whether it’s by their phone number or their email or whatever—it shouldn’t really matter so much as if they’ve given me permission to contact them.

And I think that we’ve been architecting our thinking about this from a very sort of protocol and data perspective, as opposed to thinking about, “Well, what are we actually doing for people?” Why do people want to get this data out of the networks, when the reality is they want to contact someone, they want to talk to someone, they want to share something with them?

Leslie: I think that’s a great framing of it, actually, because the point isn’t really how; it’s what they want to do. So, in this case, there’s got to be a way. For example, if you don’t have the right to have someone’s email address, but these sites are linked, why can’t you, from the technical side, link up the sites so that I never actually see the email address that I’m using but I know that my message gets through? Now, I don’t have ownership of that email address, but I still get what I want.

David: Focusing on the feature, like Chris said, I think is really important. We put sort of a life-streaming concept, called ActionStreams, into Movable Type. And instead of going and focusing on the “Oh, by the way, bloggers, you’re also now adding XFN to all of your blogs and supporting Atom and things like that,” what we did was “Oh, you want to go and share with people that read your blog what you’re doing around the Web?” and focused on that, really, as the feature, building that feature. And now, as a side effect, all these people have XFN links to their accounts around the Web.

Joseph: Yeah, I totally agree with that. That was the thing to start with. It’s like how do you find what your friends are doing, and how do you start getting connected to that, and then how do you start wanting to share yourself?

And when these technologies work well, you don’t even realize that you’re using them, right? You see Yahoo deploying OpenID for all their users, where, when you come to Plaxo, there’s a button that says, “Sign in with my Yahoo ID.” You don’t even know that you’re using OpenID; you just know, “Hey, I already have a Yahoo account. I shouldn’t have to create a new account from scratch.” Those are those signs of progress that real users can get.

Jeremy: Yes. So this is an interesting point. And we’re talking about framing the discussion. If we get bogged down in techy terms, we’re going to put people off. It’s not so much fun. And when we talk about portable social networks, it’s kind of already a kind of techy term. And there’s another term out there that sounds even more off-putting, which is “the social graph.”

David: I’m sorry.

[laughter]

Jeremy: Does somebody want to defend that position? I don’t like that term. Anybody here want to say that they do?

Joseph: I just think we needed something that wasn’t “social network,” because we already think of those as like MySpace and Facebook.

Jeremy: What about “super-best-friends club”?

[laughter]

Joseph: I mean, ultimately, it just becomes a sign.

Leslie: I feel like the whole thing is, again, kind of strange, because the focus then is on…

Chris: Terminology.

Leslie: Well, terminology. And also, it’s really about people’s relationships. But the Web is way more than that. I mean, of course, when things are social, it makes it more fun, it makes it more interesting, there’s a lot more information that you can share and find. But there’s also just being able to move between services freely, whether or not that’s with your friends.

Jeremy: Okay. You keep saying “friends.” Now, this brings up an interesting point as well. Are they friends? Are they contacts? On Dopplr, they very specifically say, “You share trips with these people.” It says “your fellow travelers.” That’s an interesting term. Do we want to be using terms like “friends”? Are we really diluting the English language at that stage? The MySpace definition of friend is pretty broad. [laughs]

Joseph: Including Captain Morgan and what have you, right?

[laughter]

David: A few years ago, I worked on LiveJournal, and this was a huge problem we had, where users were friending each other. And it first started out in terms of how the site evolved, of just a small group of people using it, and they were their friends. But it was also, at the same time, pulling together, reading people’s content, trusting other people with your content. It was very hard, and the LiveJournal still hasn’t gotten away from the concept of friends.

Leslie: It’s hard once you’ve installed your system that way. Once you’ve trained people to think of it that way, it’s really hard to back out. So anyone that works with me knows that I’m incredibly adamant against using the word “friend.” And I think it’s really important to frame things up front in all sorts of interesting ways. So I really respect the way that Dopplr has done their work because they’re very careful about making sure that it’s around an action—so it’s a person that you do an action with, a person that you share a trip with, a person that you want to share photos with.

Joseph: And I think that speaks to another important point, which I think one of you alluded to earlier, which is, just because you want to be able to go to a new site and find who you know there, of course, it doesn’t mean you necessarily want to be friends with everybody on every site or share things with everybody on every site, right?

So, just like we don’t want people to think that to make your data portable, it has to be public, we also want people to able to think that just because you can go find people somewhere doesn’t mean you’re still not going to choose the type of relationship that’s appropriate…

Jeremy: That’s very true. I mean, I have friends on Flickr because I like their photography. But then they might want to friend me on Last.fm. But if they’ve got lousy taste in music, there’s no way I’m making them my friends.

Joseph: [laughs]

Jeremy: Now, we’re going to get on to the technologies required, because the building blocks are there today. But first of all, it seems like, is this not all a solved problem? Because, Joseph, you talking about moving your data from one address book to another service, and it seems like we can actually do that, because I sign up to new services and it says, “Hey, do you use Gmail? Do you use Yahoo Mail? Do you use Hotmail? Great. Well, just give me your user name and your password for that third-party service, and away we go.”

Chris: Well, they are trustworthy…

Joseph: That seems like a loaded question.

Jeremy: Yeah.

[laughter]

Jeremy: Okay. To give some background, I did bring this issue up at the Social Graph Foo Camp, and named and shamed a lot of services in this regard, because I think it’s pretty bad personally because it’s teaching users how to be phished, and that is wrong.

Joseph: And just beyond that, because that sort of issue, I think, we’ll hear about with OpenID and OAuth and things like that addressing it. But I think the other thing that’s really important for people to realize is that that kind of one-time import is really not capturing the sort of dynamic nature of people’s relationships.

I mean, just in South by Southwest, I have met a whole bunch of new great people, right? And I think any site that you slurp down your Gmail address book and try to find people: A. it’s only finding people by email address, whereas increasingly we know people, not be email address but through other social network. So, maybe I know your Twitter name maybe I know your Facebook ID or whatev

Monkeyformats

Microformats + Greasemonkey = Monkeyformats. Is there a site that you wish used microformats? Write a userscript and share it here.