This past weekend I attended the O’Reilly Social Graph FOO Camp and got to meet a bunch of folks who I’ve only “known” via their blogs or news stories about them. My favorite moment was talking to Mark Zuckerberg about stuff I think is wrong with Facebook and he stops for a second while I’m telling hin the story of naked pictures in my Facebook news feed then says “Dare? I read your blog”. Besides that my favorite part of the experience was learning new things from folks with different perspectives and technical backgrounds from me. Whether it was hearing different perspectives on the social graph problem from folks like Joseph Smarr and Blaine Cook, getting schooled on the various real-world issues around using OpenID/OAuth in practice from John Panzer and Eran Hammer-Lahav or getting to ask getting to Q&A Brad Fitzpatrick about the Google Social Graph API, it was a great learning experience all around.

There have been some ideas tumbling around in my head all week and I wanted to wait a few days before blogging to make sure I’d let the ideas fully marinate. Below are a few of the more important ideas I took away from the conference.

Social Network Discovery vs. Social Graph Portability

One of the most startling realizations I made during the conference is a lot of my assumptions about why developers of social applications are interested in what has been mistakenly called “social graph portability” were incorrect. I had assumed a lot of social networking sites that utilize the password anti-pattern to screen scrape a user’s Hotmail/Y! Mail/Gmail/Facebook address book were doing that as a way to get a list of the user’s friends to spam invite to join the service. However a lot of the folks I met at the SG FOO Camp made me realize how much of a bad idea this would be if they actually did that. Sending out a lot of spam would lead to negativity being associated with their service and brand (Plaxo is still dealing with a lot of the bad karma they generated from their spammy days).

Instead the way social applications often use the contacts from a person’s email address book is to satisfy the scenario in Brad Fitzpatrick’s blog post URLs are People, Too where he wrote

So you've just built a totally sweet new social app and you can't wait for people to start using it, but there's a problem: when people join they don't have any friends on your site. They're lonely, and the experience isn't good because they can't use the app with people they know.  

I then thought of my first time using Twitter and Facebook, and how I didn’t consider them of much use until I started interacting with people I already knew that used those services. More than once someone has told me, “I didn’t really get why people like Facebook until I got over a dozen friends on the site”.

So the issue isn’t really about “portability”. After all, my “social graph” of Hotmail or Gmail contacts isn’t very useful on Twitter if none of my friends use the service. Instead it is about “discovery”.

Why is this distinction important? Let’s go back to the complaint that Facebook doesn’t expose email addresses in it’s API. The site actually hides all contact information from their API which is understandable. However since email addresses are also the only global identifiers we can rely on for uniquely identifying users on the Web, they are useful as way of being able to figure out if Carnage4Life on Twitter is actually Dare Obasanjo on Facebook since you can just check if they are backed by the same email address.

I talked to both John Panzer and Brad Fitzpatrick about how we could bridge this gap and Brad pointed out something really obvious which he takes advantage of in the Google Social Graph API. We can just share email addresses using foaf:mbox_sha1sum (i.e. cryptographical one-way hashes of email addresses). That way we all have a shared globally unique identifier for a user but services don’t have to reveal their user’s email addresses.

I wonder how we can convince the folks working on the Facebook platform to consider adding this as one of the properties returned by Users.getInfo?

You Aren’t Really My Friend Even if Facebook Says We Are

In a post entitled A proposal: email to URL mapping Brad Fitzpatrick wrote

People have different identifiers, of different security, that they give out depending on how much they trust you. Examples might include:

  • Homepage URL (very public)
  • Email address (little bit more secret)
  • Mobile phone number (perhaps pretty secretive)

When I think back to Robert Scoble getting kicked off of Facebook for screen scraping his friends’s email addresses and dates of birth into Plaxo, I wonder how many of his Facebook friends are comfortable with their personal contact information including email addresses, cell phone numbers and home addresses being utilized by Robert in this manner. A lot of people argued at SG FOO Camp that “If you’ve already agreed to share your contact info with me, why should you care whether I write it down on paper or download it into some social networking site?”.

That’s an interesting question.

