More thoughts on portable social networks

I’m not the only one thinking about portable social networks:

There are some good comments on these posts ‘though I keep noticing the trend for things to get too complex too quickly. Tom Carden mentions FOAF but I have a number of issues with that:

  1. Publishing XML is hard, certainly harder than publishing HTML.
  2. Out of sight is out of mind. I’ve actually got a FOAF file here at adactio but I haven’t updated it in years. Invisible metadata rots.

A lot of people are talking about the need for some kind of centralised service (ala Gravatar) for storing a social network. But surely the last thing we need is yet another walled garden or roach motel?

I’d much prefer a distributed solution and, frankly, I wish Gravatar had gone down that route given its often slugglish ways. I realise that a centralised service is needed for people who don’t have their own URL but it should, in my opinion, be second choice rather than default.

In any case, I think we may be barking up the wrong tree with all this talk of needing something new. Personally, I don’t think the solution need be complicated it all. It’s within reach right now and it doesn’t require the creation of any new service.

Suppose, just suppose, that…

… were marked up with XFN (update: or more importantly, hCard—see below). Now all I have to do is provide one of those URLs to the next social networking site I join.

Far fetched? Two of the sites I listed are already walking the walk. All that’s needed is for the sign-up form on the next fadsite I join to at least include the option of importing a buddy list by pointing to a URL.

Sure, it won’t work perfectly. People might have different names from site to site. But that’s okay. It’ll work good enough. It will probably get 80% of my contacts imported. And that’s a lot better than the current count of zero.

We don’t need yet another centralised service. The information is already out there, it just needs to be explicitly marked up.

Once you populate a network on one site, that information should be easily portable to another site. That’s doable. It isn’t even that hard: all it requires is the addition of a few rel attributes and possibly some hCard encoding.

Let’s not go chasing a complicated solution when a simpler one will do.

So here’s my plea—nay, my demand—to the next Web X.X social networking doohickey that wants me to join up:

  1. Give me a simple input field for entering a URL that lists my contacts.
  2. Parse that URL for people and relationships.
  3. Voila! I’ve added a bunch of friends. I may repeat from step one with a different URL.
  4. Markup my contacts on your doohickey in an easily exportable way.

Who wants to get the ball rolling? Why can’t this become as ubiquitous as gradients, closed betas, giant text and wet-floor reflections?

For all the talk of social media and the strength of weak ties, there isn’t much action being taken to really try to “harness collective intelligence®”. Within the confines of their own walls, these Web X.X sites might be all about social this and social that, but I want to see more sites practice what they preach on a wider scale… the scale of the World Wide (semantic) Web.

Update

Following on from some comments and Twitter chat, I wanted to clarify a few points:

  1. Yes, social networks differ depending on context. That’s why I want the ability to point at more than one URL. If I join up to a new music site, I might want to point to my Last.fm contacts, but not my Flickr contacts. If I join a new site about food or drink, I’d probably want to point to my Cork’d drinking buddies, but not my Linkdin network. Or I might want to point to any combination thereof: Flickr + Twitter - Last.fm, for example.

  2. The issue of whether the people you’re adding even want to be your friend is a red herring. That’s an issue regardless of portability. I can quite easily add people as my friends on Flickr who don’t want to reciprocate. The same goes for Twitter. Portability will allow me to add friends en masse but it won’t ever automatically add me as a friend to the people I’m importing: that’s still up to them.

  3. No, this won’t move 100% of contacts from network to network. But it will move a lot. My user name is adactio on Flickr, Last.fm, Twitter, Upcoming, Technorati and Cork’d. I suspect a lot of people use the same user name across sites. For sites that use real names, there’s an even greater chance of portability.

  4. None of this portability is irreversible, it’s just a shortcut. If I get false positives—people imported that I don’t want as contacts—I can just remove that relationship. Likewise if I fail to import some people automatically, I’ve still got the old-fashioned way of doing it by hand (which we all have to do now anyway).

  5. Forget about XFN for a minute. The important thing is that I’m pointing to a page and saying, “any people listed on this page are contacts I want to import.” Now, there is no <person> element in HTML so how does it know which strings are people? Well, we need some way of saying “this is a real name”, or “this is a nickname”. We have that already: class="fn" and class="nickname". These are properties of hCard. So I guess it’s hCard usage that really matters. That said, XFN can added an extra level of granularity: contact vs. friend, at least. But I stand corrected: the really important formatting issue here is marking up “who are the people on this page?” rather than “what are the relationships on this page?” The URL itself contains the information that everyone listed is a contact.

