You are reading an archived post from the first version of my blog. I've started fresh, and the new design and content is now at boxofchocolates.ca

Solving problems with social networking

November 21, 2006

I’m tired of re-stating my intentions with the same person on every social networking site I join. For example: I have met Jeremy Keith. He is my friend. He is a colleague and co-worker based on our conference and WaSP involvement.

This is always the same – whether I’m using LinkedIn, the d.construct backnetwork, Web Connections, defining my flickr contacts, or the new craze – Twitter.

Surely technology can solve this problem for us? I delivered the closing keynote on Day 1 of Web Directions South in Sydney, Australia earlier this year, and in that talk, I discussed something that Jeremy mentions this in his recent post about Twitter.

Here’s what I want: when I go to the latest social networking fadsite, I want it to ask for my URL. Then it can go off and fetch my hCard and XFN list. A pre-filled form for my details and a pre-filled list of potential contacts can then be presented to me.

Here is what I suggested in my keynote at Web Directions – I throw it out there as an idea, or the seed of an idea that will maybe spark someone to build it. I haven’t had the time to think it through completely, but what about a microformat for XFN relationships?


<dl class=”XFN”>
	<dt>Jeremy Keith</dt>
	<dd class=”rel”>met</dd>
	<dd class=”rel”>friend</dd>
	<dd class=”rel”>colleague</dd>
</dl>

The premise is simple: save time setting up your account on the new fadsite so you can get straight to wasting time with that new fadsite.

Caveats

There are always caveats. Here’s some that I can think of:

  • We’d need to identify people via email address. The email may not always match, and I don’t always use the same email address to sign up for different services.
  • I might not know the person’s email address – a LinkedIn connection might come through a mutual friend without either of us knowing each other’s contact details (though presumably we’d be able to get them)
  • The structure of a definition list relies on order to specify name-value pairs as there is no container for each defined item, so it would be a bit more of a pain to parse
  • The ramifications of what a “friend” can do on one site versus another may be significant. For example, friends on flickr get to see private photos whereas contacts don’t. Friends on Twitter get to see all my messages, whereas people that aren’t friends might not. Any settings that are automatically created based on my XFN list need to be spelled out for people, and we need the ability to arbitrarily override those settings.
  • What about security? do we need to protect these files with encryption?
  • If I add a new person in any given service, I need a way to easily export that so that I can add it to my global list

Getting the ball rolling

I’m sure there is someone out there that can do this. I think it will only be a matter of time before someone tries it. At least I hope so, because when I sign up for the next social networking site, I really want that initial barrier removed, so I can get right down to wasting time.

Technorati Tags: , , , , ,

31 Responses

Comment by Ben Ward — Nov 22 2006 @ 5:43 am

I was describing something very similar to a friend yesterday. It’s the OpenID + hCard + XFN dream ticket.

The way I see it, in practice you can initially search for all the XFN URLs in the existing user database. If you can’t find them, then you can load the URL and look for an hCard (possibly finding an email address, or other identifiable info that can be database matched). Any leftover, unmatched email addresses can be presented to you as ‘offer to send invites to these people’.

Of course, technically XFN is already a Microformat (it’s certainly been taken under that banner). I find the idea of your expanded rel values very interesting though, certainly there’s benefit in exposing that information in content, and would be nicely flexible. Are you planning to post this the way of the Microformats-Discuss mailing list? If not I’ll pop some attention towards your post in a little bit.

One thing that I’d like to see solved as part of this though, is the ability to spread things over multiple pages. Because at the moment, if I enter my profile URL in a page, such incredible parsing can only look for information on the same page. Some sort of @rel=friends link to identify my ‘Friends Page’ would do. That could be deployed on existing social networks too.

I’m in love with the possibilities.

Comment by feather — Nov 22 2006 @ 9:16 am

Some sort of @rel=friends link to identify my ‘Friends Page’ would do. That could be deployed on existing social networks too

That’s the kind of thing I was thinking in the first place -rather than having that information dispersed over several pages, having one main page that contains nothing but this XFN data – kind of like an OPML file is a dedicated purpose page that can be reused.

We could then encode this in the head of our document:

<link rel="XFN" href="/mycontacts.html" title="My XFN Contacts">

That way when we sign up, the first step is to provide your URL and the service can go and find your dedicated XFN file.

That was my thought, anyway :)

Comment by Steffen Mazanek — Nov 22 2006 @ 2:13 pm

Some thoughts on your post in my blog:
microformats as input for sn-sites

Comment by Dylan — Nov 22 2006 @ 3:31 pm

I had just begun thinking about this recently after reading Jon Hicks’ displeasure with having to re-add his contacts over and over again to various social networking sites.

Of course, an XML based format would also do, allowing for more specific semantics.

