Building a Ubiquitous Social Network - Interview With Chris Messina

NetSquared
See all of NetSquared's blog posts

chris messina Chris Messina, champion of the open Internet, talks to us about how he's trying to make online social networks "like air," and how that'll open opportunities for organizations and individuals working for social benefit.

Jed Sundwall: So, thanks for taking your time to talk with me.

Chris Messina: Certainly.

I know that you're already very familiar with NetSquared. In fact, Marnie told me to track you down because she just wants to profile you, I guess, on the site. She wanted to get your thoughts on how you think social media can be used for social benefit. I'd like to steer the conversation towards what you're thinking about doing with DiSo, [pronounced Dee-so] basically what your motivations are, what your goals are, what the vision is.

That's a pretty good prompt actually to start. Maybe I can go back a little bit and just give you some background on where the project came from because I think that's actually fairly relevant, especially given the NetSquared audience, which actually kind of plays into this stuff a little bit. I used to work on a project called CivicSpace, which, again, some folks from the NetSquared community might be familiar with. It was actually a project that was built on top of the Drupal content management framework. And the idea there was, essentially, to create organizing tools for non-profits, groups like that. So, that's what we're doing.

From that experience and in using the CivicSpace platform to run this Spread Firefox campaign which helped to sort of market through grassroots and web communities, the Firefox browser that it launched, I kind of realized a number of traits of social networking, behavior, things like that that people like to use a lot of different social networks, for one. And really figuring out a way of advancing the state of the social web would be useful. So, that's where some of this came from first, a long time ago.

And then, when I helped start this browser project called Flock, which, of course, had social networking type features sort of at the center of it, figuring if we brought together a number of different in boxes, friends, all of those different notifications that are going on in social networks into the browsers, the browser would place your friends around all these different networks. Then, we could actually merge all those different things into one place. That would be pretty convenient. And then, we'd just become sort of like part of the web, part of your interaction model.

And, of course, Flock is still going and has a number of very enthusiastic users. It's definitely pushing some of those aspects forward. But, it's hard because, of course, Flock has to kind of special case every different social network and build functionality and features that kind of take the best of each one. So, that's sort of annoying and really inefficient.

Let me move forward and sort of describe the DiSo project is about decentralizing social networks, enabling people to pick a social network that they want to use, or pick what will become sort of known as the identity provider, or where you host your stuff on the web, enabling you to interact with people who use different networks without having to necessarily have to create a whole new account, a whole new password, and all those sorts of frictional points that really aren't adding any value for you, as a user of these things, but that a lot of different companies, for whatever reason, mandate.

Anyway, I feel like that's what the DiSo project is about. And what we're doing or at least where I'm coming from, having tried to do this through the browser, having experienced this through CivicSpace, having worked on the Spread Firefox project, where we were trying to leverage people's social activities online to get the word about Firefox out there. And also, see more and more applications emerge that are web-based applications and that are made better through the use of social functionality. I think figuring out ways of adding like a social layer to each application in a simple, straightforward way that actually adds real value and doesn't force you to just create an account or add friends because that's what every site now is asking you to do, is part of the goal here.

The metaphor that I've kind of used or the experience that people might be familiar with, maybe, maybe not, there's sort of two cases. One is when you, let's say, buy a new computer or when you go to a friend's computer, you're visiting your parents or something like that, or you're in a hotel, traveling. In any case, let's say you go to a computer that you've never been on before and you want to do your instant messaging. You want to talk to your friends. You may download a client. Neither of those is probably the best example, but let's say you download some application like AIM or ADM or things like that. You sign in, and all of your friends are brought with you.

So, you're sort of accessing this resource on the web, in the cloud that knows who all your friends are, allows you to sort of gain access to them, and then, to interact with them in a way that you sort of expected. And you didn't have to add them all over again, even though it's a brand new computer. And I think that this metaphor should sort of work for the idea of websites and web services that you've never been to before, you've never used before, and that some of your friends might not even have used, but that you want to share content, information or whatever with your friends from that site.

So, this is sort of re-architecting the way, in which a lot of these networks work today. What the DiSo project is about is figuring out how we can architect these technologies, on the one hand, sort of engineer them for adoption, as my friend, Joseph Smarr, likes to say. On the other hand, figuring out the ways in which we can design technology that enables people to do the right thing by default, or more often than not. I started working on a post that describes what that challenge is. It's really easy to ask someone to enter their user name and password for a remote website like their Gmail account, into another site, in order to bring in your contact list.

