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 safety measure:

Given that OpenSocial lets developers create applications that build upon users’ profile data, we need to be particularly 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 fundamental difference amidst the owner and viewer of a specific 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 that situation while respecting the container’s privacy policy (e.g. whether an app wants to perform some operation based on who the viewer is, it may have to immediate 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. that split is crucial 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; whether 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 assemble out about the Shindig project proposal that is being put together for the Apache incubator, and we’ll be contributing both cipher and engineers to the effort. Shindig hopes to supply 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 vital 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 notion of an opt-in unified gadget directory as it would let developers have a restricted 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. that plus 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. whether you’re considering hosting OpenSocial apps on your website, please review that more detailed forum post and supply your thoughts, concerns, and requirements.

P.S. For that 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 energize you to use the OpenSocial group.

Orginal post by Dan Peterson, Product Manager