I’ve made a presentation about OpenSocial’s Architecture an event: Tokyo GTUG #4. Here I publish the slide I’ve used though it’s all in Japanese. Hope this will help someone.

There’ll be Aizu IT Summer Forum held on 18th Sept. in Aizu Fukushima, Japan. I’m going to have a session there, which will be about “Architectural overview on OpenSocial”.

On the next day, 19th Sept. there’ll be OpenSocial Hackathon in Aizu at the same place for as an accompanying event of Mashup Awards5.

If you happen to be in Aizu, please join us :)

Details and application form (written in Japanese):

OpenSocial Hackathon in Aizu

“Web will become more social” This has been what I kept telling people after 2005, when I’d joined goo. There’s so much things we can do when we make social graphs as a platform.  First thing I tried was to make a social platform on a portal site, which turns out to be goo Home.

I already had an image of the future at that time: the social graph will be expanded to external web and it will tie any other services into one with social connections. It was before we laungh goo Home when Facebook emerged.

What Facebook was trying to do was not like what I initially imagined: getting external services into their service. It was totally opposite to what I was imagining, but I realized our ultimate goal must be the same. Making web social. After a few month, OpenSocial got announced.

OpenSocial decides its spec democratic and open. Openness is good. Imagine you want to tie 2 systems social. Needless to say, it’s easier when the spec is something standard. You can omit communication cost as well as technical endeavor.

On top of that, with open spec, a lot of product may be expected. Taking OpenSocial as example, there’s Yoichiro Tanaka’s OpenSocial Development Environment, OpenSocial Client Library, OAuth related libraries, OpenSocial Signed Request Library which I developed… Whole bunch of open source products help latter joining developers.

And the primal open source product among OpenSocial is Shindig, OpenSocial container’s reference implementation.

Shindig was my textbook to learn existing spec of OpenSocial. There was almost no one else in Japan who looked into Shindig, so I was invited to become an Google API Expert.

I’ve also wrote a lot of patches to Shindig on my way to developing goo Home. And 1 and half years have passed…

I have become a committer of Apache Shindig

I made my first contact with Mr. Chris Chabot who has been the main committer of PHP Shindig. I met him in person at Google IO 2008, occasionally chatting on messenger, he recommended me to become Shindig committer.

To become a committer in Apache Software Foundation, you have to get voted. And luckily, I was approved.

PHP Shindig is said to be used be more than 26 SNS with 5 million users. I was really excited to know that.

To me, OpenSocial is just a tool to make my ideal social web possible. But at least in Japan, there’s no other choice now and OpenSocial IS the standard. And Shindig which is used in mixi and goo, is the one which support its core.

I’m hoping to make Social Web happen in Japan and support it as a Shindig committer.

goo Home just launched its Outbound OAuth support from today. Now, any gadget developers on goo Home can easily mash up external contents authorized using OAuth.

For demonstration purpose, I’ve developed a gadget, which I believe is the world’s first Twitter client on OpenSocial using OAuth, called “GadgeTweetr“. GadgeTweetr is simple, but powerful, even on comparing to other desktop Twitter clients.

Major features

• OAuth Login
• Tabs
• Show In-Reply-To
• Search
• Multi-account

OAuth Login

With support of OAuth, GadgeTweetr can let users login to Twitter without giving credentials to goo Home. Just by clicking “Login” button, a new window opens with clear indication that the browser is showing page on twitter.com, users can login to Twitter safely without worrying this is phishing.

Tabs

Using OpenSocial tabset feature, GadgeTweetr provides view of various status pages like some other Twitter clients do. Timeline, Mentions, Direct Message, Favorites, etc.

Show In-Reply-To

If the status is in-reply-to someone, GadgeTweetr shows “reply to:” beside its date. Clicking it will insert source status just blow that, so that you can drill down (up?) to the original tweet.

Search

You can search on Twitter. GadgeTweetr opens search result tab.

Multi-account

User can embed multiple copies of GadgeTweetr gadgets on goo Home’s home page with different authentications. So you have multiple Twitter accounts in one view!

Misc features

3 views

GadgeTweetr has 3 views: home, profile and canvas. Home view provides Timeline, Mentions tabs, profile view provides its owner’s timeline, canvas view provides Timeline, Mentions, Direct Message, Favorites tabs as default.

Auto link

GadgeTweetr detects @ and # and hyper link it, as well as external link. External link will open new window. @ and # opens new tab in GadgeTweetr showing respective status.

ReTweet

By clicking ReTweet button, you can tweet copy of your favorite status message with indication of ReTweet: “RT”. Of course, you can add your comment just as you do on your own tweet.

Show profile