The problem with that, of course, is that these credentials, your Gmail account or your AOL account or Yahoo account are becoming increasingly valuable. So, you don't really want to be entering them into the web all over the place and yet, these sites have kind of made it easy for developers to do that right now. So, part of the DiSo project is trying to figure out how we can abstract some of these behaviors that are quite common, and then, develop technologies around enabling the behavior, without compromising on security or sort of the assurance that people need when they want to just connect with their friends.

OK, and you're going after WordPress initially?

So, we're starting with WordPress, Drupal and MoveableType. And what we're trying to do is build some plug-ins that build on those core platforms to start with. Especially in the case of WordPress, there's kind of a recognition. One, there's some lead users in there, but also, there's folks who are using their blog as kind of their source of identity on the web. They've set up a blog a while ago, they've installed some plug-ins that might aggravate some different sources. And, frankly, it's a much easier platform to sort of hack on in the beginning, given the community around plug-ins and things like that.

We also want to get to the point where we're able to offer interoperability between a site like WordPress and Drupal or Moveable Type because, of course, the idea is if we're going to support the open web, that having a number of platforms that support these basic technologies is good for the entire ecosystem. And that letting people build on and use platforms that they prefer or that they've invested in is also, I think, paramount to being successful in this overall effort.

It's also, and I should also point out that what we're trying to do is sort of come up alongside efforts like MySpace and Open Social from Google, or being led by Google, anyways, and also, the Facebook platform, in order that folks can continue to sort of innovate in the open and in the lab on platforms that aren't controlled by companies whose primary stakeholders are either advertisers or other large social networks.

Right, I mean, I use Open ID. I've plugged Open ID into my WordPress blog. I guess DiSo would be something akin to Open ID, but with friends, is that right?

That's actually right. DiSo, itself, actually, kind of encapsulates a number of different general trends or behavioral patterns that we see. One of those is identity. In fact, Open ID is a core platform piece of DiSo. That's part of the stack. As well, friends are part of that. And so, we've been working on a new format called Portable Contacts, which is actually based on vCard, which all address books more or less accept. And it's also compatible with the micro format hCard, which can embed in regular HTML, which anybody can publish. And so, that would be a way of describing your friends.

And then, we also have a product called OAuth, which we spent the last year or so developing and have spent the last seven or eight months working on the intellectual property issues around that, in order to get that into the Open Social platform. And places like MySpace and so forth are actually adopting that protocol. That deals with permissions and access to your data. So, those are a few of the core pieces right now. We have identity, you have friends and contacts, you have permissions and granting authorization, revocable authorization to let other people or other applications or web services access your data.

And then, we're also hoping to deal with messaging. So, one of the big parts that actually social networks are used for are actually doing, essentially, e-mail, e-mail type behaviors or activities, where you're sending information from one site or one source to someone else. And right now, a lot of it is done within a single network. So, if you wanted to send a message to your MySpace friends from Facebook, that's actually really hard to do, if, in fact, nearly impossible.

We've had the same problem with instant messenger networks, where if you have a Yahoo IM account, you can't really talk to your AOL instant messenger buddies and so forth. So, a lot of this is trying to figure out how can we coop those issues and just make this stuff work for folks that they're not constantly having to choose new providers all the time.

One of the things that eventually, we'd like to do is figure out how to do sort of ad hoc groups, where you could throw up a new campaign site, like a CivicSpace site or a Spread Firefox, have a number of people join that site using identifiers or identities that they already have elsewhere, collaborate, do whatever they're going to do, even add friends that then gets added back to their master friends list. And then, they can go on their way once the purpose of that group has sort of expired.

This is actually a great segue into the social benefit angle to all of this. Is there any sort of civic action component to this? What are the real applications for social benefit that could come out of this, in your mind? Is there any vision that you have?

Yeah, absolutely. I think some of the biggest concerns or things that are motivating me here again goes back to sort of the CivicSpace model, where building one platform that you install one place and expect people to create accounts and move their entire social experience onto, I think, is not the solution for the long term. And so, part of this is to actually enable a couple things. One is for more people to be able to go and deploy these services and to compete on the quality of the service that they're providing, as opposed to just their lock in. And that's a change, I think.

