Kevin Marks: OpenSocial is way for application developers to use existing social networks to their advantage. It provides an abstraction that means you can write your application and use the friendship data that social network has already gathered on behalf of their users. So it’s basically a way of freeing you from having to create your own registration database and user-connection database for your application at the end which it uses the many different social networks that have popped up in the programming, including MySpace and Orkut and hi5 and Bebo.

There are three main components to the way the APIs are setup. There is the People and Friends API which lets you discover who the viewer is and who the owner of the application is and who their friends are, and use that within the application. There is a Data Persistence API which lets you store information within the social network site and retrieve that based around the users for your application. And then there is the Activity Streams API which lets you post events to an activity stream which is a feed of events that the user has created and it will setup your application, read from activity streams of events that the user and the user friends have created within your application, so you can see a flow of events that people have created.

Kevin Marks: It has something we’ve been iterating on quite a lot with the partners and there’s going to be a new release very soon.

One thing that has shown up already is the Shindig open source project which is being done in the Apache Foundation. That is designed to provide an open source implementation of the entire OpenSocial stack so that you’ll be able to install this on your own website and create your own OpenSocial containers very easily.

The first commit to that went in on Tuesday this week, the 11th. That week, we expect that to be a core part of the project. That took a little while to setup because it’s actually a proper Apache project outside Google. It’s not just Google committing to it. Other partners will be committing to that as well over time. So that is being setup to do this is as a fully opened project.

Sean Ammirati: I think that is helpful in terms of the goals and this Shindig project, but I may have misinterpreted this at Defrag, but I interpreted you coined it alpha to a large extent because you’re trying to get feedback form the community and there are relatively a few number of partners who had deployed this infrastructure within their social network although a lot had committed to doing it. My sense is that that’s still where we are, but I wanted to see if that was your sense as well.

Also, we released a sample container which means that you can write an application and run within that. That’s hosted on your own machine to experiment with. That also provides a clearer guide to implementing a container then was there before, and we expect to continually push out more code to make it easier for you to implement this. So we expect to see that will result in more containers putting up public implementations as opposed to private experiments that they’ve been doing among with gadget developers.

Kevin Marks: I can’t make a commitment on their behalf but they’re very keen on working with us and pushing ahead.

Sean Ammirati: Sure. I guess the point is that I still feel like, in general, MySpace, a number of these people who announced the support for it which is great, they’re still in the process of rolling it out, right? So this obviously is still fairly early in the game but important work nonetheless.

Sean Ammirati: Interesting. Anything you want to preview about the new release?

Kevin Marks: No, I don’t want to preflight that without –

Sean Ammirati: Yes. I figure as much but I had to ask. So there’s one more question like that that I have to ask, Kevin, and then I promise we’ll get to activity streams. With the Facebook and Bebo announcement, how do you see that playing into OpenSocial? Any hope to see Facebook, maybe, join the project?

OpenSocial is built on using existing web standards, of using HTML and CSS and JavaScript to write the applications and proving a JavaScript library for the social components of that. Whereas, the Facebook model is about having their own layout and their own query language.

So there’s a difference of approach there, which means that they can be complementary. It may be that we could combine some of those features. Maybe Bebo’s work could do that, but from our point of view, we want to make sure that we are going with a web as the platform rather than trying to build a separate platform.

Kevin Marks: Well, the idea of activity streams is the flow of events that you create within the social application. One of way of thinking about it is like feeds that you already have with blogs or with other existing social services like in del.icio.us where they would generate a feed of the stuff that you create in that, and you can then combine that to other services through a feed reader. If you look at many of the existing sites, they will let you import feeds and bring them into your social networks and combine them to show events that you’ll be having elsewhere. Orkut does that. Plaxo does that. Jaiku does that. There’s a bunch of services that do that.

The main thing that adds over the data store is a sense of time. You have a sense of when the events occur and the flow of time. I expect that different applications will filter these in different ways and present them differently, but the main idea is to use the existing infrastructure of feeds that have already been built out and combine it with the social networking world.

Kevin Marks: Yes. We expect the social networks - it’s within their control to decide which events to show and where, and present them as part of the main API. So some of them move all of them and some of them filter it out.

Sean Ammirati: In terms of reading, in terms of pulling activities out of the stream, will OpenSocial apps be able to pull of the activities or will that also be filtered?

Kevin Marks: That’s under the control of the container. The basic idea is that your app will be able to certainly get its own activities back, but it should be able to get other activities too.

Sean Ammirati: OK.

There’s a difference in kind between some of the social networks which is that many social networks are what we call performative where you’re basically showing off stuff to the world you’re performing. If you think about MySpace or Orkut, they’re primarily of that kind. Most of your stuff is public by default and you’re creating a public view of yourself.