Clicking thumbnail of a user shows profile dialog with description of the person, numbers of friends, followers, tweets.

Follow, unfollow

On profile dialog, you can even follow or unfollow the user depending on your relationship with the user.

Summary

So, this is the “GadgeTweetr”. Sorry but this gadget only works on goo Home for now, since I don’t know any other containers which supports OAuth properly designed to deploy this kind of gadget.

However, this gadget is already supporting English and is ready to serve to other containers. Although current version is just a plain Twitter client, I’m planning to implement more SOCIAL functionality as well.

Hope this helps the evolution of social web!

Signed Request in OpenSocial is a convenient solution for gadget developers to verify their remote content request is not spoofed. You can pick signature attached to the request and verify that no params are changed, added or removed.

Implementing this is not difficult, but since I don’t see any library, easy to use out of the box, I hereby introduce opensocial-signed-request-php-library as beta.

This library is using OAuth Library on Google Code. Major container’s public keys are included: orkut, Google, Friendster, hi5, hyves, Netlog, mixi and goo Home.

How to use

Check out from Google Code:

svn checkout http://opensocial-signed-request-php-library.googlecode.com/svn/trunk/ opensocial-signed-request-php-library-read-only

Looking at sample implementation should be the easiest way to learn. Instantiate SignedRequestValidator with gadget’s url, do validate_request(). that’s it. If validation fails, library will respond 401 and die. Further code can be written after that. It’s that simple.

Other known libraries

There’s a few libraries doing similar things, I know useful.

• Google AppEngine Python, Django library: gaeoauth
• Apache module: mod_auth_opensocial

Give me feedback

opensocial-signed-request-php-library should work straight. But in case you find bug, better API, please give me feedback. It’s still beta :)

Movies of Google Developer Day 2009 which I’ve been on stage for a session and a little speach for Keynote have been published on Youtube.

Keynote vol.4 OpenSocial

OpenSocial Panel Discussion

先日Googleの及川さん、石原さんと一緒にインタビューを受けました。

OpenSocialアプリ、開発者にとっての魅力（1/2）－＠IT

gooホームの方向性やドキュメント、OpenSocialコミュニティやShindigへのコントリビュートについてなどお話しさせて頂きました :)

ぜひご一読ください。

OpenSocialといえばmixiアプリ、いやむしろmixiアプリってそういえばOpenSocial？という感じの空気をひしひしと感じてますが、皆さんいかがお過ごしでしょうか。

今日はそんなmixiアプリの中身を覗き見るブックマークレットをご紹介します。

Peep mixi Appli XML

これを読んでるであろう人に詳しい説明は不要なので、簡単に書きます。

上記リンクをブラウザのブックマークに保存してください。mixiアプリの画面を開いてそのブックマークをクリックすると、ガジェットXMLのソースページが開きます。SafariとFirefoxで動作確認済みです。

これで、ガジェットがどんな風にできているのか、気軽に覗き見ることができますね。

※そういえばgooホームもOpenSocialです。

今回はOpenSocialでネット上にあまり情報のないPreloadについて、解説してみます。

ガジェットレンダリングの流れ

単純にRSSを表示するガジェットを例に説明します。あるコンテナSNS上でこのガジェットを表示する場合、下記のような手順を踏みます。

1. コンテナSNSのレンダリング
2. ガジェットサーバーがガジェットをレンダリング
3. ブラウザ上でガジェットのJavaScriptが初期化
4. 外部サイトのRSSを取得するためのAjaxリクエストをガジェットサーバーに送信
5. ガジェットサーバーが外部サーバーにリクエストを送信(キャッシュがあればスキップ)
6. ガジェットサーバーはレスポンスをブラウザに戻す
7. ブラウザ上でガジェットのJavaScriptがレスポンス内容を元に記事一覧をレンダリング

ざっとこんな感じになります。

OpenSocialコンテナの動きを理解していない人には若干分かりづらいかもしれません。この辺りの記事を参考にしてください。

さて、この一連の動きを効率化することで、全体の体感レンダリング速度を速くする方法があります。それが今回ご紹介するPreloadです。

ガジェットのレンダリングを高速化するPreload

Preloadは文字通り、レンダリングに先立ってロードしておいてくれる機能です。使い方は簡単で、/Module/ModulePrefs/Preload@hrefに呼び出したいURLを記述します。これで、先ほどのレンダリングの挙動が下記のように変わります。

1. コンテナSNSのレンダリング
2. ガジェットサーバーがPreloadで指定された外部サーバーにリクエストを送信(キャッシュがあればスキップ)
3. ガジェットサーバーがガジェットをレンダリング
4. ブラウザ上でガジェットがJavaScriptを初期化
5. 外部サイトのRSSを取得するためのAjaxリクエストをブラウザ上で処理
6. ブラウザ上でガジェットのJavaScriptがレスポンス内容を元に記事一覧をレンダリング