So, I kind of look at Basecamp as being something where you go, you actually pay to use the service because it's a good service. There's actually support, so if things go wrong, there's someone who's going to answer your e-mails. And that's worth paying for. They're not all about lock in. If it's useful for you, you'll pay for it. If it's not, you won't. That kind of thing, I'd like to see a whole middle class of applications sort of spring up around that notion that are able to create businesses that flourish and that sustain themselves.

In terms of the social benefit, otherwise, I think that the hope is that people can actually use these tools for much more productive either activism or just pushing forward conversations with tools that make more sense. So, rather than, again, getting stuck inside a Facebook, where the tools may or may not be as good as you need them to be, the benefit now is no longer about well, let's move everyone into Facebook and only focus our efforts on Facebook, but let's build a tool or a site or whatever that allows everyone from all different networks to come together. And then, we can actually leverage tools that make sense for this particular environment or this particular challenge that go beyond what has been provided by these other platforms, that actually have to keep their tool set or their platform somewhat limited to either prevent abuse or simply make it possible to support those features and functionality.

For example, the functionality that comes by default from Drupal is much higher in some ways than what you can get from the Facebook platform, simply because you can install it yourself and you can edit every single aspect of an application. The same is not entirely true with Facebook where, of course, they're going to keep you in a sandbox and limit some of the things that you can do simply because of the sheer amount of valuable data that people have entered into that system.

Right. It's interesting because the medium still matters in so many ways. It has serious effects on non-profits and social benefit groups that just have limited resources. I did an interview with this girl, Carrie, from the Humane Society. She's very active on Facebook and on MySpace, but for totally different reasons. Obviously, that sucks up a lot of time, managing two different social networks to get two different benefits, whereas, they could ostensibly build their own system and get all the benefits of social media and only manage that one system that does everything they need it to do.

The fragmentation of groups across silos ends up taking a whole lot more energy than it really should, especially for those folks who are, let's say, smaller or less well funded, less well staffed and so forth. I think part of the real social benefit that I'd like to see is where individuals can actually do more good or contribute more to different projects that they believe in, based on the decentralized distributed nature of the way that the web really works today. And so, even if their group is 10 to 15 people or even three to five of their friends, they should be able to harness their local resources and put them into good use. And I think that that actually creates a higher level of engagement than something which I haven't actually used that much, Changes?

Well, there's Changes and Causes.

Causes, that's the one, Causes, where they send you a bunch of e-mails and they kind of try to get you to do things and so on. I do think that there are great tools that they provide if you actually get into that and you're willing to spend some time on those things. However, I think that there is also sort of a benefit to having individuals be able to collectivize themselves in environments that make sense to them and their friends, rather than, again, sort of like going to these new networks and having to reestablish their social capital and stuff like that.

Right because you show up and there are all these steps that you have to go through to be able to take advantage of the new network and the new features of the network, and it's a dead weight loss. How far out do you think this sort of thing really is? Do you see yourself as laying a theoretical groundwork or do you feel you're on a runway toward adoption?

It's a very valid question, and I think some healthy skepticism is useful. I think actually that we've made a lot of progress. We started this project in December, and admittedly at the time, the project was just kind of a lark. It was sort of one of those things where it's like, OK, what's the next thing? BarCamp is sort of now going on its own. They could actually use some of the things that I hope to drive through with the DiSo stuff. Coworking is kind of doing well on its own. These are all communities that I've been involved with and kind of helped get started. What's kind of like the next thing?

And I've been working in the Open ID community for a while. Then, the OAuth community sort of came around. I've been in the Micro Formats community a while. And I just kind of felt like, man, you've got all these great technologies and no one's really building something that demonstrates the value of them. Maybe we are living five years in the future. And OK, that's fine, but if that's the case, why don't we build that future we want to see now so that by the time everyone else catches up and they've all realized like gees, social networking's the future, and as Charlene Li likes to see, social networks will become like air and a part of the infrastructure, why don't we build that out such that just like the people who created the Internet did, there's some basic principles built into the architecture and the fabric of this thing?

So, to be more concrete, we already have a number of plug-ins created for WordPress. We already have a number of people. And through sort of evangelism efforts and working with a lot of these big companies in the space, we've worked with, convinced, been convinced or just had conversations that have led to them adopting a number of these technologies that are, again, forming the foundation of the DiSo project. Some of those I mentioned. Some other ones are sort of coming out soon.

