The current public certificate is called ‘opensocket-key-1′ and can be downloaded here:

• http://www.opensocket.org/keys/opensocket-key-1_certificate.txt

This should be copied to your own server’s key cache once only, and should not be downloaded dynamically during execution. If we need to change the key in the future, we will give advance notice. So it is a good idea to subscribe to our RSS feed so that you hear about it.

For example code showing how your server can verify signed requests see Validating Signed Requests in Orkut. Of course, validating requests from OpenSocket works the same except you need to replace the certifcate text with OpenSocket’s; and the key name you expect should be ‘opensocket-key-1′ not ‘pub.1199819524.-1556113204990931254.cer’ or whatever Orkut requires today.

Open Social API

DataRequest

• Fetch Activities Requests
• Fetch People/Person Requests
• Fetch Person AppData Request
• Update Person AppData Request

Other Requests

• Share App (displays invite dialog)
• Create Activity (titles only - media items not supported)
• Permissions

Other

• Get Environment

All Open Social classes and methods are implemented but might not fully operate. E.g. newMessage will work, and requestSendMessage should not produce an error, but no message will be delivered as yet.

Google Gadgets API

Core features

• Prefs
• io
• json
• util

Optional features

• MiniMessage
• Tabs
• Flash
• rpc
• Views (find out if running on profile or canvas)
• Skins
• Dynamic Height
• Set Title

Some of the optional features may need a small amount of work. Just let us know if any parts could work differently. We really need to see more ‘real-world’ gadgets running through OpenSocket to be sure gadgets work well within the Facebook environment.

We’ll update this post as new features are polished up.

Update: makeRequest now works with Signed requests (see next post) and also type FEED.

The kind of ‘competing’ service we’re talking about here might be the Ruby framework which provides an interface lying somewhere between Facebook’s and Open Social’s, and takes care of translating that interface to the social network you want to run it on. Other comparisions might be to the widget distribution companies such as Clearspring or Widgetbox; they allow you to track and share images or flash across all sorts of web sites, including Facebook and all the other major social networks. While they have the breadth, however, they don’t really have the depth, and developers cannot use them to integrate with a social network’s friend lists and other essential components.

Yet another widget company has developed a proprietary HTML-style standard (or, more like, FBML-style standard) that it can translate to work on Facebook or Open Social sites. This is useful, although lacks the full functionality of either platform. Also, the proprietary nature of the standard makes it a risky choice.

All of these options allow you to save time and development effort when targeting both platforms. However, none of them offer access to the full functionality of both platforms.

Neither does OpenSocket. What we’re trying to do is bring a widget platform to Facebook, as an option to developers that is separate to the existing Facebook Platform. We believe that Facebook is not currently a widget platform, and that there is room for widgets alongside the full-featured apps that can be built on the native Facebook platform. So OpenSocket is not for developers building Facebook apps. It’s for developers who have built Open Social widgets, and want to see them running on Facebook - if only it was a widget platform.

We’re trying to make sure OpenSocket works naturally within the Facebook experience. But we’re not trying to replace direct programming of native Facebook apps. OpenSocket brings to Facebook all the features you are used to in other Open Social platforms. Beyond the initial spec, gadgets do not need dynamic hosting capabilities. Your gadgets are still client-side heavy, and proud to be that way.

So that’s who should use OpenSocket: Open Social authors. Not Facebook developers. Just Open Social authors who want their gadgets to operate on a Facebook widget platform.

The OpenSocket Facebook app acts as a control panel for you to register your gadget, and it also guides you through registering your own empty Facebook app. OpenSocket will then automatically configure your Facebook app to present your gadget to the app’s users.

Please try it out, but remember it is only running in beta at the moment. We are really looking for your feedback at this stage, so please get in touch to tell us about your experiences.

As far as Open Social goes, we support people and persistence data right now. Most of the normal iGoogle libraries should work fine.

More information about the service can be found in the FAQs within the OpenSocket control panel app.

A control panel Facebook app will allow you to register a gadget that you would like us to wrap into your own Facebook app. It will guide you to register a Facebook app in your own name, then help you fill in the settings so that we can take care of everything else - including hosting the application!

So if you have developed (or are thinking of developing) any Google iGadget or OpenSocial widget, please get in touch giving your gadget URL if you already have one:

• betatest@opensocket.org

No gadget is too small or specialised or niche! We love your gadgets as much as you do!

We look forward to seeing what you’ve created, and helping you port it to Facebook with minimum hassle.

The Shindig project, championed by the Ning team, has been set up within the Apache Foundation in order to provide a solid reference implementation. Now Google have offered their support, and even hope to use it in their sites. The OpenSocket team will also contribute anything we’ve learnt about building gadget support into a web site.

So we are no longer planning to release a separate code base for OpenSocket. The Facebook-specific components of OpenSocket will be developed independently, and we will provide this to gadget developers in the form of a service.

We believe it is in the interest of Open Social gadget writers to be able to publish their gadgets on Facebook, but do not feel it is necessary or advisable for them to have low-level access to the OpenSocket technology. Also, we had concerns that users running arbitrary third-party gadgets within our Facebook app would cause us (as the operators of the OpenSocket app) to essentially defer our responsibilities under the Facebook terms-of-service to any gadget writer.

Our solution will be for individual gadget writers to register their own Facebook app, but point the settings directly to our servers so that we take care of the gadget conversion and hosting. For the end-user, this will be slightly less flexible - they will no longer be able to try out any gadget URL unless it has been wrapped already. But for gadget writers it will be far more convenient to wrap and promote their own app, which would then represent itself in the Facebook news feeds etc, rather than being trapped within an OpenSocket window onto the Open Social world.

Any questions or suggestions are welcomed. If you are interested in wrapping your gadgets, please get in touch! Distribution and hosting partners are also sought.

The actual application linked above is for demonstration purposes only, and the framework will allow developers to set up a Facebook application to wrap their own OpenSocial gadgets only - a general purpose container as showcased here is not suitable for non-technical users since arbitrary third-party apps will be able to access unwitting users’ Facebook information.

This release was written by Dan Lester (me) with invaluable help, support, and advice from Ignacio Blanco. It could not have been completed without him, and I am thrilled to have made a new friend through this project!

Features of the current release:

• Supports all Google Gadgets of type ‘html’
• Gadgets requesting version 0.5 of OpenSocial will have access to the OpenSocial functionality implemented so far
• Person and People data fully supported, typically ‘VIEWER’ , numeric id, or ‘VIEWER_FRIENDS’
• Data Persistance - strongest support at the Person level
• Gadget User Preference settings can be fully configured via the ‘Edit’ button

Limitations:

• Gadgets run only in canvas view - there is no profile display; thus VIEWER=OWNER always
• People requests limited to first 20 results (that’s more friends than you have in Orkut, anyway…)
• Sending a batch of more than 3 or 4 requests at once may fail because it uses the URL (limited to 2k) to send request data; I could split these into multiple requests but prefer to translate to POST data as soon as possible
• No Activities feeds supported
• Persistance settings are not implemented efficiently: please don’t overuse, and be aware that I might clear old data in order to maintain performance (this is a novel scaling solution…)
• People Collections do not yet support iteration and array-like properties
• User Preferences will not be maintained for a gadget between sessions
• Locale will generally just default to, err… the default.

Because of the dangers of users trying out unscrupulous third-party gadgets which might steal their Facebook data, the demonstration app currently restricts standard users to trying out the approved gadgets only (I am evaluating whether a warning to the user would be enough). If you would like to see your OpenSocial gadget running in Facebook, please send the URL and I will put it up there - but note a copy will have to be hosted on my server just in case you’re one of those unscruplous third parties…

Please also get in touch to register your interest in the project, either as a developer of as a user. As discussed in the first post, we would like to expand this project to cover other code to bridge between social networks, and also reusable code frameworks to build Facebook or OpenSocial apps in general.

Given the inherently kamikaze nature of this project, we have secondary goals - which, realistically will be the long-term legacy of this project.

We will establish new standards of operation in collaborating on an open source social web app. The hosting requirements for a Facebook app - not least the fact that apps are tied to individuals’ accounts - may call for new procedures in the development, testing, and deployment of the app. As code if necessary, these lessons should be ‘exportable’ from this project.

The working knowledge of Facebook and OpenSocial APIs that we will gain through our primary goal will allow the project to expand to allow interaction in other directions and/or with social networks. For example, a side-project would be to allow data from arbitrary Facebook apps to flow into the OpenSocial world.