図にしてみると一目瞭然ですが、通信部分のオーバーヘッドを削減できています。こりゃ便利。

仕組みは単純で、ガジェットがプリフェッチした外部コンテンツを埋め込んだソースコードをブラウザに渡し、makeRequest時にプリフェッチした内容が存在すれば実際のAjaxリクエストを行わずに応答を返してしまう、というものです。

Preload利用時の注意点

Preloadはとても便利な反面、扱いにくい性質のものでもあります。以下を理解して、ポイントを絞って使う必要があります。

キャッシュの有効期限をコントロールできない

結構致命的なのがこれです。キャッシュの有効期限をコントロールできないと、デフォルト(24時間が多い)のキャッシュ期限が適用されます。これを回避できるケースとしては、ユーザーが任意の動作でmakeRequestを行うため、その時にキャッシュの有効期限をクリアできる場合が挙げられます。逆に言うと、RSSを表示するだけでユーザーは任意に更新できない、でも更新頻度は1時間程度、というようなガジェットには向いていません。

ContentTypeを指定できない

通常makeRequestを行う場合、ContentTypeをDOM, FEED, JSON, TEXTから選択することが出来ます。特にFEEDに関しては、RSS/RDF/Atomを丸めてJsonで返してくれるため、慣れた人には便利な形式です,

しかしこの挙動は、明示的にContentTypeとしてFEEDを指定し、ガジェットサーバーが外部コンテンツを取得した際に特別な処理を行うことで実現されているため、ContentTypeを指定できないPreloadでは、これを行うことはできません。RSS等をPreloadしたい場合は、DOMを選択してパースするしかありません。

UserPrefsの内容を反映することが出来る

/Module/ModulePrefs/Preload@hrefの内容に__UP_****__といった形でUserPrefsの内容を含めることができます。これは残念ながらmixiアプリでは使えない技ですね。

<Preload href="http://example.com/example.php?id=__UP_userpref__" />

Signed Requestが使える

/Module/ModulePrefs/Preload@authzに”signed”を指定することで、署名リクエストが行えます。これの利点は、ガジェット側でビューアーのIDを指定しなくても、サーバーが署名と一緒に送ってくれるため、上記のUserPrefsのケースのように、URLを工夫する必要がない点です。

コードを変える必要はない

PreloadはガジェットXMLにメタデータを追加するだけですので、基本的にJavaScriptのコードをいじる必要はありません。もちろん、キャッシュを気にしたりするといじった方がよい場合もありますけどね。

Preloadはいくつでも指定できる

実はPreloadはいくつでも指定できます。これまでに挙げた条件をクリアしているのであれば、思い切って使ってみましょう。

まとめ

今回は存在が地味なのであまり注目されていないけど、うまく使えば非常に便利なPreload機能を紹介しました。うまいこと使いこなして、一流OpenSocialerを目指しましょう。

最近「OpenSocialでOwnner毎 or Owner*アプリ毎の永続化方法 オプション」辺りでOpenSocialのパーミッションに関する疑問がいくつか挙っていたので、どういう場合にどのデータにアクセスできるのか、ついでに、FriendConnectにおけるパーミッションモデルについてもまとめてみます。

まずは最低限の知識としてビューアー(VIEWER)/オーナー(OWNER)という考え方と、基本情報/個人情報を押さえておきましょう。

ビューアーとオーナー

ガジェットは貼られる場所によって呼び方が異なり、これをビュー(view)と呼びます。OpenSocialでは標準的にhomeビュー、profileビュー、canvasビューが用意されています。ここを参考にしてください。

ご覧いただくと分かると思いますが、homeビューのガジェットは自分が見るマイページに貼られる前提で，profileビューは他人が見るプロフィールページに貼られる前提になっています。では，「自分が見る」「他人が見る」は何を意味するのでしょう？

OpenSocialガジェットには所有者/オーナー(OWNER)という考え方があります。オーナーとは，ガジェットをページに貼付けたページの持ち主を指しています。反対に，ガジェットを見る人を閲覧者/ビューアー(VIEWER)と呼びます。

つまり，homeビューで「自分が見る」が意味するのは，オーナーでありビューアー。逆に，profileビューで「他人が見る」が意味するのは，ページを見ているビューアーと，ページの持ち主のオーナーです。もちろん，プロフィールページをオーナー自身が見ているケースでは，オーナーとビューアーは同一人物になります。canvasビューでも同様。

基本情報と個人情報