One of the things that I am going to start working more proactively on is around trying to come up with a format for expressing activities between different sites. So, one of the things that's become pretty common and I've seen a number of either start ups or small sort of side projects get going around are these activity streams or life streams, kind of what Facebook popularized as the news feed. What are your friends doing, where are they doing it, who are they doing it with? And that's a very, very common pattern that we're seeing across a lot of sites. The problem, of course, is that if people are using diverse sites, two or three or even five, they're expressing what they're going to be doing. They're using Twitter to tell their friends what they're all about. Maybe they're buying movie tickets at Fandango.

It's kind of like Facebook wasn't wrong with Beacon. It just did it in the wrong way and did it in a very centralized, kind of skeevy way, where it crossed the blood and brain barrier kind of thing between a social space and a commercial space. To be more clear about that, essentially they're saying, "Oh, you're taking all these commercial activities out on the web. Why don't we bring those into your news feed and then, all your friends can find out about it and it'll be the marketers' dream."

Well, you're actually breaking a social contract there. It is interesting, actually, to know what your friends are up to, what they're doing, if they did just buy an album on iTunes or Amazon and so forth, but leaving it up to the individual to sort of push that back to their own network and to be somewhat judicious about who gets to see that stuff or why. I'm not going to just spam all my friends, telling them I bought toilet paper at Drugstore.com, but they might want to know that I'm going to some music festival in the fall or whatever, various little things like that.

So, anyways, that's one of the other things that's sort of realistic coming out of this. We're going to have a format for activity streams, a format for friends. We already have the protocol done for doing the authorization and permissions.

Actually, another thing that's come out of this, and this might be interesting to you since you're an Open ID user, we've worked lately to create this service called Emailtoid.net. And just last week at OSCON, we released a specification called EAUT.org for e-mail address to URL transform. And what that means in very, very simple terms, hopefully, is taking an e-mail address, which many people are familiar with and then, converting it into a URL that can be used as an Open ID. And the reason why that's important is two-fold. One is that we have found, and Yahoo's done some usability studies lately on Open ID, and we've known this, it's got problems. Let's just say that a lot of people don't necessarily think of themselves as URL's. But, they identify themselves more easily as e-mail addresses. And maybe that's just built up behavior and whatever.

But, the reality is that a lot of people are more comfortable using e-mail addresses. Clearly, a lot of websites are asking for your e-mail address all the time. You sign up for a new service, what's the first thing they ask you, "What's your e-mail address?" So, we needed to address that pain point and sort of make that issue a non-issue for Open ID. And so, we came up with a way of doing this that is a decentralized over the long term mechanism for resolving or turning e-mail addresses into website addresses. And not just solving that usability hurdle, but that from a development perspective benefit, allows you to then look up services. How would I describe it? For example, if I have an e-mail address, you could point to the place where you store your friends' list. And then, using that authorization protocol, a remote website could ask you, "Hey, do you mind if we see your friends because you're looking to share this thing with your friends, and so, we need to know where they are?" And so, that whole process could be automated through using this protocol/format. Does that make sense?

On a high level, it does make sense. Conceptually, I'm understanding that's the way things are going to go.

Let me give you an example. The main way in which this would work, let's say you go to a brand new site you've never heard of before. Your friend just sent you can e-mail about it. It was like, "Hey, dude, I'm joining this new group. It's awesome. We're trying to do something great. Let's call up BarackObama.com." And you go there, and as it is today, the first thing that they ask you for is your e-mail address and your ZIP code. But, supposing that they actually supported this EAUT transformation or allowed you, let's say, to use your e-mail address as your Open ID. The very second step of putting in your e-mail address would be to confirm yes, indeed, this is your e-mail account. Or, it would then bounce you over to your Open ID provider.

Now, where the benefit comes in, both to that site and to you using a known identifier like your e-mail address, is that then, Barack Obama can say, "OK, well you're signing into our site, you've proven that you own this e-mail address. Well, the second question that we're going to ask you is do you have some friends that you'd like to tell about the site?"