Someone needs to setup a centralised profile service (for people without access to their own server) which allows people to input contacts and other info, which would then be translated into the contact format and (hopefully) would then be used as a contact database for other web services. Of course, the problem is that this would require adoption by these third party web services.

I’m surprised this hasn’t been done before, or has it?

Comment by feather — Nov 22 2006 @ 3:38 pm

@Dylan:

Someone needs to setup a centralised profile service

Yes, someone does. It would essentially be the same as a Gravatar. But that has its own set of problems, doesn’t it?

Comment by gareth — Nov 22 2006 @ 6:02 pm

…rather than having that information dispersed over several pages, having one main page that contains nothing but this XFN data.

It might be possible to compile this page based on parsing a given site. Set a spider to work, spider the site, discover the XFN data and then create this hypothetical page/feed. One for the next time I cant sleep.

Comment by feather — Nov 22 2006 @ 6:10 pm

@Gareth:

It might be possible to compile this page based on parsing a given site

While it might be possible, i’m not sure I’d have links to all my contacts, even throughout my entire site. So any spidering would still need to be supplemented with other entry. Good thinking though – there are a lot of things that need to come together for this to work…

Comment by gareth — Nov 22 2006 @ 6:13 pm

While it might be possible, i’m not sure I’d have links to all my contacts, even throughout my entire site

Fair point. I guess it would be more useful once you had that initial list. If you add a new contact in a new post, or new page, the parser could automatically update the feed.

Comment by Jeremy Keith — Nov 22 2006 @ 6:55 pm

I don’t think there’s any need for a definition with a separate [dd class="rel"] for each relationship. That can be encoded just fine in a regular rel attribute on a hyperlink:

{a rel=”friend met colleague” href=”http://v1.boxofchocolates.ca/”}Derek Featherstone{/a}

Each link could be in a list item in an unordered list… or not; it doesn’t really matter.

Point is: there’s no need to come up with another format for this. XFN (which *is* a microformat) does it already.

Dylan, I don’t know what extra information XML would give in this case. In fact, this has already been tried with RDF dialect for describing relationships”>FOAF. The problem is that, while anyone can publish a little HTML pretty easily, publishing an XML file is a lot trickier. I think choosing XML over HTML would just raise the barrier to entry.

Personally, I definitely *wouldn’t* want a centralised service: just look at how slow Gravatar gets. If anything, I’d also like to see a decentralised version of Gravatar… something along the lines of the favicon.ico link:

{link rel=”gravatar” href=”/path/to/gravatar/img” /}

Comment by Aesqe — Nov 22 2006 @ 7:05 pm

I might be totally off the right track here, but what about 30boxes? They seem to be moving in the “centralized profile service” direction. Or, it’s just too late here and I’m making no sense :)

Comment by Dylan — Nov 22 2006 @ 7:24 pm

But what about people who don’t have access to their own web server?

Comment by feather — Nov 22 2006 @ 7:57 pm

I don’t think there’s any need for a definition with a separate [dd class=”rel”] for each relationship. That can be encoded just fine in a regular rel attribute on a hyperlink:

