Google Data

Posted by Dan Peterson, Product Manager

As OpenSocial evolves, we're eager for websites to be able to host OpenSocial apps. To that end, we released an in-memory container sample which includes an early glimpse at the Service Provider Interface (SPI) layer, and you may have heard about the Apache Shindig project proposal, which we're quite excited about. We're still iterating and thinking through some of the open questions, but we wanted to let you know what we're thinking about so we can get your feedback. Here are the highlights (there is a more detailed forum post linked below as well):

Privacy and Security:

Given that OpenSocial lets developers create applications that build upon users' profile information, we need to be especially careful with authentication and permissions. In the last blogpost, we talked about a proposal for a trusted version of IG_Fetch_Content, which leverages pieces of OAuth, to help address the trickiness around cross-domain authentication. Additionally, from a privacy perspective, there is an important difference between the owner and viewer of a particular app. When you are browsing a social network, you often end up on someone else's profile page -- that makes you the "viewer," and them the "owner."We plan to add an API that lets app developers handle this situation while respecting the container's privacy policy (e.g. if an app wants to perform some operation based on who the viewer is, it may have to prompt for the user's permission).

API and SPI iterations and refactoring:

OpenSocial is young, and we’re iterating quickly to extend the initial 0.5 spec. One improvement is to cleanly separate the API for app developers from the SPI for container implementors. This split is important to serve both audiences well: the former want a clean, convenient interface for building app; the latter want a clean interface for connecting those apps to their websites. Another improve is to add support for parts of the Google Gadgets API. There is a fairly broad scope to the Google Gadgets API, and, while we're eager to let all gadgets run everywhere, it seems best to start with the bare essentials. For the short term, we've heard that equivalents of IG_Fetch_Content, IG_Adjust_Frame_Height, and IG_Register_On_Load_Handler are crucial components that all containers need to support; if your OpenSocial gadget definitely needs something else, please let us know in the group.

Shindig: open source OpenSocial reference implementation

We're very excited to hear about the Shindig project proposal that is being put together for the Apache incubator, and we'll be contributing both code and engineers to the effort. Shindig hopes to provide a reference implementation for sites that would like to host OpenSocial apps; more on that as it happens.

Policies (gadget directory, discovery, and abuse)

Outside of the more technical conversations, there are many important policy questions. To name a few: How do users discover applications? Is there a central application directory? How can apps let viewers easily “get their own” copy of an app? What happens when an app is reported as malicious?

We’re still working through many of the specifics, but we’re attracted to the idea of an opt-in unified gadget directory as it would let developers have a single point of entry for listing their apps, and let containers offer a wide variety of apps with little effort. In addition, it would potentially allow for unified malware and abuse detection, and some global rankings.

Server-to-Server APIs:

The OpenSocial docs include an early iteration of the server-to-server API spec. We've heard from gadget developers that, although those APIs will be useful, it is fine to have a consumer beta release without them. This also makes it easier for containers to host OpenSocial apps more quickly. Therefore, we are working on the server-to-server API spec in parallel with the JavaScript API spec, but we are not gating on it.

***

Most importantly, we need your input. If you're considering hosting OpenSocial apps on your website, please review this more detailed forum post and provide your thoughts, concerns, and requirements.


P.S. For this and all future posts, we've turned on blog comments, and we welcome your remarks here. However, for more in-depth comments and discussion, we encourage you to use the OpenSocial group.