And you can, at this point, say yes or no. No, actually, I don't want to share this information. Just take me back and I'll explore this thing, whatever. But at some later point because the Barack Obama website or whatever has that identifier for you and knows that you are able to verify it, later on when you're browsing through some content or something like that and you're like oh, I'd really like to share this article on my favorite book marking site, well rather than giving you 40 different buttons, Mix and Buzzed and Dig and Delicious and Magnolia and all these different buttons that describe where you might want to share this thing, at that point, BarackObama.com or whatever could go back to your Open ID provider and ask, "Hey, does this person use any sharing services?" And the provider would say, "Oh, yeah, actually, they use Magnolia, or oh yeah, actually, they used another service called Mento," which Barack Obama never heard about before. Now, it goes back to sharing that article, and it's able to show you, "Share this functionality that actually you're familiar with and you want to use." And that's all advertised kind of like in the open because you want to have a better experience. It's sort of like moving your preferences around. And that was all done just by being able to use your e-mail address as an Open ID, so that's that benefit.

Understood. I have to ask, you mentioned OAuth before as something that has come out of DiSo?

The OAuth protocol is actually an extraction of a number of other protocols that already existed that were being provided by Yahoo, Google, Flickr and the rest. They essentially all do the same thing. And if you've ever used a Flickr uploader, you kind of know what the process is like. Essentially, you download an application. And rather than putting in your user name and password into this application that may or may not be trusted, instead, you go back to the website that you actually want to either upload data to or get data from and so forth. And you give it permissions at that point. So, you only ever share your credentials with the site that actually issued the credentials. So, you're not, again, spreading your password all over the place.

And so, that's what the OAuth protocol basically, is designed to solve. But, it also is designed to solve that problem in the mobile experience, as well as over API's and things like that. The reason why we developed OAuth was to solve a problem that actually we discovered in Open ID. And so, the problem we discovered with Open ID was that if you want to, let's say, sign into your Magnolia account using a dashboard widget or a gadget on Windows and you had an Open ID, well these widgets don't actually know how to deal with Open ID. They know how to deal with a user name and password.

And so, we developed this protocol, looking at everyone else who had solved this problem by essentially having you click a link that takes you to the site that you want to share it with, log in there, and then, it sort of provides a temporary or an individual, unique password that grants that little widget or application access to your account.

What's great about OAuth is that at any point, you can actually revoke the privileges that you've given to one of these applications, as opposed to changing your password and breaking all different places that you're using those things to work.

I'm curious because I've heard about OAuth. It's come up, obviously, people are blogging about it. And I interviewed Scott Stadum, who's the guy at Idealist.org. He's really excited about it, too.

Really, now what did he say?

Basically that his interest in data portability, Idealist only has so many resources and they're trying to consolidate all of their efforts across all these different social networks to be able to securely authorize or allow their users to authorize access to their data is a big bonus. It streamlines a lot of that process.

Well, the nice thing about it is that it's designed to be sort of a conventional specification that behaves in the wild like a standard. The major difference, and I don't know if you caught this, but last week, we announced the formation of the Open Web Foundation. We're putting out the Open Web Foundation kind of in recognition of some pain that the grassroots community creating a lot of these social technologies have been feeling. Whenever we try to put out a new technology and get large providers to adopt it, essentially to lower the cost to many developers by minimizing or making nil the differences between different protocols that do, essentially, the same thing, you run into problems, where all of a sudden, one of those companies could have intellectual property, patents or things like that in that space.

The reason why I bring this up is because OAuth is kind of going through that now, where it will have the properties of a standard, in that you should be able to, over time, ideally, expect that different providers or different service providers or web services that have an API will be using OAuth to do all the authorization type stuff. And so, what you'll do is you'll just grab libraries of code that other developers have written and tested and made sure that they're secure, and you'll just use those to replace all the stuff before, the user name and password stuff.

And so, that lowers the barrier to adoption. It lowers the friction. It also creates a pattern that I think end users will become familiar with. And they'll understand, hopefully, over some period of time, maybe the next couple years. And it also again, sort of goes back to that original point of helping people do the right thing by making it more easy and cheaper to do the right thing.

Yeah, to just do, right?

Yeah. There is no other way. It's like "This is the way it's done, this is how you do it and this is how you solve that problem."

And it's secure.

It is. Again, it was an extraction from what these sites were already doing, but it just kind of normalized the different names, the variables and the different sort of approaches to dealing with the security aspects.