{a rel=”friend met colleague” href=”http://v1.boxofchocolates.ca/”}Derek Featherstone{/a}

I think the difference in what I was thinking is that I hadn’t viewed this as a publicly consumable file, in the sense that I saw its only purpose was to declare these relationships for fadsites. With that, a real hyperlink isn’t needed. However, I can see that it would be easy enough to repurpose a generic file and the hyperlinks could be useful.

In fact, the hyperlink works for anybody that has their own blog as their “unique identifier” in place of email. I suppose that’s the whole point of rel="me" in the first place.

So, what would we do for people that don’t have their own site/blog? Would they be able to use, for example, their LinkedIn profile as their “warehouse” for their connection data? That would require LinkedIn to provide some extra mechanisms, but that would be a possibility. Maybe if we had a solid system in place, it could be a fully distributed system where your blog, or your profile on any one of a number of sites could be the warehouse.

Comment by Jeremy Keith — Nov 22 2006 @ 7:59 pm

Well, I think a third-party service can then work: all it would need to do is offer you your own page (just like your own myspace page, Flickr page, Twitter page, etc.) and give you a nice wizard form for adding friends. But this centralised solution would work no differently to doing the same thing on your own site (if you have one).

So, if you have your own site, that’s the URL you give when signing up to the latest fadsite. If not, give the URL of “your” page on the centralised service.

But I strongly feel that the centralised service shouldn’t be the only option. I really wish that Gravatar had gone down the route of distributed first, centralised second.

Comment by feather — Nov 22 2006 @ 8:07 pm

But I strongly feel that the centralised service shouldn’t be the only option

Agree completely. My first choice would be to use my blog as my central storehouse, and I’d point all of my services there. My second choice would be a third party service, though others might prefer to make a third party service their first choice.

No matter where it is stored though, I think we’d need to sort out some means of securing the data – on my blog I might protect it with a simple .htaccess file. Third party services could provide the data through an API with a token perhaps.

Comment by Dylan — Nov 22 2006 @ 8:49 pm

Yeah, of course the third party service should just be a (lesser) alternative to a personally hosted solution. Security is an interesting issue I hadn’t thought of, but shouldn’t be too hard to work out, as you’ve said.

@Aesqe:

While 30boxes aggregates different services you’re part of and allows you to essentially track your life in their service, we’re talking about something which can provide an easy way to add contacts you have made in the past to new social web services you wish to join. Centralization isn’t a key point here, since it would actually be somewhat detrimental (as it often is). More of a unified data format is what we’re after.

Comment by Glenn Jones — Nov 23 2006 @ 7:53 am

We are all fed up with social networking as endless one-way streets for data. What is needed are portable social networks. As the designer of one of these “fad-sites” I have spent a great deal of time thinking about this issue.

As the debate is so lively at the moment, I thought it would be good to outline the concept I am working on for backnetwork.

http://www.glennjones.net/Post/820/Mircoformatsandportablesocialnetwork.htm

If social networks are willing to provide contact and relationship information in mircoformats, I can see a practical solution to this issue.

It is all down to the power of the rel=”me”. With this XFN attribute you can provide a spider with all it needs to find profile information.

Comment by feather — Nov 23 2006 @ 8:29 am

@Glenn: Thanks for stopping by! Hope you are well…

As the designer of one of these “fad-sites” I have spent a great deal of time thinking about this issue.

Actually – I don’t classify the backnetwork as a fad-site by any stretch of the imagination, and didn’t mean to imply that. The fad-site comment I mostly directed at Twitter, I think, and even then it may not be the best descriptor. Didn’t mean to offend – and apologies if I did.

t is all down to the power of the rel=”me”. With this XFN attribute you can provide a spider with all it needs to find profile information.

I have to admit it wasn’t until going through the comments here and responding to them that I realized rel="me" can and will be so powerful. We tend to think of the email as the unique identifier for a person, but with multiple emails, we run into issues. Rel=”me” might be better positioned to solve that problem. I will go and check out your post now… Looking forward to it!

Comment by Glenn Jones — Nov 23 2006 @ 9:56 am

@ Derek: Thanks for asking I am doing well.

No offence was taken with the “fad-sites” label :-), did not really think it was meant to describe backnetwork.

Comment by Gavin Jacobi — Nov 23 2006 @ 7:45 pm

Hi Derek – it was good to see you back in the “Great Southern Land”!

Maybe this issue has been addressed better elsewhere already but I see more problems with social issues than technical ones (there will always be a technical solution…)

# The ramifications of what a “friend” can do on one site versus another may be significant. For example, friends on flickr get to see private photos whereas contacts don’t. Friends on Twitter get to see all my messages, whereas people that aren’t friends might not. Any settings that are automatically created based on my XFN list need to be spelled out for people, and we need the ability to arbitrarily override those settings.
# What about security? do we need to protect these files with encryption?

I know this is common for any social networking system but there were grumblings after WD06 about what is a friend, acquaintance, colleague, etc. Some people were a bit unhappy about how others classified them on connections.webdirections. Language is a funny thing that gets really messy when you start getting into the territory of emotions and relationships. Really messy when coupled with access to information.

Security. Hmm. I had a bit of a peak behind what my spam filters were blocking and noticed a significant rise after WD06. Maybe just a coincidence but it looked like it was being skimmed for info (no surprise there really) and I was reminded of Molly’s post about personal information on the web.

Comment by Tim Lucas — Nov 23 2006 @ 8:09 pm

Interestingly Cam and I had considered OpenID and hCard import during the signup processs, but not really importing your XFN. I did give it a quick thought but put it in the too hard basket… probably a little too soon.

With connections it was less about just pumping in your contacts as it was exploring the other delegates and finding those you know and discovering some you don’t. If you were able to just pump in your XFN I wonder how that would have changed the usage.

I agree though, we definitely need a way to port the information. The rel=”me” looks like it could get us some of the way, but it’s a pretty heavy implementation if you have to spider a bunch of sites. Libraries and a site which could provide an API to do this for you would at least make life easier.

@Gobi: so you were getting more spammers to your site? I’ve noticed that a Connections profile page is often the number 1 hit for Google for that person’s name… and then the profile can link off to a site… so it could be playing some part in helping spammers get to you. I think some privacy granularity is definitely in order if there’s a v2… the idea of being able to expose specific hcard fields for only certain types of users (friends, acquaintances, etc)

Comment by Gavin Jacobi — Nov 23 2006 @ 8:38 pm

