The OpenSocial 2.5.1 Activity Streams and Embedded Experiences APIs is part of the larger OpenSocial framework. The submission consists of two distinct APIs, one of which is a REST API for manipulating ActivityStreams and the other is a Javascript API for embedding the launching of third-party applications in response to user reactions to an activity stream. The use-case that motivates this API is the processing of activity streams and activity-related events inside the browser.
The first part of the submission is an REST ActivityStream API that specifies how to use HTTP methods to find, create, and delete ActivityStreams. The use of HTTP GET, PUT, and DELETE for activity streams is straightforward.
The second part of the submission is an API for "embedded experiences". The general idea is that a third-party activity stream is embedded within a web-page, as is currently done by most social websites using proprietary interfaces, and the API allows actions and preferred visual rendering to be associated with the pure data given by the activity stream. The central innovation of this API is the launching new applications within the same browser window in response to actions by the user on embedded activity streams, which lends the API its title of "Embedded Experience." Typically, this kind of embedding of browser context is done with the iframe element with optional sandboxing to allow it to communicate with the originating context. Embedded experiences allows the limited passing of contextual data using a context parameter. It also features a URI for the application definition, as possibly given by a Gadget XML location. The "preferred experience" allows some default rendering of the activity stream to be given.
A concern with this API is that while it currently claims compatibility with any packaged Web application, it is for historical reasons dependent on the OpenSocial Gadget framework. Note that an earlier deployed Gadget framework, the Google Gadget framework, has fallen out of usage. Even Google has begun deprecating the Google Gadget framework in its products. Any future work should be simplified, and therefore remove any normative dependency on OpenSocial Gadgets as well as any reference to Google Gadgets, so that the scope of embedded experiences is not restricted to Gadgets. This will accomplish the goal of including a wider number of use-cases and the variety of the technologies that are part of the Open Web Platform
Substituting widely-used web standards from the Open Web Platform will likely simplify the work and produce a mutually beneficial relationship between OpenSocial and the Open Web Platform. For example, the Activity Stream API, XRDS-type should be removed in favor of use of URIs with the ActivityStream media-type. Inside of the Embedded Experience API, HTML Imports could be used rather than Google Gadgets XML URIs, and we could allow the removal of XML as a data serialization. The passing of context could be done via postMessage with security guarantees made by Cross Origin Resource Sharing (CORS). The embedding itself could be done by Web Components (such as Custom Elements and HTML Templates) for preferred rendering and applications. The problem of user approval and the performance of "secure rendering" is likely related to chartered work of the WebAppSec Working Group on UI Security.
The 2013 W3C Social Standards Workshop gathered the use-cases and requirements, including discussions of OpenSocial and Web Components. This workshop followed the well-attended W3C Social Business Jam online event.
The agenda for the W3C Social Standards workshop has several papers and positions that are directly relevant to OpenSocial.
A new draft of the ActivityStreams 2.0 specification, built on top of JSON-LD, now exists and should be moving into W3C as part of the proposed Social Web Working Group. The use of HTTP verbs to modify linked data (such as given by JSON-LD and ActivityStreams 2.0) is also part of the Linked Data Platform.
This work is in scope as an input to the proposed Social Web Working Group charter. If the Social Working Group charter is approved, the functionality given by this submission may be within scope of the "Social API" part of the Working Group charter. There is also the possible input of the updated JSON ActivityStreams Action Handlers work.
Future efforts towards an OpenSocial API should coordinate with the HTML5 Working Group in order to fully incorporate Web Components and HTML imports. The passing of context can be done via using CORS and postMessage, and take advantage of new chartered work by the Web Application Security Working Group on UI Security.
Continuing discussion of this topic is welcome on the mailing list in the Social Business Community Group's public-socialbizcg@w3.org (archives).