去る11月11日にリクルートメディアテクノロジーラボの「カフェ」でTokyo GTUG(Google Technology User Group) #4のイベントが開催されました。テーマはOpenSocialで、今回は「OpenSocialのアーキテクチャ」というテーマで講演させて頂きましたので、スライドを公開します。

9月18日に会津大学で行われる会津ITサマーフォーラムで講演することになりました。僕のセッションでは「OpenSocialのアーキテクチャ」というマニアックなネタをお話をさせて頂く予定です。 また、せっかくの会津なのでMashup Awards5のキャラバンも兼ねて、翌19日にOpenSocial Hackathonも開催することになりました。 OpenSocial入門を執筆されたmixiの田中洋一郎さんやMTLの川崎有亮さんも参加されます。地元の方は滅多にない機会だと思いますので、ぜひご参加ください。 詳細と参加フォームはこちら: OpenSocial Hackathon in 会津

「ウェブはソーシャルであるべきだ」。これは今の会社に
入社した2005年くらいからずっと訴えてきたことです。ソーシャルグラフをプラットフォーム化することで実現できることがたくさんあります。まずはポータルサイト全体をソーシャル化することを目標にし、作り上げたのがgooホームでした。

将来の構想はその時点で既にあって、いずれはポータル外のサイトとも接続して、インターネット全体がソーシャルグラフで繋がることをイメージしていました。そんな時に登場したのがFacebookです。

Facebookがやろうとしていたことは、SNSの中にサービスを取り込むという、僕の考えとは真逆でしたが、結果的にやろうとしていたことは似たようなもので、先に実現されたことにくやしい思いをました。そしてOpenSocialが登場します。

OpenSocialは仕様を民主的に決めて行くオープンなスタイルでした。オープン性のメリットは計り知れません。2つ以上のシステムを繋ぐのに、仕様から作るよりも、既に決まり事があれば話が早いのは火を見るよりも明らかです。技術的工夫もさることながら、コミュニケーションコストは大幅に削減できます。

さらに、オープンな仕様であればそれを使ったプロダクトが生まれやすくもなります。OpenSocial周りでも既に、よういちろうさんのOpenSocial Development EnvironmentやOpenSocial Client Library、OAuth関連ライブラリ、そして僕の作ったOpenSocial Signed Request Libraryなど、様々なオープンソースプロダクトが生まれ、後発の生産性を上げています。

そんなOpenSocial関連プロダクトの中心となるのが、OpenSocialコンテナのリファレンス実装であるShindigです。

僕がOpenSocialの既存仕様を学ぶ上で紐解いたのものこのShindigでした。当時はまだ日本でほとんど手をつけている人がいなかったため、API Expertとして声をかけて頂いたのも、Shindigに関する情報をこのブログで公開していたためです。

その後実際にgooホームでディプロイするに辺り、様々なパッチを書き、Shindigの開発チーム提供してきました。(もちろん、OpenSocialの仕様自体にも口を出してきましたが。)そうこうしているうちに、1年半ほどが経過し・・・

このたび、Shindigのコミッターになりました。

PHP版ShindigのメインコミッターであるChris Chabot氏とは、PHP版の最初のコミット前から連絡を取り、昨年のGoogle IOでも直接お会いし、その後もメッセンジャーで話したりしてきましたが、そのChrisにShindigのコミッターに推薦して頂いたのです。

Apache Software Foundationでコミッターになるには、既存コミッターの投票が必要らしいのですが、これまでの貢献を認めてもらい、承認して頂きました。

PHP版Shindigは今や、全世界述べ5億人(!)が26以上のSNSで使っているといいます。にも関わらずフィードバックされていたパッチはそれほど多くなく、自分がやってきたことは貴重だったようです。

本来僕にとってOpenSocialというのは理想のSocialWebを実現するための道具に過ぎないのですが、少なくとも日本では実質的なデファクトであり、mixiやgooホームで使われているShindigというプロダクトは、その根幹を支えるものです。

今後はShindigのコミッターとしても、日本のSocialWebを作り上げ、支えて行ければと思います。

gooホームのOAuth機能公開に合わせ、TwitterのOAuthを使ったガジェット「ガジェツイ！」(英語名GadgeTweetr)をリリースしました。ガジェットながらに、そんじょそこらのTwitterクライアントよりもシンプルかつ高機能で使いやすいものに仕上がったと思いますのでご紹介します。