@Tim
The spam increase was just an observation and it could have been a coincidence—take it with a grain of salt.
I personally thought connections was a great success!
It is always a good thing to let the user decide on the level of openness of their information.
Granularity sounds like a good idea, possibly even a veto option for things like friend, lover, crush, etc. That gives someone the option of saying “actually you are not my friend, I just met you”. That could be seen as rude but it also might cut down on name-droppers and… creeps.

Comment by Steve Ganz — Nov 29 2006 @ 12:01 pm

@Derek: LinkedIn already marks up a user’s Connections with hCard and it shouldn’t be too difficult to add XFN support. I start work there tomorrow (you heard it here first) and you can bet that it’s already on my to-do list. :-)

Comment by Dan Libby — Jan 30 2007 @ 5:55 pm

Hi, I’m a bit late to the party. But I’ve recently added RDF dialect for describing relationships”>foaf/hcard import capability to Videntity.org (an OpenID server and social network), including the ability to import RDF dialect for describing relationships”>foaf relationships. Here is a write-up for anyone interested in such things.

I would be interested in standard ways to:

1) Identity which hcard in a page represents “MY” hcard, as opposed to someone leaving a comment, etc. Right now I just check which one has the most attributes.

2) Use XFN in correlation with hcard to specify my relationship with the hcard holder. This is basically a superset of the first point.

cheers!

Comment by Dan Libby — Jan 30 2007 @ 5:59 pm

Derek,

I’ve noticed that LinkedIn profiles are not visible unless one is logged in. This renders the XFN/HCard markup inaccessible to most non-browser agents. Do you know if there is there a backdoor or any plans to change this?

Comment by Steve Ganz — Jan 30 2007 @ 7:40 pm

@Dan, LinkedIn’s Public Profiles (which are now marked up in hResume) are visible to anyone at anytime; you don’t need to be logged in to view them.

You are probably referring to Connections. To view those, you do need to be logged in. The good news is that we’re currently exploring API’s that will ultimately make your network information more useful to you in a wide variety of ways.

Comment by Dan Libby — Jan 30 2007 @ 9:33 pm

Steve, I see now. I just needed to edit my linked in profile to find (and modify, nice!) the public URL, and then make full details public.

At that point, I was able to import some basic settings into Videntity. Yeah!

I noticed a couple things:

1) The country was marked up with the “locality” identifier instead of “country-name” (I think). So Videntity thought my country is a city.

2) It would be really great if the connections were available in XFN links. Just a name and a link to the public profile is all that’s needed. Could even be in a hidden div. Of course, I understand there may be privacy issues…

Comment by Steve Ganz — Jan 30 2007 @ 10:38 pm

@Dan, glad to hear that worked out for you.

1) It looks like you uncovered a bug that occurs when the user is outside of the USA. Thanks for catching that. I’m checking in the fix as I type.

2) While logged in, click on the My Contacts tab and you’ll notice that your Connections are now marked up with rel=”contact”. Obviously, this has limited value right now, but I am thinking a lot about how we can make this much more useful.

Comment by Dan Libby — Jan 31 2007 @ 1:32 pm

That’s excellent Steve. Feel free to use the import profile feature of Videntity.org for testing if you like.

btw, I’d like to commend you on your quick and proactive response. I know this isn’t the proper way to file a bug report or feature request and that the relevant code is likely not even your responsibility. :)

Comment by Dan Libby — Jan 31 2007 @ 1:34 pm

oh, I forgot to mention that Videntity.org is now able to import embedded XFN relations, in addition to hcard and RDF dialect for describing relationships”>foaf. link

Comment by Afternoon — Feb 08 2007 @ 6:26 am

I’m really excited to see this idea gathering steam as I think it’s been in the back of a lot of people’s minds for a while.

The intermediate problem is how to aggregate the identities we already have and recover all the content we have created. Once we’ve done that an XFN or RDF dialect for describing relationships”>FOAF friendship edge will be much more useful, my OpenID will be the key to my blog, my Flickr photos, my Twitter twitterings, etc.

The great white hope is that all the sites we use will adopt OpenID this year and that’s looking more likely with Microsoft’s announcement yesterday and Yahoo!’s umming and ahhing. There are other projects such as Simon Willison’s idproxy.net, which are providing some identity glue.

The developers amongst us are building our own DLA to reclaim our data, but I expect to see some of the OpenID providers morphing into DLA services this year. Backwards-compatible OpenID!

Comment by Afternoon — Feb 08 2007 @ 6:36 am

Back on topic (sorry!), it would be lovely if the big social networks (MySpace, Bebo, LinkedIn, FaceBook, Twitter) exported our friends lists as XFN for us, although it’s very difficult to see this happening in the case of MySpace at least :-).

While I like the idea of a central XFN provider, I much prefer an OpenID-like system of distributed providers, where I can just move my friends list to another provider in the drop of a hat. Of course, these kind of value-add services is how the more business-minded OpenID providers will look to do lock in, which negates the portability of my ID somewhat.