Whereas, there are other applications that are more for controlling your own set of friends and not really doing it as a performance. You’re doing it, and that’s all for yourself. The original Plaxo is very much like that. That is for keeping track of your contacts and friends’ names and addresses and so on.

So there’s a difference of kind in there between whether you’re naturally performing or you’re just naturally classifying information to yourself. So what your application will have access to would depend on the privacy policies of the social network it is running within. What that means is that your application doesn’t have to do the work of setting up that privacy policy. The user has an expectation of how the network they’re running in behaves, and that will be projected onto your application. So you will make the “get friend’s call” or whatever and the result you’ll get will depend on the policy of the container.

The same is true for the activity streams. You will be running within the policy of the social network that’s containing your application.

Kevin Marks: Sorry. I do what?

Sean Ammirati: I’m saying I know a lot of your role as a developer advocate and sort of an evangelist to the community, but you also are interacting with the containers, the people who are supporting OpenSocial. Do you have a sense as you talk to them? I guess, first of all, has there been anybody who has deployed the activity stream component to OpenSocial live right now? Second, do you have any sense on what the excitement level is around this relative to the other two components of OpenSocial?

Again, it varies between containers. Other sites will make it a big or a smaller part of the interface depending on how their site feels.

For myself, at the moment, feeds are a bit of a minority interest if you think about it. People, there are a bunch of us who use feed readers all the time and keep track of things that way. But there are some barriers to discovering them and copying the URLs and connecting stuff together there. One of the hopes is that this will make it more straightforward to do so because it will be a natural part of the social networks to connect these apps.

Sean Ammirati: Yes, I would agree with that.

One of things, I guess, I was curious about though going back to your two types of social networks, the performance type and then the server controlling an app for yourself. This question, I’d like you to actually boil back up to talk about the three different components of OpenSocial. How different do you think the uses or the ways a developer would deploy an OpenSocial app? How different do you think they are if they’re trying to gear that app for a performance network versus for controlling an app for yourself?

With the networks that are strongly browsing folks, they will be able to move this info from other people’s feeds. The owner of graph becomes much more important, whereas for the ones that are personal, you tend to find that the viewer nearing with the same person in most cases. You’re looking at your own dashboard of information and you’re not browsing other people’s view of it. So what you’ll see is an interaction between which of those two are most important to your application, but that is not the way of characterizing it.

So there, the context would feel different to the user, but to the application, it would look the same. You’d have these two sets of people in relationships that you could manipulate and send information about.

So rather than the app trying to subsume the function of your cortex and mapping people’s relationships, the app is just able to say, “OK. This container has some information about people. I will reflect that back to you and then you can make the decisions about which ones to click on and which ones to make sense of.”

Kevin Marks: You mean a way of categorizing the applications that different people write?

Sean Ammirati: Yes. I hadn’t really thought about it, but the viewer and owner thing is one interesting way. This app is targeted at viewers. This app is targeted at owners or targeted at both. As I see different OpenSocial apps, I sometimes struggle at putting them into categories of other similar applications. I’m curious. How are you guys doing that at Google?

Sean Ammirati: That’s interesting. What other feedbacks have you gotten from the containers?

One of the things that we discovered was that we needed better security in the method to call out to remote applications because if you’re doing an HTTP fetch over the network, that would be potentially spoofable, so there’s now a protocol within OpenSocial being designed to sign those requests so that the application server can know that it has come from a particular container and that the user ID that container is parsing hasn’t been tampered with. So that’s something that has been added since the initial release. That’s using the OAuth signing method to do that.

Kevin Marks: One of the things that they were interested to know was if there’s more than one place the applications can run, if there’s a profile surface or a full-screen surface, could they have information about that. So that’s something we’ll be adding too to let them have more introspection into which environment within the containers they’re running it because that will allow them to make different decisions on layout and information based on knowing what kind of context they’re running in.

That’s a case, again, where we have to look at several of the containers and say, “What are these places that these run in?” What’s the difference between them and come up with commonality there.

Kevin Marks: [Laughing] The broad thing is much more potential users. There’s a much larger user base across many more social network platforms and in many different countries and social groups that aren’t just the demographic that Facebook already has. One of the reasons that Facebook got a lot of attention is that it has moved into the university educated people working for U.S. corporations’ demographic very strongly which makes sense given its roots. So those of us who work in the industry are suddenly aware of it, but there have been social networks out there for 10 years or more who have been gathering users and clustering in different places, and this is just the one that surfaced within our homophylic demographic so there’s a wider world out there with just Facebook, and that’s the key thing to think about when doing this.

So I would expect to see lots of smaller applications rather than the very large scale ones because they’ll be able to run them in a self-contained way without having to do a server setup as well.

Kevin Marks: Great. Thanks very much.

Sean Ammirati: Thanks.