※ガジェツイ！のロゴフォントには「ついってる」を利用させて頂きました。

主な機能

• OAuthログイン機能
• タブ機能
• 返信元表示機能
• 検索機能
• マルチアカウントに対応

OAuthログイン機能

OAuthに対応していますので、IDとパスワードを直接gooホームに入力する必要はありません。「ログイン」ボタンクリックで、twitter.comドメインの画面が開くので、ユーザーは安心してログインすることができます。

タブ機能

タブで様々な種類のステータスを並べて表示するタイプのTwitterクライアントです。Timeline、Mentions、Direct Message、Favoritesなど、一通りの表示に対応しています。

返信元表示機能

ステータスが返信の場合は「返信元」をクリックすることで会話を辿って行くことができます。

検索機能

フリーワード検索にも対応しています。

マルチアカウントに対応

ガジェットはいくつでも追加でき、それぞれに違うアカウントを指定することができます。

その他の機能

3つのビュー

home、profile、canvasそれぞれのビューに対応しています。homeではTimelineとMentionsが、profileでは当該ユーザーのステータスが、canvasではTimeline、Mentions、Direct Message、Favoritesがそれぞれデフォルトで開きます。

自動リンク機能

外部URLはもちろん、@によるID指定、そして#によるハッシュタグの指定を検知してリンク化します。URLの場合が別ウィンドウを開きますが、@と#の場合は新しいタブを作ってステータス一覧を表示します。

ReTweet機能

気に入ったつぶやきはこのアイコンをクリックすることで、いわゆる「ReTweet」することができます。もちろん、コメントを追記することができます。

プロフィール表示機能

アイコンクリックでフォロワー数や投稿数などのプロフィール情報を表示することができます。

フォロー、アンフォロー機能

プロフィール表示からそのままフォローしたり、既にフォローしている場合はアンフォローすることができます。

まとめ

せっかくOpenSocial上に作ったTwitterクライアントということで、ならではのソーシャル機能を準備していたのですが、残念ながら今回の発表には間に合いませんでした(実装でき次第公開します)。

とはいえ、gooホームのOAuthを体験してもらうためだけに作り始めたにも関わらず、シンプルかつ高機能なものに仕上がりました。ぜひガジェツイ！をお試しください。

OpenSocialのSigned Requestは、ガジェットからの外部通信リクエストに署名を付けることで、パラメータの内容が改ざんされていないかを検証可能にする仕組みです。一般に2-legged OAuthやSigned Request、OAuth Consumer Requestという名前はすべて同じ、これを表しています。

実装自体は全く難しくないものなのですが、お手軽なライブラリがあまり出回っていないようなので、作ってみました。まずはベータとして公開します。

特徴

Google CodeにあるOAuthのライブラリを利用しています。公開鍵はorkut、Google、Friendster、hi5、hyves、Netlog、そしてgooホームとmixiのものを同梱しています。

使い方

Google Codeからチェックアウトしてください。

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

中身はサンプルガジェット(SignedRequest.xml)とサンプルのサーバーサイド実装(example.php)、そしてライブラリです。

サンプルのサーバーサイド実装を見て頂くのが一番早いですが、使い方はシンプル。ガジェットのURLを引数にしてSignedRequestValidatorをnewし、validate_requestメソッドを呼ぶだけ。署名の検証に失敗した場合は、勝手に401を返します。署名の検証に成功した場合のコードは、その後に続けて書けばOKです。

参考

僕の知る限り、他の言語でSigned Requestを検証するコードやライブラリを公開されている方も何人かいらっしゃいます。

• Google AppEngine Python版 Django上で動作するgaeoauth
• Google AppEngine Python版で動作するコード
• Apacheモジュールレベルで動作するmod_auth_opensocial

まとめ

ベータ公開ではありますが、動作上の問題はないと思います。ただ、そのままのコードではGoogleからのリクエストもmixiからのリクエストもガジェットURLが合えば通してしまうため、任意に指定できるようにした方がいいかなど、フィードバックをもらって判断したいところと感じています。

※ちなみに、oauth_body_hashには未対応です。

というわけで、ぜひお試しください。

先日行われたGoogle Developer Day 2009の動画が公開されてます。基調講演に一瞬と、パネルディスカッションに登壇した動画もありますので、よろしければご覧下さい。

基調講演 vol.4 OpenSocial

OpenSocial パネルディスカッション

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