Building Portable Social Networks
- 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 whatever it is.
It’s a one-time process and so, I’m only finding people that I know at that point, but if people join that service later, I miss that. If I meet new people, I miss that as well. And then if I start friending people there it’s not coming back out, right?
So it’s not an ecosystem. It shows how important finding new people is that people have gone to this trouble and have done this sort of dubious thing of slurping in your credentials and your address book, just because finding people is so important. But It’s clearly just one little piece what really the solution is going to look like.
It’s easy to miss how much better the experience could be if these things could really talk in a persistent way.
Jeremy: That’s interesting to hear that coming from you, Joseph. You there working at Plaxo who even provide the API for other people to implement the password anti-pattern on other sites.
Joseph: And we’re very excited to be able to move now. For example, Google’s got their contact API and Yahoo has moved to BBAuth and hopefully they have all moved to OAuth. We really do look forward to being able to do that in a safe and secure way as possible.
At the same time, we always want to make sure people can see that value, so that they are pushing those companies to do it the right way. They realize there is some value there.
Jeremy: In case anybody didn’t get the news, it was on Wednesday or Tuesday, I can’t remember quite when, Google did finally release an address book API and that is fantastic news. That means there is no longer any excuse for a third party site to ask for your Gmail user name and your Gmail password.
Also, within 24 hours I think, or 48 hours, Matt Biddulph of Dopplr had already implemented the API. And seeing as I named and shamed him at the Social Graph Foo Camp, for using the password anti-pattern, I would now like to name and praise him for being so quick to get rid of the password anti-pattern. So a round of applause for Matt Biddulph of Dopplr.
[applause]
Okay, so that’s how not to do it. Asking for somebody’s user name and password for the third party site. And now we’re going to talk about the building blocks that exist today. This is not some future thing. These are technologies that exist today, that enable us to build essentially portable social networks, social graph, super best friends club, call it what you will.
Each of the panelists are now going to talk about one of those technologies, the little building blocks that we can pipe together to build a better Web.
So Leslie, do you want to kick it off, talking about when I go to a site to sign up and now I have to input my contact details…
Leslie: Again. Again. There are actually solutions for that. And so I have a little experience with it because we have implemented hCard on Get Satisfaction.
But what was interesting was not so much hCard. hCard is pretty straightforward. It is basically where you are just taking publicly available information from other services and pre-populating whatever fields you want on your service.
So I have a couple points that aren’t as technical. Big point I want to make is that with all this technology, the point is to make it like magic. We don’t want to tell people what’s going in the back. Wow. We just want them to know what it’s going to do for them. So we want to be able to expose to them what information is going to be shared.
All right. So, that’s surprisingly distracting for me.
So, for example on hCard, when we initially laid hCard out on our site and said, hey use your hCard and get information from many of these sites and we had Flickr and a few others.
I went back in and changed that so it did say something to the point of hCard is this sort of tool, use it here. Don’t use the word hCard. Don’t use the work OpenID. Don’t use the word OAuth. I don’t want to see that anywhere on the page that users are looking.
I mean, if you want to have it on there, put it in your about section, that’s fine. But you should say, and this example is, rather than creating yet another profile, why not start with the one you already have? That makes sense to people. They don’t need to know what is happening behind the scenes.
But what they do need to know is what information is being shared between the two sites. So, expose all that data. This is something that is going to get really, really complicated in the future as we’re sharing data, not from one site to another but through multiple sites.
So, being able to see that trail of information. The way that I would see doing this is a checklist of all the stuff that you are going to send over. What we do is we show you the image we’re pulling. We show you the user name we’re pulling. We show you all the other information that we can get, and we let you edit it right there before you click save.
So, it’s all there. You can edit. You can change it. You’re in full control. Another thing is that in the future it is going to get much, more complicated. hCard is pretty straightforward because it’s just, again, publicly available information like your user name, your photo.
But when Open ID, OAuth starts kicking in, you who are going to have these huge lists of people. You are going to have the content that you created. You are going to have the content that your friends have created for you.
So, the way to start thinking about that is how do you expose all of that in an easy digestible way? It’s really important to let people have control over this information and to expose the complexity in a sort of the gentle manner.
You want to pre-select a few things that of course they want to share. They want to share their photo from one service to another. They would want to share their user name from one service to another. But let them decide if they want to bring all their contacts over.
I start a new site usually… when I move from MySpace to Facebook it was because there were people on MySpace that I didn’t want to interact with anymore. So give me the option to not pull those people with me to the next site, right?
And let’s see, this is just a personal thing. Don’t treat your users like they’re dumb. Yeah. I’ve just been seeing a lot of this lately. Basically, they’re not going to understand these technologies and that doesn’t mean they are stupid. A great example is my mom. Yeah, my mom.
Everyone has that user case, right. My mom is actually very technically savvy. She’s an Excel power user; she does beta testing for them. She’s scared to death of the Web. That’s because there’s this culture that just a little bit hard to understand, if you’re not used to it. It’s not because you’re not technically savvy.
So, don’t be a xenophobe, go ahead and explain everything, but explain what it’s going to do for people, not how it works.
Jeremy: Excellent. So if you want to see this in action, getsatisfaction.com. If you don’t have an account yet, check out the sign up process and see how the flow works.
Leslie: Yeah. And just say to they’re going to talk to one of the technologies that we also going to be implementing really soon, because again I don’t think it’s necessarily even about your social network. If I’m a Digg user, and I want to use Get Satisfaction because it’s a service that helps my Digg experience, I just want to build a flow over to the other site. I don’t want to have to sign up for another service.
Jeremy: Okay. So that covers getting your information, your account information and profile information, from one service to another. Trickiest thing is your friends: your buddy list, contacts, fellow travelers, call them what you will. So Joseph, would you like to talk about the technologies for encoding that information?
Joseph: Sure. So, even before you get to your friends there’s just this same problem of all of you raised your hands for all these different Web sites that you use, right?
So, even if I can pull out say, my Twitter friends and I go over to some new site, how do I know that it’s the same David Recordon on this new site that I already knew from Twitter? Because all I know form Twitter is just Daveman692, which some inscrutable user name, right?
And so, in addition to saying who I know, a really important part of who I am, besides my name and my photo and that kind of thing that you talked about with hCard, is also what are the other sites that I use.
So, one of the simplest things that you can do is, almost all of these sites let you link to your home page and when they link to your home page, they not only put up a link there that other people can see, they encode it with a little microformat called XFN where it just sort of says rel=”me” and it just means this is another Web page about me.
And then computers know how to follow those links and figure out that, so for example, if I link from my Twitter page to my home page, and I link from my home page to my Upcoming page or my Flickr page or what have you.
Then if you come over to one of those sites, you can follow that trail of links and realize that I really am the same person on these two sites and, therefore, you already are my friend. Does that make sense?
So that’s a really simple thing that already exists today that almost all sites do support or could support. What’s really exciting is in the last month or two, Google released this Social Graph API that crawls all of those links and gives you a simple API to follow them.
So when people come to your Website, you can automatically sort of crawl these rel=”me” links. Remember these are just the things that people publicly wanted to say, “Here are the other sites that I use.”
So, I don’t link to every other profile that I have created. But for the set of profiles I want people to know about I link to them with these rel=”me” links.
They can kind of follow all the way downstream and all of a sudden, say, hey do you want to pull in your photos? Do you want to hook up your blog? Do you want to find your friends and do this sort of very rich thing? That’s available to everybody now.
So I really encourage you to take a look at that, because it’s I think one of the easiest things to do with the highest reward.
So, once you’re sort of figured out who you are and you can describe that in a rich way, then you want to be able to do this same thing with your friends. Now, this information may be public in some cases, and maybe private in other cases.
And it’s really important again to just stress that it doesn’t have to be public to be portable. You just need to be able to get it around.
And technology is like, oh, I’ll help you do the private part that they’ll talk about in a second.
Now, moving your friends around could be just as simple as being able to get the data out in a vcard or one of these standard address book formats. It doesn’t have to be anything new.
But there are these new standards like XFN, which is a way of sort of describing your friend relationships. So just like you can link to another page with rel=”me”, you can also link to your friends’ profiles with rel=”contact” or rel=”friend” or “family” or “acquaintance”. There’s a variety of different ways you can describe them.
And so the idea in both cases, and also with hCard, is you’re already using all these Websites, right? You’re already creating all this information, and in fact, in most cases, it’s already being served up in HTML for your friends and yourself to see, right? So you can just sort of annotate it in a very light way that will also allow the computer to be able to see it. You don’t have to create some whole separate system.
And so you can actually leverage, if you can see information that you want to be able to move to other sites and have it work together, that information itself should be encode able so that things can move around, right?
So if I give you access, if I tell you my Twitter username is JSmarr, and this works today on Twitter, you can go there, my little contact info up in the right? That’s got hCard, right? My list of friends that I’m following on Twitter? That’s got XFN. My link to my home page? That’s a rel=”me”.
And so you’ve already got the information you need there. You don’t have to learn about some secret API that’s totally separate, right? And I think that’s a very powerful concept because it means that we can enable this portability between all these sites that we’re already creating without having to start over.
And there’s also things like FOAF, which stands for “Friend Of A Friend”, which is sort of a more complicated format for describing who you know and who your friends are. And so Live Journal and other sites support that.
And actually, you know, it doesn’t even really matter what these formats are as long as I have some way of getting out the information about who I am and who I know from one site, taking it over to another site, and then being able to look up who I know either by email address or by following these rel=”me” URL links. Then I can do the sort of portability stuff that I want to do.
And people are going to be able to build the tools to glue it together and make it just work so that it can be under the hood like we were hearing about, right? And so the real thing you have to ask yourself is not, “What particular standard or particular technology do I need to land on,” but just, “Can I understand intellectually why empowering my users to not have my site be just a dead end but to be part of a social ecosystem is going to be good for them and good for me?” And then pick whatever technology works for you, and realize that there’s a whole set of us working on making all those technologies work together.
Jeremy: And before Google released their Social Graph API, you were working on some spidering stuff yourself?
Joseph: Right. So we had some stuff that went out and crawled these things on the fly, but Google’s already crawled the entire Web and they have it sitting on a hard drive somewhere, so it was much easier for them to deliver a really fast experience. I was very happy to give them the job of that.
David: Yeah, it was the exact same thing with us. We had demoed some stuff late last year, but it was like, Okay: Google already, exactly as Joseph said, Google has the Web, let’s let them.
Joseph: Oh, and it’s important to point out that Google’s not trying to do this for any kind of exclusivity. In fact, they very much hope that other people will mirror this API and use their own crawls of the Web. I mean, this is all based on public data, right?
So an important thing to realize, it’s not trying to invade anybody’s privacy, it’s just sort of saying whatever information I choose to make public, which could be nothing or it could be a lot, I should be able to leverage the fact that I’ve made it public by not having to repeat myself everywhere I go. It should be able to say, “Oh, look, I already know this about you, let’s start from there.” And of course, again, that’s good for everybody, because it’s just reducing friction.
Jeremy: Okay. So this is good. We’ve got, you know, my contact details, my friends lists; this is all portable at this stage.
We are talking here about publicly available URLs. There’s nothing to stop me claiming to be somebody else, right? I can point to somebody else’s profile. Now, of course, this is an issue with the Web in general, right? How do you trust anything on the Web? But there is technology for essentially enabling trust, I suppose? OpenID. So David, I think you know a thing or two about OpenID.
David: So, the basic idea with OpenID is that you, as Leslie was talking about and Joseph was talking about, you already have these other accounts around the Web. So when you go to a new service and you want to share with it your hCard, or you want to share what your other accounts are online via XFN, you still need a way to tell that service, “Here is who I am.” And that’s what OpenID can do for you.
OpenID is completely decentralized. No one owns it, no one controls it, and there’s tens of thousands of sites where you can login using OpenID, somewhere over a quarter billion OpenID identities out there.
So you’re building a new service, you can expect that everyone has one. Largest population there, every single Yahoo user and every single AOL user has an OpenID.
But it’s sort of that case of, OK, if I show up… here, I’ll use my props again. I’m going to go login to Facebook, assuming Facebook supports OpenID, with my Blogger identity. So I go over to Facebook and say, “Hey, I’m this guy on Blogger,” and they talk to each other. And at that point, now instead of going and creating a new account on Facebook, I’m able to use my Blogger URL, or my TypePad URL, or my Flickr URL, or all these different places, to login and say, “This is who I am.”
And if, from my Blogger URL, or from my home page, or from any of those places, I have profile information in my hCard, that site’s now able to discover it. If I’ve said, “This is where my other accounts are online,” that site is able to discover it.
One of the places that I do push back, however, around hCard being the perfect solution for profile portability, is when you’re dealing with things that you don’t want totally public. hCard’s great when you want to go and share your email address, and your name, and your avatar totally publicly on the Web. But if you’re wanting to give us, say, your phone number, or maybe you’re wanting to share some of your interests or some of your preferences which you don’t want to be completely public, that’s where OpenID can also help, as well as OAuth, which Chris will talk about next.
OpenID supports the ability for the site you’re logging into to say, “Oh, I need your email address as well,” or, “I need your first name, “or your postal code, or some of these really common signup parameters. That’s a really bad word for trying not to be geeky.
Pieces of information, your profile information, so that you can go and say, “Oh, yes, I want to share my email address, but no, I don’t want to share my postal code or my birth date.” So really giving you more control than what you’d have with an hCard, which is generally completely public.
And it’s interesting because you’re also able to then use OpenID to prove where you are sort of in the social graph, or what accounts you own. And so this is really interesting to us from the side of distributed reputation, where if you now have someone show up and comment on a blog, and that blog author and you are friends on another service, we could have your comment bypass spam moderation, and do some of those things.
It’s really important to know not just that you are random users coming to the site or that you have an email address, but that you’re actually connected between multiple people.
Jeremy: Okay. I’m going to take issue with your point about hCard there because I’m going to channel Tantek, who is on the microformats IRC node right now.
David: I expected that.
[laughter]
Jeremy: Your point is inaccurate because you are conflating format and protocol. Privacy and control is a protocol matter, right? HTTP, HTTPS, OAuth, that kind of thing, whereas the format that the information is coded in is something completely separate. So hCard, vcard, FOAF, whatever, should be separate. So I don’t see why OpenID couldn’t just use hCard for encoding, or why hCard isn’t the perfect format when the privacy or settings level thing is something that happens at the protocol level.
David: Yeah, so moving in hCard, or moving vcard attributes within an OpenID login flow definitely seems like a good idea, but as you’re seeing hCard being evangelized and being adopted today, it’s the, you have a public hCard on your Website. And I don’t think that really scales when you get into talking about, “How do we get these technologies out of the geek world?”
Jeremy: But I could have a private hCard on my OpenID.
Joseph: I think the point here is just that, again, some of your info you’ll be happy making public, some of it you’ll want to make private, and in both cases there’s a good answer for how do you move it around? You don’t have to make it public to make it portable, and there are these various standards for marking it up, and it works well in both cases.
Leslie: And in both cases it’s really important to make the distinction very clear to people trying to move this information around.
David: I’m not at all trying to argue that OpenID shouldn’t adopt vcard and hCard attributes in the protocols when it’s getting moved around. Just wanting to point out that the way that it’s generally being used today of totally public. And it works great. If you’re going to comment on a blog, you want to go grab your avatar to show up next to your comment, that’s perfect if it’s totally public.
But I think that it is important to realize that not all of this profile information is going to be public information.
Jeremy: Okay. Well, we get on to the issue of protocols now, I think, because we’ve covered contact information, my friends, and now, essentially, authenticating there’s a trust level, “This is me,” proving who you are.
But what you’re talking about now, this idea what’s public, what’s private? Kind of getting on to authentication, and there are good and bad practices when it comes to authentication, and the one I’d like to hear about now is something called OAuth. And I think Chris; you’d be the man to talk about this.
Chris: Sure. First of all, actually, it’s not so much about authentication as much as it is about authorization. Those are actually two very important, different practices and ideas.
In particular, actually, I’ll tell you the story about how OAuth came to be—which was actually originally called OpenAuth, until a larger company ended up owning the trademark and we had to change the name.
About a year ago, last December or so, I was talking to both Blaine Cook, from Twitter, and Larry, from Magnolia, and at the time I was trying very hard to get Twitter to adopt OpenID. And it turned out that they had a problem doing that because, at the time, they were using more or less cleartext passwords for their API. Well, OpenID had no way of really dealing with APIs, and so this was a real stumbling block and kept them from implementing and supporting OpenID. Well, that was a pain in the ass.
Well, it turned out that Magnolia was actually a supporter of OpenID, was a consumer of OpenID. And the problem there was that when you wanted to use a Magnolia dashboard widget, you couldn’t actually log in to that dashboard widget using your OpenID. They required, basically, user name and password. And so these two problems basically coalesced into helping us to identify that, oh, this is actually a problem that a lot of people are going to have if we’re going to continue to evangelize OpenID.
This work ended up sort of turning into an extraction of a number of protocols from a number of service providers, namely Google’s AuthSub, Yahoo’s BBAuth, FlickrAuth—a bunch of different things, basically for authorizing access to your protected resources in some account that you have. So, in order to basically continue promoting OpenID, we needed to solve this problem.
We went about doing that in what started out as a closed process, having maybe 10 or 15 people talking on a mailing list, getting together in person, and eventually opened it up to a larger audience, to a much wider mailing list. And eventually, this past December, we released the OAuth 1.0 spec, with a great deal of work actually done by one of our friends, Eran Hammer.
What’s important about OAuth is that it allows you, instead of using your user name and password credentials, to instead provide tokens that are used to essentially sign messages, to say, “Yes, this is actually me saying this is OK,” whatever. But more importantly, the user experience is identical to what you would experience if you’ve ever used Flickr Uploader, for example.
And what that means is that, let’s say you download the Flickr Uploader. The first step of that process is to go back to Flickr through your Web browser and tell Flickr, “Yes, I want to actually enable the Flickr Uploader to upload stuff to my account.” Obviously, I don’t want everybody to be able to do that, or random applications to do that, but I want to be able to specify that, yes, it can have access.
Beyond that, I want to be able to say what specific permissions that application has in accessing my account. So, do I want it to be able to delete my photos, or maybe just edit the meta-information, or maybe I just want it to access the stream and not actually be able to make any changes. Well, with these authorization protocols, you can actually do that and be very, very specific, as opposed to the alternative.
And this is the problem with the password anti-pattern that was described before, that, for example, if you were to import your Gmail contact list or your Yahoo contact list or whatever, using your full credentials—in this case, your Gmail user name and password—you’re now giving someone else credentials that can unlock your Google Checkout account, your Google Web history, and all these different things. Google has no idea what you’re actually giving permission. All it knows is that you’re logging in legitimately and it knows how to identify you.
So this protocol is extremely important for, essentially, permission-ing the Web, for giving you control over who accesses what and for how long.
Another important aspect of OAuth is that you can essentially manage these tokens. So, essentially, when someone has one of these tokens, they come back to your account, they say, “Hey, I got this special, shiny token. Let me have access based on this stuff.” Well, if your service provider is like, “Well, actually, that token has been revoked. It’s no longer good here.” You no longer have the Facebook wristband. You can’t get in anymore. Sorry. Party’s over.
And that’s really important because it means that you don’t have to change your password across every single different service just to disable one service accessing your account. That’s a huge user benefit, actually.
So, some other aspects of this, in terms of adoption, I guess—again, this protocol only came out in December. But we’ve already seen a number of people implementing and supporting it, largely because, well, for two reasons. One, we spent a lot of work actually building libraries, so it’s super-easy. If you go to oauth.net/code, you can get libraries in a bunch of different languages, written by the community, to get up and running very quickly.
The second thing is that it means that developers have to spend a lot less time actually implementing support for lots of different authorization APIs. So, for example, in the case of importing your contacts from lots of different services, you actually have to implement, one-off, support for Google, for Yahoo, for whoever else you want to import stuff from. And that’s a real pain in the ass, because now you have to maintain all these different sets of APIs.
But we are seeing adoption, like I said. Probably one of the bigger ones this week came with Fire Eagle. In fact, Rabble Twittered today about how great it was to be able to use OAuth to do their authorization stuff. And if you don’t know what Fire Eagle is, basically it’s a way of storing your location and spreading it around.
This also means that if someone has implemented OAuth on a consumer side, they don’t have to implement support for yet another authorization protocol. It makes it super-easy. You do it once, and you’re kind of done.
As well, Open Social is using some of this stuff, so Google’s there. Twitter will eventually get it, even though it was promised in October. Pownce actually has it already. Magnolia has it. Satisfaction actually is using it. There’s a new service launched, I think, two days ago, called Thumbnail that has it. And there’s a number of other sites that are, more and more, almost every day, coming online using this stuff. So it’s really good to kind of see this adoption out there.
David: On the OAuth adoption, we’ll actually be announcing tomorrow a Fire Eagle plug-in for Movable Type, as well as that the next version of Movable Type will ship the Net.OAuth Perl plug-in so that then plug-in developers, on top of it, have no hesitation about, “Are they able to use OAuth? Will the libraries be installed?”
Joseph: And all the big players have basically said, “Yeah that makes sense. We want to move towards that.” Because they all have pain with customer support of people who haven’t figured out how to do the special, custom version properly. And so just being able to drop in a library and say, “Here’s a way that I can safely get my users to get their private data,” is something that everybody’s very excited about.
Chris: In fact, there’s a company that basically builds support for APIs, called Mashery. And Oren Michaels said in the comments of a ReadWriteWeb post the other day, about this G-Archiver application that sucked up people’s Gmail user names and passwords, that their greatest request right now from a lot of their Enterprise customers is actually supporting OAuth. So we’re seeing a lot of interest, just out in the marketplace in general.
Jeremy: Very encouraging. Listen, at this stage, I want to open up this discussion to you guys. So we have microphones, and please make your way to the microphones and have your questions ready.
This all sounds very encouraging, the adoption of OAuth and other technologies. How far away are we from having that nirvana of the “Vaselined Web” of portable social networks?
[laughter]
Joseph: I think we’re actually really on the cusp of a major positive transformation about the way Websites get built and the way users use the Web. So it’s important to realize, of course, all of these things are still fairly nascent technologies. And in addition to the technical hurdles, there’s sort of the user education and there’s the sort of bigger sites finding the time and resources to implement this stuff and get behind it.
But, even as someone as optimistic as I am, I have just been so surprised at how quickly these things have moved and how the big players are all sort of getting it. I mean, they’ve seen this before. They saw AOL and the Web, and they’ve seen these things about open winning and user choice winning, and they don’t want to make the same mistakes they’ve made before.
So I really do think, if you’re going out there thinking about “What kind of apps should I build?” or “How should I design my thing?” right now, you have this sort of devil’s bargain between I build a completely standalone site that’s very hard to get people to use, or I go live inside some walled garden and I’m sort of beholden to them.
And there’s going to be this third way, which is that I can build a site where people can come and bring the info that they have, then share the info back out, and I can be part of this rich ecosystem, and users can have control about who they want to share with and what’s private. And that’s the world you’re all going to be living in very soon.
And so, start looking at it. Start following it. Different people will want to be earlier or later adopters. But we really are moving into this world, and I think it’s very exciting, and I really don’t see any reason why it’s not going to happen very quickly.
David: I agree that we’re moving there. I don’t think very soon and very quickly is when it’s going to really be ubiquitous. But I think, going back to the first five or ten minutes of the panel, this is going to happen when there’s the business value there, and that’s where really focusing on what is that feature you’re building is going to get you there.
And so that’s, I think, where it’s encouraging to see companies, like Pownce and Twitter and Fire Eagle from Yahoo, seeing the business value in using OAuth for their API, in that more developers will interact with their API quicker. And I think that’s where you’re going to see this adoption come from.
Jeremy: Okay. Let’s have a first question.
Audience member: Okay. Well, first, I’m really looking forward to seeing “Vaselined Web” as a PR term.
[laughter]
Jeremy: Somebody please get that domain name. Thank you.
Chris: There’s a lot of Vaseline on the Web already, so…
[laughter]
Chris: Sorry.
Audience member: And that was really it. No, no. So one of the things I’m kind of curious about is getting your opinions about the discretization of user relationships brought about by XFN. So, you know, it says rel=”me”, rel=”friend”, rel=”hookupped”…
[laughter]
But there’s no real continuous measurement of my relationship with my friends, and I don’t even know if it’s possible but if you guys have thought about it I’d like to…
Jeremy: Well XFN is, by design, always present tense. It’s current. There is no past tense or future tense.
Leslie: And there are no negatives, either. I do have enemies.
Jeremy: Well, myself and Brian Suda have been working on XEN, which is XHTML Enemies Network.
[laughter]
Jeremy: It’s mostly a subset of XFN because actually, most of the terms in XFN are neutral, like coworker, colleague. There’s only a few that are positive, like friend, sweetheart, muse. So, you know, arch-enemy, nemesis, there’ll be a few more.
Leslie: Yeah. That’s all…
David: But still, taking it from technology to feature, like I think what you point out is really important, that there are going to need to be services which help people manage information like that in order for the technology to remain in that present tense.
And I think that you’ll start seeing more of those services evolve, and that’s where technology is interesting. Instead of going and creating your own way to represent that present tense of a relationship, use an existing open standard.
Joseph: And I think there’s no doubt that when you can start to define more fine-grain relationships you’ll be able to start sharing in more important and nuanced ways. Even just sort of scratching the surface with that in Pulse where you can share different things with your family and your friends and your business network so you don’t have drunken college photos showing up at your business interview, and if you just want to share photos privately with your family, you can.
I mean, that’s sort of a very crude partitioning, and even that has had a tremendous impact. And so I think the problem, though, is it’s a lot of work to actually go and say what your relationship is with all these people. And as long as you’re doing that in sort of a closed silo, it’s not really worth it, but once you can leverage that investment so that over time you can describe more relationships, you come here and you say, “Well, I want to do something with my family.” Well, who is your family? And you can pull in those relationships and tag them and that can flow back out. Now the reward is going to be there enough that I think people are going to start doing more and more of that. And I think we’ll see that evolve over time.
Jeremy: So, I do take your point that XFN is rather limited in a number of relationships that could be defined, but it is by design because it is then simple. So there’s always this tradeoff between simplicity and complexity, and other formats might be able to encode much more nuanced and fine-grained information, like FOAF can do that, you can define pretty much any kind of relationship, but then the tradeoff is it’s pretty complex.
Audience member: Yeah. You know, and I think no one’s really interested in, like, having a slider of how much of a friend they are with somebody.
[laughter]
So that’s a good point about the technology.
Jeremy: Yes. It’s true. And by the way, the thing about XEN, that was a joke. It’s not really going to happen. XHTML Enemies Network, it was a joke. All right.
Leslie: Somebody else do it.
Jeremy: Next question please. Oh, we’ll take it from this mic over here.
Brad Templeton: So, I’m going to put on my hat as chairman of the Electronic Frontier Foundation and tell you that everything you know is wrong.
There’s a paradox that comes out of technology like this. And that paradox is that if you make something easy to do, if you give it a good user interface, if you do all the things… if you add Vaseline…
[laughter]
… all the things that we think as engineers that we’d like to do. The easier something is to do, the more it will be done, and the more it will be asked for, and the more it will be demanded for. And if it is easy to give away all your information, even if you give people this wonderful sounding thing, control, an easy checkbox that lets them control who gets what, you’re still creating an interface where it’s easy to give people information.
Now, that will mean more information is given to more applications. Now let’s look at Facebook, for example. With one checkbox, I can tell any new application that is begging me about how cool it is everything about me, my whole friends list. There’s only one checkbox. I have no negotiation ability.
Jeremy: Right. But you clearly didn’t get the memo that privacy is dead, right?
[laughter]
Brad: At EFF, we’re a little bit slow on getting that memo.
[applause]
By the way, I just want to make the plug…
This week in Congress, they’re voting to give immunity to all the phone companies for letting the government get a wiretap on all of the communications through AT&T. Now, we’ve been fighting this in a lawsuit and the president is getting Congress to pass a law to throw out our lawsuit. If you would all call your congress people for me, tomorrow or today, and tell them that you want them to not grant that immunity, I would be really pleased.
Jeremy: Okay, that is a very good cause.
[applause]
Your point is well taken, and this actually came up in relation to the Social Graph API, because I remember the morning it came out, I was like, “Oh, this is awesome!” and I was putting it in my blog URL and watching all these links it was finding, connections in all these sites.
I thought it was great. danah boyd, small D small B, wrote a blog post about…
Brad: And a dot, don’t forget a dot.
[laughter]
Jeremy: … how this was not necessarily a good thing for the reasons that you’re suggesting, that now it’s easier, it’s Vaselined, and the thing is, if it can happen, it will happen, that maybe users don’t expect this kind of ease of access to all their information.
Joseph: There’s no doubt that there’s a user-education component here. I mean, you even think about the Web itself, people had to get used to the idea that you can Google somebody and you better know what comes up, and you better be able to do something about that, and you may not want that information being available. And so, similarly I think you’re going to want to start to learn more about who you’re sharing with what.
But still, there’s so much good benefit to happen that the solution is never to do nothing. The solution is never to just lock everything down. I think the solution is to move forward with a certain amount of humility and caution and really make sure that users are being educated and having control, and just sort of take it as it comes.
Jeremy: Okay. Chris, did you have something?
Chris: Yeah. I mean, I think there’s an important point, and I definitely respect what you’re saying, Brad, but at the same time I think that in some ways these technologies that we’ve been working on are efforts to make things better than they are today, because right now people are throwing around their credentials like confetti.
And if we can prevent that and make it harder by actually improving the baseline technology that underlies all this stuff but they get the same benefit, I mean, the reality is, and this sort of goes to Joseph’s point…
Brad: But you’re making more confetti, even if it’s smarter.
Chris: Well, I’m not so sure about that, I think there’s…
Jeremy: This isn’t really a technical issue as it is cultural.
Chris: There’s a business aspect to this, and I think, like Joseph being sort of on both sides of this, where Plaxo has this API that allows you to basically pipe your confetti passwords in through Plaxo to get your address book out.
The reality is that people want to be able to connect with their friends, and that’s a problem that needs to be solved. If we can find a better way to do that that’s less risky in terms of exposing all their privacy, then I think we’re actually enabling the types of social interactions and connections that we want while also, in some ways, keeping them safer.
And I also would suggest that some of the work that we’re doing and the building blocks that we’re creating that are open and non-proprietary are an effort towards creating more competition in the marketplace, because we do not want just Google and just Facebook and just MySpace to determine the aspects of this conversation. I think that it needs to be much wider and much more diverse.
Jeremy: I also want to point out, of the four technologies we’ve heard about here today, two of them, yes, were about publishing stuff, and how do you format this stuff: hCard and XFN, the other two were about how do you protect access to that, how do you authenticate and how do you give control to that data? So there is a balance here with those technologies.
Leslie: I completely agree with you. This isn’t going to make things easier; it’s going to make things much more complicated. Much more complicated, and I’m kind of tired of hearing the sell that it’s, “Oh, everything’s going to be wonderful once all of these technologies are implemented.” They’re not.
What it is going to do, though, is give us a lot more control and understanding of what information we are sharing, and more control over how we share that information. So I think what’s going to happen is we’re going to open up a huge whirlpool of issues.
This is part of the evolution of the Web, and it’s great, and I don’t want to stop it. This is not about shutting it down, it’s just saying, this is the reality. It’s actually going to get much, much more complicated. And we’re going to come up with better ways…
Jeremy: Okay. I’m going to have to move on. I’m going to have to move on.
It is kind of tough love what we’re doing, and there will be interesting times ahead, there is no doubt about that. But what we have at the moment is essentially security through obscurity, and that really isn’t particularly secure at all.
David: There’s a middle ground, though.
Jeremy: Yeah, I agree. I’m not saying the technologies make everything wonderful, but there is this balance.
Leslie: But we’ll get it out there and we’ll come up with good solutions.
Jeremy: Yeah, once we know what the problems are.
David: You’re right, and there are lots of questions.
Leslie: Unfortunately we’re going to fix things after we break them.
Jeremy: Yeah. It’s going to hurt for awhile. Aral.
Aral Balkan: You touched upon the fluid nature of social networks of our relationships. And they are they can change from day to day. But a lot of the information that we’re creating out there is pretty static, and there might be different versions of it depending on when and where you expressed your relationship to someone.
So two questions, one that came out of Webcamp in Ireland. We were talking a lot about XMPP and maybe creating a real-time network, and the other, what about versioning of all of this information?
Leslie: Yeah, how great would it be if you could take a snapshot of your profile, right? This was me in 2000. This was me in 2004.
Aral: Yeah. I guess the temporal dimension in all of this is really what I…
Jeremy: Yeah. I guess we do concentrate on the present, right? The lifestreaming stuff, events happening right now. But Google never forgets.
Joseph: I hope that the stuff that we’re all talking about will make that problem a lot better. Right now if I move or change my information, I have to go around to each individual site and update it, and that’s if I can remember all the sites that have that information.
David: If you want to. Do we need to go back to another one of the arguments that danah boyd made of that people in some of her studies have actually moved between these sites because they don’t want to connect their information, they want to start over?
So I think that the default answers of, “Oh, all of this stuff is wonderful and the bunnies are going to run through the dandelions,” isn’t the right assumption.
[laughter]
Joseph: The broken case works really well right now. But what doesn’t work really well is the fixed case, right? [laughs]
Chris: Yeah. So I think the broader point, though, is really around this notion that’s lacking from a lot of digital systems, which is decay. I mean, our relationships are much more organic, and they change over time, as you’re suggesting. But digital systems are made to exist and to stay the same way, because they’re all made up of bits.
And I think that, potentially, what I would like to see is, I guess, putting a person in control of their relationships, or at least being able to manage them, in that the systems—or in some cases, their identity providers—get smarter about understanding how close someone is.
I mean, one of the great things that I think a lot of people get value out of Facebook is going back to like Kindergarten and finding all the friends that they lost. Now, that’s a very interesting thing, that if you took a very linear approach to decay, you’d never find those people again.
So I think, in some ways, we need to rethink the way that we understand the way that people are represented on the Web and the way in which, as you’re suggesting, those relationships are represented, so that we can stay in touch with people, fall out of touch with them, the interfaces actually respond to that and become better, but that we’re not cut off from them forever.
Jeremy: Yeah. I think we tend to focus on technologies that are fairly binary and yes/no kind of answers. And what we’re talking about here is people. We’re talking about relationships. And relationships with people are complicated. So I don’t think there are technological solutions, necessarily, for these issues.
David: I still just want to go back to what Leslie said in the first five minutes of, if you look at this by—I mean, I fell for this nine months ago, writing that paper with Brad Fitzpatrick about “Let’s go open the Social Graph,” and then joining Six Apart and saying, “We’re going to open the Social Graph.” And focusing just on the technology and just how to make this stuff portable? Completely the wrong approach.
Changing that to go and look at: what are the features that people want? What are the things people want to do? How can we start building those, bit by bit, and supporting the principles of this sort of portability? I think that’s the way that it has to be done.
Leslie: This is like really large-scale iterative design. You want to put things out, see if people are using them—allow them to decide how they get used, not force people into different frameworks.
Jeremy: Right. We don’t want to make assumptions for people. I want another question. We’re going to have to go pretty quickly through the questions. Thank you, Aral.
Audience member: My question kind of builds on that. You guys have all alluded to the fact that so far we’ve seen very technical solutions to what essentially is a human-focused problem, right? And Dopplr and Satisfaction have pretty much set the bar in terms of design patterns for profile importing, importing friends. And I’d love to know how you see those design patterns being refined, or where the room for innovation is with them.
And secondly—it’s a two-parter—how you would rank the user experience of using OpenID and authorizing access to data through technologies like OAuth, particularly the breakdown in continuity when you’re bounced to another site…
Jeremy: Okay. So, Leslie, first of all, if you could take the first part of the question about the user experience of importing…
Leslie: Sure. Oh, and even the second part. There’s all these devices coming out now that can kind of read your brain waves and show your emotions, and I really wish that we were using those more in user testing so that you could actually see when someone was frustrated. So some if it is actually just user testing.
But yeah, it’s actually been really interesting. I think you could say that we’ve set the bar, but we’re still seeing these things happen. We’re not sure if this is the right way. Right now, the usage of hCard, the way that it was sort of implemented before, was pretty low on our site. People are still pretty comfortable just coming in and adding a new photo and adding their user name.
There’s been some reframing on it, and there’s going to be more reframing, because we’re very iterative; we’re going to add a lot more to the design. So we’re still experimenting.
What I would like to do is start talking more about those design patterns. A big influence for me was Yahoo Design Patterns. So, if we could sort of start doing something like that, around all of these technologies, that would be really, really brilliant.
David: Let’s do it.
Jeremy: Library patterns would be great.
On the second part now, OpenID, I agree: OpenID can still be sort of scary-techie. It’s still not for everyone. There is a new service coming out, and you talked about this earlier in your other panel. Peter Nixey—I don’t know if he’s in the room. There. He’s down there. He’s got this service called Clickpass, which is essentially a nice, pretty interface onto OpenID. Under the hood, it’s all OpenID, but what you experience as a user is pretty nice.
Leslie: And actually, even more than being pretty, it just makes sense. It’s probably the first implementation of OpenID that I’ve ever seen that actually makes sense. Their tagline is brilliant. It’s “Log on to the Web.”
Joseph: Yeah. So I think this is an area we’re all still experimenting with actively. We have a very mass-consumer user base who doesn’t know or particularly care about any particular technical standard. And we also track our metrics very carefully in terms of sign-up rate and adoption and falloff and that kind of thing.
We’re seeing areas where this stuff can really help, and we’re also seeing areas where it’s sort of too cumbersome and people get confused. And so I think that ability to have that dialog—and that’s certainly something we’re hoping to be contributing to the community.
And we certainly talk with Yahoo and Google and all these other people who are working on this, about sort of what’s working and what’s not and where do we have the opportunity to streamline things, or, actually, sometimes you want to un-streamline things, right? To those points of sometimes you want to put more friction in the place and say, “Are you sure this is what you want to do?”
Jeremy: Right. Take out some of that Vaseline.
Leslie: Yeah.
Joseph: I think the good news is that there’s a very active community here. And when we’re at these Internet Identity Workshops and things like that, you’ve got people from Google and Yahoo and AOL and Microsoft and Plaxo and Facebook and developers and individuals, all sitting at the same table and all earnestly kind of talking shop.
And I think that sort of spirit of camaraderie and sharing has what’s really made these things move as fast as they have. So I’m optimistic we can work some of that stuff out. But it’s certainly not done yet.
Jeremy: Okay. We’re more or less out of time. If anyone has like a really quick question—but it’s got to be quick—get to the microphone and shout it out.
Audience member: Okay. I’m Pete, from Blogger.
Jeremy: We don’t care.
Audience member: Okay.
[laughter]
Audience member: Leslie, you said, “Don’t say hCard on the site.” Yet we launched OpenID commenting on Blogger. And so we said, “Use WordPress. Use LJ. Use TypePad.” How does that scale? Are we going to have 10 “use these sites to log in,” or can we sometimes say “OpenID”?
Leslie: That’s interesting. So our front-end guy actually just put another box that said “other,” and you click on that and it gives a list of things.
Jeremy: Okay. Answered. Next question, quickly.
[laughter]
Jeremy: Because people have been queuing for ages, and I want to make sure they get to ask their questions.
Audience member: Okay. You’re effectively redeveloping another operating system, where the Web is the operating system. And you’re reproducing the concept of groups and access control lists, but you’re trying to do it in a distributed way. Isn’t there actually going to be the need for each user defining a place for an access control list in groups, and then all the applications access that?
Jeremy: Oh, so, centralized instead of decentralized?
Audience member: Well, it’s a single point, an authoritative source, rather than applications seeking to be the OS.
Leslie: When Clickpass comes out tomorrow… Ooh. Go check it out.
Joseph: That’s one way you can do it. With OpenID, you choose your provider, and you can choose a lot of information there and have other people delegate to it. But you don’t just have to have one provider for all your information. So, maybe Flickr is going to be my source of authority for my photos, and maybe Plaxo is going to be my source of authority for my address books…
Jeremy: Short answer: OpenID’s pretty good. Okay. Quickly. I just want to go…
[laughter]
Audience member: All right.
Jeremy: We’re out of time, so I really want to…
Audience member: Not a question for you guys, but a question for YOU guys. Who here screen-scrapes Hotmail today? Anyone?
David: Don’t raise your hand. They sue you if you do.
[laughter]
Audience member: No. Because we’ve got an API for this. And lots of people just aren’t aware that you can safely access your Windows Live contacts. Like I think people up on the panel are even screen-scraping Hotmail. There is an API for this, and a lot of people just aren’t aware that you can do this. So this is just a gratuitous plug.
Chris: All right. Use the API.
Leslie: Ready. Set. Done.
Jeremy: That’s enough. Kevin Marks, you get the last word.
Leslie: Oh…
David: No, there was another guy over there.
Chris: One more.
Jeremy: Can you make it quick, Kevin?
Kevin Marks: Okay. I’ll make two things quick.
Jeremy: One thing.
Kevin: One is we’re switching the Gmail contacts API to OAuth.
Joseph: Yay.
David: Yay.
[applause]
Jeremy: Oh, fantastic!
Kevin: That will happen—I can’t give you a date yet because it’s…
Jeremy: So you have nothing to announce?
Kevin: I’m announcing we’re going to do it.
Jeremy: Vaporware. Great.
Kevin: It’s a commitment, no?
[laughter]
Joseph: That’s very good.
Jeremy: No, that’s good.
Joseph: You heard it here first.
Kevin: David, you committed to OpenSocial in November and I’m waiting.
David: [laughs]
Jeremy: Great. Okay. That’s fantastic.
Kevin: Okay. And the second thing is there’s the Google OpenSocial OpenBar party at McCormick and Schmick’s, starting right now, and I should be there.
Jeremy: Okay.
Kevin: We’ll talk about XFN and…
Jeremy: Okay. We’ll do some portable social networking there. And the last word goes to the gentleman here.
Audience member: Thanks so much. And this is perfect, I think, to lead into drinking, because it’s a scope-buster. So, with OpenID—and I really enjoyed the panel earlier today—it seems to me we have a distributed, URL-based authentication system. There’s actually nothing in there that says what’s at the other end is a person, right? Couldn’t this be for any number of things? And aren’t we doing some real Web architecture here?
What comes to my mind is whether the object on the other end is a Creative Commons license or a copyright license object, and my usage on it may be something that’s Trackbacked to it in that way. Is this where OpenID is going?
Chris: That’s where DiSo, which is a distributed social networking project that I’m working on, is going next.
Jeremy: Minus points.
Chris: Sorry. It’s not a company! It’s not a company!
Joseph: Yeah. OpenID is a simple building block for proving that you own a URL, and I expect it to be used for lots of interesting things.
Jeremy: Yeah. I think that’s the important point, that these are all kind of building blocks that can to be piped together like UNIX pipes. And yes, there will be all sorts of mashups, I guess would be the way to describe them, that we haven’t even thought of.
Joseph: Real mashups.
David: Mashups 2.0.
Jeremy: Okay. Listen, everybody. Thank you so much for coming…
Joseph: Thanks, guys.
Leslie: Thank you.
[applause]
June 8th, 2008