This guest post is written by Kevin Marks, Developer Advocate for OpenSocial at Google. Over the last 20 years he has alternated between giant companies and founding startups – BBC, The UK MultiMedia Corporation, Apple QuickTime, Technorati and now Google. He is one of the driving forces behind microformats.org and advisor to the Open Rights Group. He wants you to remember that URLs are people too, and his URL is http://epeus.blogspot.com.
In this Q&A-style post, Kevin delves into the standards that make up the emerging open social stack (OpenID, OAuth, Portable Contacts, and OpenSocial), looking at the infrastructure problems they address, and exploring some of the live implementations, including Plaxo and Google Friend Connect.
Q: We keep hearing that “Google wants to make the web more social.” What does that mean?
Everything on the web is more interesting when it takes place with friends. Today’s social networking sites, are the online contexts where you and your friends go to be social, and the time we spend on them shows the attraction.
But the model of going to a single website to interact with other people is changing. In the future, we expect everything on the web will become more social, augmenting the many things you already do on the web. Whether you’re shopping, deciding what to read, or researching a topic, knowing what your friends, or family, or the people you respect think about that product, book, or source of information is a vital part of the web.
I call this the “social cloud,” meaning that “social” will be integrated with the web so that you don’t think about it anymore. Charlene Li calls this same idea “social networks become like air.” The web itself is like this — following links seems like second nature to us because we know a URL can take us anywhere. Social isn’t there yet, but that’s the highest level goal of the OpenSocial project — to make interacting with people a natural part of how we use the web
Q: What are the hurdles to the web becoming more social today?
For every website to become social, each site needs to know something about you and who your friends are.
How do they solve this now? By asking you to fill out a form and by spamming all your friends. For many people, that’s enough of a deterrent that they will simply leave the site. For others, there is no value to providing personal information to yet another site, so they lie. If you’re forced to enter a zip code, you tell them 90210 or 12345, and websites end up puzzled by how many users they have in Beverley Hills and Schenectady.
Then, once you’ve done the whole registration “song and dance” (submit your email address to the site, login to your email, check the spam folder, then click a link to go back to the site), you still have to find all of your friends on that site and establish those relationships again each time you join a new site.
This model doesn’t scale because users end up only joining a small number of sites, and it doesn’t help the web as a whole become more social when most sites have inaccurate information about their members. We need open standards to enable the exchange of this kind of information.
Q: How do OpenSocial and open standards help?
There are three main components to social activity on the web — people, friends, and activities.
Representing people has several aspects. First, there is the notion of identity. Email addresses are one way to identify people on the web, but as social networks have become increasingly popular, personal profiles (and the unique URLs that go with them) have emerged as a common way for people to find and connect with one another. OpenID is the standard that lets you prove to other websites that you own such a URL, thus letting you link your online identities.
Then, to represent people more fully within OpenSocial, we started looking for things that social sites have in common. We talked to many social networking sites, looked at their data structures, and found that they were actually very similar. Under the hood, most of these sites had names, photographs, addresses, phone numbers, preferences. Based on these commonalities, we defined a model for representing people. This model is expressed in the Portable Contacts standard, which is also used in OpenSocial for people and friends.
What makes these sites different from each other to their users are the communities of people who inhabit them. You’re happy to share information with people you know and trust, so long as you’re confident the website won’t share that information with anyone else. The most successful social sites, therefore, become trusted custodians of your social data.
This brings us to the second component of social activity: friends. Once we can represent people, we need a model for who your friends are and which friends can see what information about you. Within a site, this is straightforward because the site is in control, but in order for the whole web to become more social, there must be a way to share this information between websites. That’s OAuth.
Today, if a site wants to know who you’re friends with on a social site, it will often ask you for your user name and password. The site will then login to the social site with your user name, pretending to be you, look at the webpages there, and pull the data out. The problem is that by handing over your credentials, you’re also giving the site full access to everything in your social account, relying on faith that it will only do what you want it to do. But what if you accidentally give this information to a malicious site? What if the user interface is confusing and you accidentally let a site send out emails to your whole address book?
By contrast, OAuth lets you grant permission for very specific tasks. You may let another site see all your profile data or just your name and image. You may let it see all the people you know or just a subset – your family or colleagues. Additionally, OAuth lets the social site know that a request is being made on behalf of a specific user, so if the social site reveals different information to different people, that can be taken into account, e.g. if you share your photos with some friends but not others. As the web becomes increasingly social, having an standard protocol to express this from website to website is very important.
The last piece of this social web is activities — what you and your friends are doing around the web. Leisa Reichelt calls this “ambient intimacy,” the idea that you care little about the activities of strangers, but you’re very interested in the activities of people you know. What is more, with your close friends, you care what they had for lunch, how they’re feeling, and what they’re thinking. This flow of phatic information makes social sites like Twitter, Facebook, MySpace, Flickr, Seesmic, Picasa, et al., enormously attractive — they feed a basic human desire to know about others.
The challenge with sharing activities is that it can’t be a chore. This is why OpenSocial allows any application to generate an activity and provides a way to send those activities from one place to another. The social networking site can then filter those activities in a way that makes sense for their users.
When these events flow from one place to another, everyone is better off. If I can bring the information I have invested in a social networking site elsewhere, to say, a Bay Area biking website, when I post a comment like “I just rode this trail, here’s a photograph from the summit,” the site can feed that information back to the network, where my friends who are also interested in cycling can click over to the biking website. Additionally, other bikers on the website can see me, recognize that we share an interest, and establish a relationship within that context. Social networks get richer information, the cycling site spreads through friendship networks, and users get the benefit of being able to control what they share with whom.
Q: We’ve also heard that Google wants to open up the social web. What does that mean?
When I talk about OpenSocial and “we,” it’s important to remember that OpenSocial isn’t a Google project. OpenSocial is an industry-wide standards effort. From the beginning, we worked with many other groups to put this together and to form an independent foundation. All of the standards work is public, and it is very much an open dialog.
We also don’t want to reinvent the wheel, so OpenSocial uses existing standards whenever possible. The OAuth standard and Portable Contacts are both examples of this. The person specification in OpenSocial is the same as the Portable Contacts standard, which was developed in parallel. This allows people to use only those components that they need, while still being compatible with the entire OpenSocial specification.
We’re looking for interoperability not just with shared standards, but also with shared code, and so the community has also built open source implementations. For example, the core social networking server for Google is Shindig, an Apache open source project with both Java and PHP implementations that is used by many of the large social networking sites.
This is important because these standards have applicability beyond just social networking sites. They work for personal dashboard sites like MyAOL, MyYahoo, and iGoogle, as well as sites that are not purely social but are still designed around people — e.g. LinkedIn, Xing, and Viadeo. Their primary focus is on business, but having a standard model for people and for activities is still useful. Similarly, Portable Contacts maps well to other sites with people lists, such as webmail, and the open source gadget standard has been broadly adopted by different companies.
Q: What efforts are underway to make it easy for people and websites to use these standards?
For more websites to become social, they need to be able to connect to this infrastructure. While we have defined the REST APIs and are providing client libraries to access them, there is still a lot of integration work that needs to happen in order for websites to adopt these standards. As these roll out across more social sites, the rest of the web gets even more value from calling them.
There was a great example of this recently, where Plaxo demonstrated how they saw a 92% update rate using OpenID, OAuth and Contacts API to let users and their contacts onboard in one step rather than by asking for passwords and scraping.
Ning approached this integration problem by making it easy for anyone to create a social network for a specific group of users — church groups, soccer teams, any interest group – even the OpenSocial community itself. Their adoption of OpenSocial means that many more niche social networks will be able to use these social applications.
Another example is Google Friend Connect, which is designed to let any website become a social website as easily as adding Google Maps. Just add a small amount of Javascript and couple of pages, and suddenly users are able to sign in to the site, interact with each other, and comment. Friend Connect runs code on our servers to connect these open standards — OpenID for login, Portable Contacts and OAuth for connecting your friend lists from many sites, and OpenSocial for creating applications. Additionally, you can send your activities back to your social networks, using OAuth and activity streams.
Q: What can we expect to see more of in the coming weeks and months?
I’ve talked about this at several different layers — the aspirations and barriers to them, as well as the implementations that we have seen.
At the moment, OpenSocial is deployed to sites representing over 700M users around the world and this is growing consistently.
Friend Connect is running on tens of thousands of websites, drawing more users and more connections every day.
As more sites start to implement these open APIs to allow connections between sites, these virtuous cycles will become more obvious and we’ll start to see a second degree of growth in connections between sites, not just within sites.
I also expect to see a slight transition within the application space from apps for individuals to apps for groups. With Ning and Friend Connect, we see groups of people associated around an idea or a website. As developers start to see this, I expect we’ll should see some exciting applications that are deployed across websites and a strong movement towards the pervasive web sociality that is the high-level goal of OpenSocial.
The future of OpenSocial isn’t a fixed roadmap, it is an open mailing list where future specification changes are discussed, with working examples expected. Among the topics currently being debated are realtime chat , an Albums API to share users’ photos and other media, and a virtual currency model for Application developers.
As the consensus around these composable, open standards grows, and more and more sites implement them, we are making the web pervasively social for everyone online.