Loose notes from SXSW 2008 session Building Portable Social Networks with:
Jeremy Keith Clearleft Ltd
Chris Messina CEO, Citizen Agency
Leslie Chicoine Experience Designer, Get Satisfaction
Joseph Smarr Chief Platform Architect, Plaxo Inc
David Recordon Open Platforms Tech Lead, Six Apart Ltd
This topic has been fresh on our minds at the Berkeley J-School in our work providing guidance to news publications who are trying to focus more on community, and wondering whether to just tap into Facebook, use Ning, or create their own. The public is rapidly approaching SN overload. Are people really willing to create yet another SN profile? Will they able to re-engage their existing networks of friends? What about all of the data they’ve already stored in their existing SNs? Will BuddyPress help? OpenSocial? SocialThing? What are the technical and privacy issues we’re facing here? Is this problem solvable, or are we erecting a tower of babel?
Travel works better when it’s social. Bookmarks work better when they’re social, etc. But do non-geeks have the same “SN overflow” problem that geeks at this conference have?
Every web site acts like it’s the first / only web site you’ve ever used – you have to start over each time.
The web is successful because it’s not silo’d.
You should be able to reach out and interact with someone no matter where you are, without having to jump through hoops.
Email accomplished this a a long time ago – you can go from server to server. SNs are facing a problem that was solved long ago (but there is no “protocol” – it’s different everywhere. )
SocialThing launched yesterday and dominated Twitter this morning.
We need vaseline on the world wide web.
Are there business benefits from opening up, or is there an incentive to stay closed?
Plaxo: Ability to reduce friction has been great for our own business.
Is the matter complicated by data geeks, who think from a protocol and data layer perspective.
Movable Type has “Action Streams” – rather than have users try and work with multiple protocols, discovery just works.
Of course we also have a problem with too many friends – the FaceBook def. of friends is too broad. Do you want portability amongst 500 friends?
To make your data portable doesn’t mean it needs to be public.
To start data exchange … just give so and so your username and password and away we go… is this teaching users how to be phished?
One-time import mechanisms don’t get to the heart of the matter. It’s just one little corner, but these apps need to interact in a consistent and persistent way.
Google has just released an open API. Which means there’s no more excuse for a 3rd party site to ask for your username and password.
Building blocks that exist today:
GetSatisfaction moved to h-card, which is pretty straightforward. Taking public info and pre-populating fields on new services. Make it like magic. You shouldn’t be saying “h-card” to your users – that means nothing to them. Instead say “Rather than create another profile, why not use the one you already have?” We’re not just sharing data between two sites, but through a network of sites – there’s going to be a trail. How to keep it in sync? And in the future it’s going to get more complicated.
Also: Give me the option to NOT pull people with me to the next site.
Don’t treat your users like they’re dumb. They won’t understand these technologies but that doesn’t mean they’re dumb. Explain things to people, but explain what it’s going to DO for them, not how it works.
Also: When pulling data over, how do you know the person you’re pulling in is the real or the same Scot Hacker? We could have big synchronization problems.
Google has a social graph API which can be tapped for this.
XFN is a format for describing your friend relationships. XFN+HCARD = beginnings of an open standards system for this stuff. FOAF (friend of a friend) – LiveJournal and others support that. What is the difference between FOAF and XFN?
Every single Yahoo and AOL user has OpenID. And HCARD is a perfect format for profile portability — assuming you want to make all of your profile info public. But OpenID can also help in making some of your profile data private.
O-Auth (OpenAuth): Not about authentication but about authorization – very different. OpenID has no way of dealing with APIs. To continue promoting OpenID, the auth problem had to be solved. The initial spec has been released. oauth.net/code – they’ve released a lot of libraries already.
FireEagle – uses O-Auth. FE is a way of storing your location and spreading it around.
OpenSocial is using some of OAuth. Pownce, Magnolia, Satisfaction…. it’s coming along quickly.
EFF guy: “Everything you know is wrong.” If it’s easy to give away your information, you’re creating an interface where it’s easy to give info away to other applications. On Facebook, with one checkbox I can give some 3rd party app all my private info. Putting vaseline on the web may create some huge privacy problems. Contra: yes, but we’re trying to make things better with OAuth. Right now people are spreading their credentials around like confetti. EFF: No, you’re just making more confetti. We do not want just Google and just Facebook and just Myspace deciding how this stuff is going to be done. We need to make sure these protocols are open source and inspectable. We’re talking about how these technologies are going to make things easier; but chances are we’re going to open up a whirlpool of issues and complexities, both technical and from a privacy perspective.
All of this is going to hurt for a while.
Focusing just on the technology of this problem is completely the wrong approach. This has to be really large scale iterative design.
We’re effectively creating a major component of the “web as operating system.”