Just take a look at these URLs:

  • http://corkd.com/people/adactio/buddies/
  • http://flickr.com/people/adactio/contacts/
  • http://last.fm/user/adactio/friends/

A semantic consensus is already emerging across sites in URL structure:

http://site name/[people|user]/username/[buddies|contacts|friends]/

All that’s needed is to explicitly mark up any people on those pages. That’s easily done with hCard. All these sites have to do is edit a template. For extra relationship richness, XFN can help.

Have you published a response to this? :

Comments

Jeremy, I am in much much agreement. The only place I differ is on my friends list being fungible (identical) everywhere. I can think of one pairing where I would want two separate lists of friends, cork’d and last.fm because the tastes of friends do not transfer between wine and music for me. The friend taste clash and even for privacy reasons (would not want workplace friends knowing about a job search site activity).

This variance of friends and contacts would need a central broker or a smart scaleable address book. I have been looking at OpenID as a means to do this. I know this solution is in the open Microsoft infocard (yes, open), at least from what I understand.

I am personally seeing a need for an onion layered approach, for access to my ID, but a little more fine grained so to set up granular interest for my social network.

The key elements are ease of use, privacy, trust, and one solution (can be stored centrally, or I personally can house and control it).

# Posted by vanderwal on Thursday, November 23rd, 2006 at 2:28am

This is a fantastic approach to this problem. Even Gyford’s idea of groupings could be achieved by choosing which URL you use to import into the next site. I agree, when simple is good enough, complex is too complicated.

It’s great that you can import your friends through the use of XFN marked up pages, but how do you know your friends on one network also want to be your friend at another one? They should give permission for that, and how will that be facilitated without me entering all their individual email-addresses?

# Posted by Yme Bosma on Thursday, November 23rd, 2006 at 7:56am

Echoing I had a couple of days ago (http://flickr.com/photos/hicksdesign/298271647/#comment72157594378491021), I definitely agree this has potential. It’ll only take a couple of sites to start and the ‘standards aware’ few will follow suit. I can’t help wondering just how much microformats would explode in popularity if a site like Myspace were to do this (but the chances of them doing this are slim, given they can’t get valid best-practice markup right yet).

One nice possibility with this is that you could have mutual relationships automatically parsed (if a given friend’s individual’s URI contains XFN indicating they consider you a friend in return, then automatically add you to their own friends list within the site), which would help with things like twitter’s ‘only giving updates to friends’, for instance.

# Posted by Ben Darlow on Thursday, November 23rd, 2006 at 8:06am

orrite,

so lots of people talking about this at the moment. which is good :)

there is a flaw in the simple pointing at an xfn list model.

those buddies at your xfn url have to match with those people’s real signup details on the latest fadsite. people quite often use different email addresses or screen names. not always by choice, sometimes the one they wanted is already taken.

there needs to be something more than that in my opinion. it’s not hard to solve technically, but to implement would be near impossible.

it’s gonna be fun trying though :)

Jeremy - your update is superb and really deserves to be a post of its own.

My original feeling on the use case that I was putting forth was explicitly XFN related because I was thinking of the relationships as important: friend vs. contact etc. However, I think you’re bang on - the XFN is the added bonus, not the core, and the core is hCard semantics.

I love the way ideas come together. As I’ve said before, the back and forth is critical to solving the problems.

So social network X can find your list of buddies on flickr, but how does it link those flickr names back to its own accounts? When people sign up they’d have to add their flickr/last.fm/cork’d names/urls too. Perhaps thats where having your own url comes in, you link to your different profiles with a rel saying they are you. The new site can then follow them and find your contacts as well as remember who you are on their site and others. Or you just give the site all your urls.

If OpenID was more prevalent, it could easily be an used for this.

In the here and now, 43places|things|people asks for your Flickr screen name. I think this model (ask for what you want) could and should be more common.

One API call to Flickr and I can get all your contacts. If I can get you to authenticate, I can tell who’s a friend or family.

Now I just have to create an app to use this…

It would be amazing to see this theory implemented. I think the need is really there and there’s a lot of bright minds, like yourself, thinking out the logistics.

Great article, Jeremy. I’ve begun integrating microformats into my sites and I plan on implementing XFN as well. Your proposal makes sense as it takes what is already available and makes it portable. I hope someone takes up your challenge, it will be yet another example designers/developers can use to promote microformats and their value to colleagues and clients.