OpenSocialではプロフィール情報は大きく2つに分けられます。
goo Social Platformではこれを基本情報(id, profileUrl, thumbnailUrl, nickname)と個人情報(その他のプロフィール)と分けて呼んでいます。詳細はこちらをご覧いただいた方が早いと思います。

基本情報は、必要最低限の情報で、個人情報はさらに詳細で重要性の高いものと思ってください。

基本ルール

これらを踏まえて、各種情報をやり取りする際に必要となるのが下記の基本ルールになります。

• 個人情報を取得する場合、対象となるユーザー(オブジェクト)が同じガジェットをインストールしていること
• オブジェクトが友達の場合、ガジェットをインストールしていなくても基本情報のみ取得可能
• 更新・削除はビューアーが自分のデータを操作する場合のみ可能

ミソは、

• 友達でもガジェットをインストールしていない人の個人情報は取得できない
• 友達じゃなくてもガジェットをインストールしていれば個人情報が取得できる

ところ。

「なぜそんなに面倒なの？」「なんでガジェットインストールしてないと個人情報取れないの？」と思われる方も多いかと思いますが、理由はずばり、「プライバシーの保護」です。

• 個人情報はコンテナがユーザーから取得したものである
• 個人情報保護法では、収集した個人情報を事前に通告した目的外に利用してはならない
• 個人情報はコンテナが取得したものであり、第三者に譲渡や開示する(ディベロッパーがガジェット上で利用する)場合はユーザーがそれを理解している必要である
• ユーザーは誰が自分の個人情報を取得したかを把握できる必要がある
• ディベロッパーは受け取った個人情報を外部に流出させることも、売り渡すことも、理論的には可能である
• ネット上にパブリックになっている情報でも、受動的に(スクレイピング等)渡す場合と、能動的に(API経由)渡す場合では、法的意味が異なる(そういう意味では、mixiのようなクローズなSNSでも、gooホームのようなオープンなSNSでも扱いは変わらない)
• ディベロッパーが故意または事故で個人情報を漏らす等した場合、責任はもちろんディベロッパー側にあるが、情報を提供したコンテナは、ディベロッパーとの連絡を確実に取れる手段を用意しておく必要がある

若干複雑ですが、こんな理由で、本人が意図して利用していないガジェットに対しては、基本的に個人情報を渡さない方向に倒されている、という訳です。これはgooホームだけの話ではなく、まだ明示されてはいませんが、mixiも含め、今後登場するであろうOpenSocialコンテナすべてで似たような実装になると思います。

なお、基本ルールに対する特別ルールについては複雑になるのでここでは説明しません。興味のある方はこちらをご覧下さい。

FriendConnectのパーミッションモデル

さて、ここまで一般的なOpenSocialについて解説してきた訳ですが、FriendConnectにおけるガジェットのパーミッションについてここで考えてみましょう。

通常のSNS上のOpenSocialでは、ガジェットをインストールしているかどうかで個人情報を提供するか否かを決定していましたが、FriendConnectではちょっと事情が違います。それは、ガジェットのオーナーが人間ではなく、サイトである、という考え方に基づいている、という点です。

こちらの記事をご覧いただければ分かると思いますが、

Ownerはサイト。そういえば、FriendConnectガジェットを入れた時点では、自動的に自分がメンバーになったりはしていませんでした。Ownerは貼付けたサイトという仮想人格が担うようです。

サイトという仮想人格、というところがミソです。つまり、FriendConnectでは、ユーザーがオーナーになることはあり得ないのです。そのため、先に解説した一般的OpenSocialのパーミッションモデルをそのまま適用することはできません。

では、FriendConnectではどういう場合に個人情報を取得できるのでしょうか？

現実的には、私の把握している限り、まだFriendConnect上で基本情報以上の情報(個人情報)を取得することはできないので、必ずしも正しいとは言えないのですが、「そのサイトに参加しているか否か」がパーミッションを得るための条件のようです。

言い換えると FriendConnectの基本ルール：

• 個人情報を取得する場合、対象となるユーザー(オブジェクト)がガジェットを動かそうとしているサイトに登録していること
• オブジェクトが同じサイトに登録していれば、個人情報も含め取得可能(実際は取得できないので想像)
• 更新・削除はビューアーが自分のデータを操作する場合のみ可能

となります。一般的OpenSocialの基本ルールと並べて比べてみると、違いが分かると思います。

まとめ

今回は、先日のHackathonでも多数の質問が出たパーミッションモデルの話を解説してみました。開発者にとっては面倒なだけですが、コンテナやユーザーにとっては、プライバシーを守るためにとても重要なことです。

OpenSocialガジェット開発もある程度のレベルに達してきたら、この辺りの理解をしっかりやっておくことが重要だと思います。