I realized that one of my answers is that I actually don’t even want to share this info with the majority of the people in my Facebook friends list in the first place [as Brad points out]. The problem is that Facebook makes this a somewhat binary decision. Either I’m your “friend” and you get all my private personal details or I’ve faceslammed you by ignoring your friend request or only giving you access to my Limited Profile. I once tried to friend Andrew ‘Boz’ Bosworth (a former Microsoft employee who works at Facebook) and he told me he doesn’t accept friend requests from people he didn’t know personally so he ignored the friend request. I thought it was fucking rude even though objectively I realize it makes sense since it would mean I could view all his personal wall posts as well as his contact info. Funny enough, I always thought that it was a flaw in the site’s design that we had to have such an awkward social interaction.

I think the underlying problem again points to Facebook’s poor handling of multiple social contexts. In the real world, I separate my interactions with co-workers from that with my close friends or my family. For an application that wants to be the operating system underlying my social interactions, Facebook doesn’t do a good job of handling this fundamental reality of adult life.

Now playing: D12 - Revelation


 

Saturday, 09 February 2008 05:53:12 (GMT Standard Time, UTC+00:00)
Dare, Great post! It was great to spend some time with you at sgfoo, and it's great to see the evolution in your thinking on this important topic.

And here's a picture I took of you that I think is cool: http://www.flickr.com/photos/56624456@N00/2241509837/in/photostream/

John McCrea, plaxo
Saturday, 09 February 2008 07:37:59 (GMT Standard Time, UTC+00:00)
Hey Dare,

Nice post as usual :). You've got a lot of readers at FB, more than just Mark.

With regard to the sha1 hash, believe me, I've spent a lot of time thinking about doing it. The biggest problem I see with it is that it is pretty easy to reverse engineer an email address given the hash and the other information we expose about a user through the API - e.g. you could reasonably guess my email address as first initial, last name @ mycollege.edu or hotmail.com. You could try about 10-20 combinations and be able to find the correct one (and validate it!) for a big percentage of users. Admittedly, there are some other ways that we can try to work around this vulnerability, but none are really perfect solutions.

Also, there's this other issue which is sort of related to the rest of your post, which is that just because someone uses the same email address for two different services doesn't mean that they want to connect their identities in the two places.

Hopefully one day we'll be able to get past this, as I think we all agree that being able to unify this data would lead to some really cool possibilities. But as you obviously know, one needs to think about these things in a far more nuanced and careful way than many "web 2.0 fanboys" often do.

-Ari
Sunday, 10 February 2008 00:32:09 (GMT Standard Time, UTC+00:00)
It's not really discovery per se -- after all, you know who your friends are and how to reach them -- it's more the empty drive problem.

When you buy an Xbox, it's pre-loaded with some music and an arcade game so that you have something to do with it right away. Social networks have similar needs.

Signing up with a new site is the web equivalent of installing a desktop app, although most web devs haven't figured that out yet. When you install a new mail client, it offers to import your address book and accounts and so on. Lately some web sites have started doing this; NotchUp, for example, offers to import your LinkedIn profile (grabbing your job history, adding contacts who have already joined and giving you the opportunity to spam the rest).

However, people aren't using social networks exclusively like they do desktop apps. You add a friend on one social network and still have to add them on every other (and they have to repeatedly confirm). You become a fan of a band on MySpace and still need to become a fan on Facebook. You twitter something and still need to publish it to all your other public status. (At least with email I can check all my POP/IMAP accounts from a single client...)

Imagine if you had to give out a different telephone number to every friend based on which telephone provider they had signed up with. Here's my # on T-Mobile, and here it is on Verizon, and oh you're on BT? I haven't gotten a # with them yet. (Or equivalently, if to call someone you had to first know which telephone company they're currently signed up with.) What a mess.

What we really need are centralized authoritative services divorced from specific applications. We've got telephone numbers and DNS and time servers; now we need "status" and "directory" and so on. You'd think the GYM (Google/Yahoo/Microsoft) would be solving these problems, instead of being hyperfocused on search and ads.

Sunday, 10 February 2008 01:23:17 (GMT Standard Time, UTC+00:00)
Michael,
You know better than to suggest that Microsoft should get in the centralized user identity game. :)

I'm sure there are still folks here who remember how well that worked out a couple of years ago when we tried it with Passport single-sign on and Hailstorm.

On the other hand, I'd love to see something decentralized show up in this space. I think folks are on the right path with efforts like OAuth, OpenID and even the Google Social Graph API.

Comments are closed.