2008年12月30日火曜日

2009年のソーシャルウェブを占う

PlaxoのJohn McCrea氏が2009年のソーシャルウェブを予言しています。

それによると・・・

Facebookが最低でも1つ(OpenIDかOAuthが有力)のOpen Stackをサポートする


FacebookはアプリケーションプラットフォームとしてOpenSocial勢を大きく引き離し成長を続けています。現在のところOpenIDもOAuthもPortable Contactsも一切無視した、独自仕様で展開していますが、オープンな規格を取り込むことなどいつでもできること。状況次第でこのカードを切ってくる可能性は十分あり得ます。

Google、Yahoo、MicrosoftがそれぞれのウェブメールサービスでPortable Contactsをサポートする


OpenSocialのRESTful People APIと完全に一致したことで、Portable Contactsのスタンダード化はもう既定路線でしょう。他に有力なプロトコルもありませんので、Microsoftはともかくとして、Google、Yahooは必ず対応します。

Microsoftが少なくともOAuthを、Portable Contacts対応のため実装


MicrosoftがPortable Contactsに対応するとすれば、認証方法に独自プロトコルを用いるのは得策ではありません。なぜなら、OpenSocialがOAuthとPortable Contactsをセットで規定しているから。ディベロッパ寄りに考えれば、これも十分にあり得る選択肢です。

MicrosoftのWindows LiveがOpenSocialコンテナに


上記のいずれも、実はMicrosoftは独自の代替プロトコルを持っています。ガジェットプラットフォームとしても、Windows Live Gadgetがあります。しかし、ウェブサービス分野で遅れをとっている今、独自路線に固執するのは得策ではありません。OpenSocialに対応する可能性は皆無とは言い切れません。

Plaxoが伝統的メール/パスワードによるサインアップをOpen Stackによって完全に駆逐できることを証明する


これは、まあオマケですね(笑)

で、僕も考えてみました。2009年のソーシャルウェブを大予想!

GoogleがSNS化


以前にも書きましたが、Googleは着々とSNS化への準備を整えています。SNS化というと語弊があるかもしれません。SNSをプラットフォームとして取り込む、かな。

Google FriendConnectは対応サイトを手軽にSNS化できることが目玉のように言われていますが、僕はもっと違う狙いがあるものと思っています。仮にGoogleがiGoogleをOpenSocialコンテナ化した場合、当然友達リストはGmailのアドレス帳が筆頭になる訳ですが、実はGoogle FriendConnectで接続したアカウントもその候補なのではないか、とにらんでいます。

もしそうなった場合、複数のSNSに参加している人のアカウントはすべてGoogleに束ねられることになり、他の追随を全く許さない状況になってしまうのではないでしょうか。

(実はGoogleの人にこのことについて聞いたことがあるのですが、そんなevilなことしないよ〜と言ってました)

課金プラットフォーム流行


iPhoneのApp Storeはディベロッパにとって革命でした。一般のディッベロッパが自分の作ったアプリケーションを投稿するだけで、配布・課金までしてくれるプラットフォームはこれまでなかったからです。

これはソフトウェア開発に限った話ではありません。ビデオや音楽で似たようなことができるとしたら?2009年、こういった「モノを作れる人」がお金を得るための仕組みが新たなビジネスモデルとして盛り上がってくるのではないかと予想しています。もちろん、ソーシャルウェブプラットフォームと紐付けられるというのは大前提です。

広告プラットフォーム戦争勃発


Facebook戦略の次の展開は広告と言われています。レコメンドやターゲティングを行うプラットフォームとして、ソーシャルウェブ以上のものがあるでしょうか?Facebook Connectを活用することで、ユーザーに最適な広告を表示する準備は整っているはずです。そして当然、MySpaceやGoogleも同じ路線を取るだろうし、取ることができるでしょう。という訳で、広告プラットフォームもソーシャル化し、新たな競争が生まれるものと予想します。

まとめ


いかがでしたでしょうか?ソーシャルウェブにとって2008年は助走の期間、来年いよいよ勝負の年になります。欧米での今後の動きは、必ず日本にもやってくるでしょう。

ソーシャルウェブについて興味がある方はぜひ、SocialWeb Japanにご参加ください。

2008年12月11日木曜日

SocialWeb Japanを立ち上げました

そういえばソーシャルウェブ周りに関する勉強会をするコミュニティが存在しないなあと思い立ち、Google GroupsにSocialWeb Japanを立ち上げました。
SocialWeb JapanはOpenStackやFacebookを中心とした、ソーシャルウェブにまつわる技術の情報交換、勉強会の開催を目的としたコミュニティです。

これらのキーワードにピンときた方はぜひご参加を。

  • OpenID

  • OAuth

  • OpenSocial

  • PortableContacts

  • XRDS-Simple

  • Google FriendConnect

  • Facebook Connect

  • MySpaceID

  • Yahoo! Open Strategy

  • etc...



ZIGOROuさんと話してたら、ものすごい勢いでIRCも立ち上げて頂きw

#socialweb-ja@freenode

ご参加お待ちしております。

2008年12月10日水曜日

FriendConnect実験中

本ブログ左サイドバーの下の方に、Friend Introducerという以前作ったOpenSocialガジェットをFriendConnect用に若干修正して追加してみました(2008/12/9時点)。



元々このガジェットは、キャンバスビューで自分の友達の紹介文を書き、プロフィールビューでその人に書かれた紹介文が読める、というものでした。Orkutやhi5等のsandboxで試していたものです。

しかし今回FriendConnectでガジェットを試して明確に分かったことがいくつか。

  • ブログは1面しかありません。そのためビューはprofileまたはcanvasから選択。FriendConnectのSocialGadget設定画面で決めることができます。

  • friendconnectフィーチャーというものがあるようです。具体的に何をするものなのかは不明。

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


ビューに関しては、profileビューにするとサイトがOwnerとして表示されるので、よくわからない状態。APIでプロフィールを取得するとどうなるかは未検証です。現在はcanvasビューで表示していますが、おかげさまで自分で自分の友達の紹介文を書くだけで、誰にも見せられないというしょーもないガジェットになっています(--;。

そういえば他のFriendConnectガジェットは右上にキャンバスビューに移行するボタンがありますね。どうやってこれを使うことができるんでしょう?時間があるときにでも追いかけてみたいと思います。

2008年12月4日木曜日

Google FriendConnect一般公開

事前にプレビューを申し込んでいた人にはインビテーションが配布され始めたようです。

早速このブログの左側にも貼ってます。Join!してみてくださいね。

Windows Live Home登場

海外のメインプレイヤーが次々にソーシャル化していってます。今回はついにMicrosoft。

Windows Liveといえば、元々Messengerのソーシャルグラフを取り込んだブログサービスのSpacesがSNSとして存在していましたが、今回Homeが中心となり、さらにSNSライクになりました。

Windows Live Profile




画面右上に友達リスト、中央には他のSNSでいうアクティビティストリームが表示されています。アクティビティストリームはFacebook同様完全に時系列で、サービスごとにまとめられたりはしていません。Live Messengerのムードメッセージが混じっているのがTwitter的で面白いところでしょうか。また、指定された外部サービスのフィードも混ざって表示されています。

URLはサブサブドメイン(?)にユーザーの裏IDらしき文字列で表現されていますのでシンプル。この裏IDは後で変更できるとスマートでいいですね。

Windows Live Home




一番上にはLive Mail(旧Hotmail)の最新メール。その下に、Live Messengerで繋がっている人の更新情報がアクティビティストリームとして表示されています。Spacesとの整理はよく分かりません。

画面右には広告枠とニュース、占い。うーん地味だ。

Windows Live Photo




SkyDrive(MSが提供する25GB(!)の無料ストレージ)と連携したフォトストレージサービス。ここにもアクティビティストリームがありますが、おそらくLive Photoに特化したフィードを表示してくれるのだと思います。友達の最新フォトを確認できるだけでなく、自分の写真をアップロードしたりもできるようです。

外部サービスの取り込み




TwitterFlickrなどの外部サイトを取り込んで、アクティビティストリームに混ぜることができます。一番最初に思いつく類似サービスはFriendFeedですが、自身もソーシャルであるという意味では、ある種FacebookPlaxoの方が近いかもしれません。

その他新サービス


他にもWindows Live Groupというグループコラボレーションサービスがあるようです。



Live Messengerでのグループチャットや写真の共有に使えるようです。

技術的側面


MicrosoftはWindows Live IDのOpenID化を宣言していますが、その他のOpen Stackについては、まだ特に言及していません。OpenSocialOAuthPorableContactsについてです。調べてみると、Delegated Authenticationという独自プロトコルを使って、OAuth的なことを実現しているようです。

果たしてこのまま独自路線を走るのか?Yahoo!やMySpaceのように独自路線+オープンスタンダードの路線でいくのか?疑問が残るところです。

Windows Liveソーシャル化の持つ意味


結局Microsoftまでもが、ウェブサービスだけでなくソーシャル化にまで手を出してきました。これはソーシャルグラフをプラットフォームに据えたサービスが今後のウェブでは当たり前になっていくことを示唆しています。ただ、ソーシャルであれば万能という訳でもないし、すぐに何かできるという訳でもありません。それを活用できるサービスがあってこそ、初めて便利さが享受されるもの。では、Microsoftの戦略は?

実はすでにWindows Liveメールはサーバー上のものと同期可能なクライアントソフトが登場しており、SkyDriveもデスクトップとウェブでシームレスに利用できるクライアントが出るとか出ないとか。メッセンジャーは言わずもがな。ソーシャルグラフはとっくの昔にメッセンジャーとHotmailで共通化しています。他にもWriterというブログ編集ソフトが既にリリースされています。

これらは明らかに、クラウドとしてのウェブサービスと、デスクトップソフトの組み合わせ利用を意識していると言え、そのいずれもが、SNS的機能によってより実力を発揮することができるものです。

今までウェブサービスとしては地味にやってきた感のあるMicrosoftですが、そう考えると、Windows7が出るタイミングで大バケする可能性も、否定はできません。

気になったこと


Windows Live Gadgetの使いどころをHomeに用意していないところが気になります。Gadgetの仕様はよく知りませんが、もしOpenSocialに変わる独自JavaScript APIを用意するのだとしたら、、、!?

この辺の戦略は気になるところです。

2008年11月21日金曜日

Facebook Connectに見る未来のソーシャルウェブ

DataPortabilityを実現するData AvailabilityやFacebook Connect、FriendConnectの技術が公表されて半年が経ちますが、ようやくこれらを実際に使ったサービスが登場してきました。

これまでのFacebookやOpenSocialにおけるガジェットや埋め込み型アプリケーションは、中心となるソーシャルネットワークに外部サービスが機能を提供する形でプラグインするものばかりでした。Data AvailabilityやFacebook Connectは逆に、RESTful API等を活用して外部サービスにソーシャルネットワークをエキスポートします。今日はCitysearchというサービスで実現されたFacebook Connectを例に、これからのソーシャルウェブの具体的なカタチを紹介したいと思います。

CitysearchがFacebook Connectにβ対応


僕の知る限り、これが初のまともなFacebook Connect対応 / DataPortability対応のサービスです。

Citysearchは、レストランやホテル等、実際に利用した人がレビューを書いて共有するタイプのソーシャルネットワークです。



よく見ると画面右上に"Sign In Using Facebook"の文字があります。



早速クリックしてログインを試みます。

認証




Lightbox風のダイアログがポップアップして、Facebookアカウントを使ってサインインしても良いかの確認が。

ここで重要なのは

  • Citysearchのロゴが入っている。つまり、FacebookとCitysearchの間には、自動化されているにしろ、事前に何かしらのやりとりがあったことが伺える。

  • このダイアログはiframeです。僕の場合は既にFacebookにログイン状態だったので確認しか表示されませんでしたが、ログインしていない場合は(フィッシング対策として)別ウィンドウがポップアップしてFacebookのIDとパスワードを求めるようです。

  • 利用規約に同意する必要があります。地味ながら、日本での法的なハードルも今後課題になるとは思われます。


サービス登録




コネクトすると、未登録のためメンバー名を求められます。既存アカウントが無い人のために用意されているようです。ここでもいくつかポイントがあります。

  • Facebookの認証は独自方式ですが、これがオープン仕様ならOAuth/OpenIDのコンボになると考えられます。つまり、Facebookの独自方式では認証と認可が同時に行われているようです。

  • この後分かりますが、できあがったアカウントにはFacebookのプロフィール写真、名前、友達リストが少なくともインポートされています。オープン仕様であればOpenIDでsregを使ってニックネームとプロフィール写真を、OAuthで友達リストをインポートすることになるのでしょうか。OAuthだけでもいいかもしれません。

  • "Merge your Facebook profile with an existing Citysearch account?"というリンクが用意されています。既存アカウントとOpenIDをマージできるサービスが少ない事を考えると、なかなか気が利いています。

  • ここではCitysearch自体の利用規約に同意させているようです。


コネクト完了




ログインしてみると、画面右上に自分のFacebookプロフィールの写真が表示されています。



マイページには自分の名前とプロフィール写真しか掲載されていません。他にエキスポートされる情報があるかは未調査です。



ここが最大のミソになる、友達リストです。残念ながら"None of your Facebook friends are Citysearch members"とあるように、両方に登録しているFacebook friendsしか友達として表示されないようです。ここで未登録の友達も表示して、"Citysearchに招待する"なんて機能があってもいい気がします。

フィードバックとなるアクティビティ


さて、ここまで見てきたものはすべてCitysearch上の画面でした。Facebookは自身が持つデータを提供するばかりで、考えてみればいいことなど何ひとつないように見えます。広告を貼る方法だって見つけられません。では、なぜ惜しげもなくソーシャルグラフを提供するのでしょうか?

実は、Facebook ConnectはアクティビティをFacebookにフィードバックする仕組みを持っており、これによってFacebookはコネクトされたサービスのアグリゲータになれるからなのです。下記画像の「掲示板に記事を掲載」とあるのがこの部分です。OpenSocialで言えばアクティビティストリームがこれに当たります。



実際の画面イメージを掲載したいところですが、Citysearchにレビューを書く勇気がないのでJohn McCrea氏のサンプルにリンクしておきます。



アクティビティのアグリゲータになることは、トラフィックを集める上で非常に重要な戦略です。Facebookにさえ来れば、友達が関わる様々なサービス上の活動を一目で確認することができるのです。今まで知らなかったサービスも、友達を介して知ることができます。さらに、集めたアクティビティにはこんな利用法もあり、様々なマネタイズの可能性も秘めていると言えます。

参考サイト




2008年11月18日火曜日

iGoogleの進化に見るGoogleのソーシャル化

iGoogleはこれまで複数のガジェットを1ページに表示するスタイルでしたが、最近「canvasビュー」が追加され、1つのガジェットを画面いっぱいに表示して利用できるようになったことは記憶に新しいと思います。canvasビューを使うことで、特にGmailやGoogle Readerのガジェットでは、単体サービスのかなりの機能がガジェット上でそのまま利用できるようになり、大幅に利便性が向上しました。





このiGoogleの変化は、既に明言されてはいますが、iGoogleのOpenSocial対応を予感させ、将来的にGoogle全体がソーシャルネットワークになっていくことを示唆しています。実は既にGoogleがそれ自体をソーシャルネットワーク化していく方向性は随所に見られます。

Googleのソーシャル化


Gmail連絡先(コンタクトリスト)


ソーシャルネットワークを形作る上で最も重要になるソーシャルグラフを、GoogleはGmail/Google Talkに持ってきました。当然と言えば当然。この連絡先(コンタクトリスト)はAndroidケータイ上にもインポートされ、電話帳としても利用されており、いやでもリアルなソーシャルグラフになる点が特徴と言えます。

Google Mapsプロフィール


最近プライバシー問題で話題のGoogle Mapsには実はプロフィール機能がついており、画面上部の「プロフィール」リンクをクリックすると、自分のプロフィールを作成/表示することができます。これは後述のGoogleプロフィールと連携しています。

Google Readerの共有機能


Google ReaderはRSSリーダーですが、気になった記事をボタン一つで友達に共有できる機能があります。その際利用されるのがGmailの持つ連絡先のソーシャルグラフで、ここでも活用されています。

Googleプロフィール


いつのまにか、ひっそりと作られた感のあるのがGoogleプロフィールこれが今後どう充実して行くかは要注目です。



画面左上にユーザーの写真とニックネーム、住所が表示され、その下にはプロフィールの詳細情報が表示されます。今のところ住所や過去に住んだことのある場所、通った学校、勤めた会社、略歴に加え、Googleを使っても見つけられないもの、超能力(?)など一風変わった項目もあり、この画面から編集を行うことができます。



そして「リンク」。今のところ本当にただのリンクですが、利用している外部サービスを登録することができます。面白いのは、例えばFriendFeedを登録すると、自動的に他のサービスも登録候補にずらずらっと表示されるところ。なるほど、ここでGoogle Social Graph APIを活用しているようです。確かに、FriendFeedにはrel="me"といったmicroformatが埋め込まれています。

メッセージ機能


Googleプロフィールに最近メッセージ機能が追加されました。英語版でしか存在を確認することはできませんが、プロフィールページからメッセージを送ることができるようです。これもOpenSocial対応を意識したものでしょう。

Googleは今後どう変わって行くのか


Googleがソーシャル化していく上で、今後どのような部分に変化が見られるのか予想してみました。

Googleプロフィールにガジェット


まず間違いなく、Googleプロフィールにもガジェットが追加できるようになるでしょう。

OpenSocialにはhomeビュー、canvasビュー、profileビュー、previewビューの4つがあらかじめ定義されていますが、ガジェット追加確認用のpreviewビューを除けば、一般的なSNSにおけるマイページ(homeビュー)、ガジェットのみを表示するcanvasビューが既にiGoogleで用意されているので、残りはプロフィールページ(profileビュー)となるのは自然な流れと言えます。

GoogleプロフィールのiGoogle統合


GoogleプロフィールとiGoogleの統合はあり得ない話ではありません。今もiGoogleのSandbox環境では自分のGoogleプロフィールの内容を確認することができますが、例えば簡単に画面遷移ができたりすることで、他者との距離を近づけ、iGoogleがソーシャルなものであることを意識できるようになるかもしれません。

アクティビティストリーム


iGoogleのSandboxでは既に片鱗が見えますが、OpenSocialのアクティビティストリームという機能がもう少し明確に、姿を現すはずです。アクティビティストリームとは、ユーザーの行動履歴のようなもので、mixiで言えば友達の日記やコミュニティの最新情報に当たります。

OpenSocialではガジェットからアクティビティを登録する機能が規定されていますが、iGoogleではこれに加えてリンクしたサービスのフィードも自動的に混ざる、FriendFeedライクな機能を追加してくるのではないでしょうか。MicrosoftがWindows Live Homeで追加した機能にも同様のものがあります。

まとめ


Googleプロフィールをネタに記事を書き始めたのですが、なんだかんだ話が広がり、結構大きい話になってしまいました。しかしGmailを中心として着実に、潜在的にソーシャルグラフを広げているGoogleが、完全なソーシャルネットワークの形態をとった時にどれほどの影響力を持ったものになるのか、正直想像もつきません。果たしてGmailを作った時点でここまで考えていたのか?今後の動向から目が離せません。

2008年10月29日水曜日

米YahooがOpenSocialに対応

本日米Yahoo!から、Yahoo! Open Strategy 1.0として、ディベロッパ向けにYahoo! Application Platform (YAP)Yahoo! Social Platform (YSP), Yahoo! Query Language (YQL)リリースされました。

Yahoo! Social Platform


プロフィールやアドレス帳、更新情報等、ソーシャルにまつわるAPIをRESTベースで提供するものです。認証機構にはOAuthを利用し、PHP版、Flash版のライブラリも提供されていますが、このREST APIはOpenSocial互換ではありません。

Yahoo! Query Language


SQLライクなコマンドを送信する事でYahoo! Pipesのようにデータ取得が可能なウェブベースのAPI。FacebookのFQLのようなもののようです。

Yahoo! Application Platform


Yahoo!上で動作する埋め込み型のアプリケーション。OpenSocialのガジェットプラットフォームは現時点ではサポートされていませんが、JavaScript APIは使えるようです。大きく2つのビューがあります。

Small View


HTMLまたはYML Liteのみサポート。JavaScriptはサポートされていません。YMLは、Facebookで言うところのFBMLのようなもので、 My!Yahoo等様々なページにパーツとして表示する事が想定されています。

Canvas View


ディベロッパが指定したURLが出力したYMLをプロキシして表示するタイプのアプリケーション。Facebookライクな仕組みですね。もちろん、サーバーサイドでYahoo! Social Platformを使ったプログラムを書く事で、OAuthで認証を行い、RESTベースでソーシャルグラフを取得したり、コンタクトリストを取得したりすることできます。

また、OpenSocial JavaScript API(v0.8)にも対応しているので、クライアントサイドから更新情報を追加するといった利用も可能な様子。Cajaが利用されているので、セキュリティに気遣う事なく実装できそうです。(いつのまに実用レベルに達していたのでしょうか・・・)

時間のある時にでもサンプルアプリケーションを作ってみたいと思います。

所感


今回のYahoo!のリリースは、FacebookプラットフォームとOpenSocialのいいとこ取りといった感じ。ただし、OpenSocialに完全に準拠している訳ではないので、他で作ったアプリケーションをちょっとだけ書き換えて転用、という訳には行かなそうです。

例えば、クライアントからmakeRequestを使って外部サーバーのデータを取得するようなJavaScript APIは利用する事ができません。また、OpenSocialならHTMLを出力すればよかったものが、YMLを出力しなければなりません。等々・・(追記:Gadgets Core APIは利用できるようです。ただし、Pref、Viewなど、featureで指定する機能は利用できません。また、YMLは通常のHTMLに加え、独自タグを使って拡張した機能が使える、というもののようです。ただ、Caja対応のために外部スクリプトを読み込めないことが、他のコンテナに実装したガジェットをインポートする際の障壁になりそうです。)

ただ、世界最大のポータルサイトがOpenSocialに対応することの意義は大きく、今後の動きは要注目です。全体の戦略からすれば、OpenSocialの対応はあくまでパーツに過ぎず、今後のウェブのあり方を位置づける重要な意味を持ちます。先日行われたYahoo! Open Hack Dayのプレゼンテーションは必見です。

どんどんプラットフォーム化していくウェブと、その中で占めるソーシャル機能の持つ重要性が、日本でも認識される日はそう遠くないと思います。

2008年10月20日月曜日

Orkutアプリのソースコードを覗くブックマークレット

OpenSocial-Japanのメーリングリストで出した小ネタを貼っておきます。

OpenSocialアプリ(ガジェット)はiframe内に表示されているのですが、iframeタグのsrc属性に含まれるURLのquery部分に、実はソースコードとなるXMLのURLが書いてあります。 このブックマークレットを使えば、ワンクリックでソースコードを開くことができます。

Open Orkut Gadget XML

↑上記をブックマークレットとして保存し、Orkutアプリを表示した状態でクリックすると、ソースコードのページが新規ウィンドウで開きます。 (複数表示されている場合は、一番上のアプリのソースコードが開きます)

※Firefoxでしか動作確認してないので、動かなかったら教えてください。

2008年10月4日土曜日

OAuthの署名方式を掘り下げる

当ブログでこれまで何度かOpenSocialに絡んだOAuthについて取り上げてきましたが、MySpaceを参考にしていたため、署名方式としてHMAC-SHA1のみを対象にしてきました。しかしShindigを掘り下げる上でRSA-SHA1を避けて通ることはできず、むしろこちらについても十分な知識を得ていないとなかなか先に進めないことが分かりましたので、この機会にまとめてみます。(OpenSocialをある程度前提にしていますが、署名の話はOpenSocialに限らないものです。)

署名とは何か


ITの世界で署名とは、問い合わせ元がその人であることを証明するための手段、と言えます。OAuthだと、コンシューマがサービスプロバイダに対して、名乗っている通りの者であることを証明することを意味します。これは、「自分」もしくは「相手と自分」にしか分からないものをリクエストに付け加えて送ることで実現されます。

OAuthの仕様では、署名方式について厳密に規定していませんが、HMAC-SHA1、RSA-SHA1、PLAINTEXTの3つの署名方式を説明しています。
OAuth does not mandate a particular signature method, as each implementation can have its own unique requirements. The protocol defines three signature methods: HMAC-SHA1RSA-SHA1, and PLAINTEXT, but Service Providers are free to implement and document their own methods. Recommending any particular method is beyond the scope of this specification.

HMAC-SHA1


HMAC-SHA1を使ったOAuthでは、予めコンシューマとサービスプロバイダが、同じコンシューマキー(oauth_consumer_key)とコンシューマシークレット(oauth_consumer_secret)を持ちます。コンシューマシークレットはもちろん、秘密というくらいですから、2者以外に知られてはいけません。2者がコンシューマシークレットを共有することから、Shared Secretと呼んだりもします。

MySpaceでは、コンシューマキーをアプリケーションのURL、コンシューマシークレットをMD5らしきランダムな(?)ハッシュ文字列としていますが、コンシューマキーはディベロッパの任意で変更可能です。詳しくはこの辺りをご覧下さい。

RSA-SHA1


逆に、RSA-SHA1の方式では、コンシューマが公開鍵と秘密鍵を持ちますが、サービスプロバイダは秘密鍵を知ることはありません。コンシューマは秘密鍵で暗号化した署名を加えたリクエストを投げます。この暗号化された署名は、公開鍵でしか解くことができませんし、秘密鍵でしか作ることができないため、コンシューマが身分を証明できる、という訳です。

署名を作る際、HMAC-SHA1方式の場合、コンシューマシークレット(oauth_consumer_secret)とトークンシークレット(oauth_token_secret)を"&"で繋いだものをkeyとして利用しますが、RSA-SHA1方式の場合、秘密鍵をkeyとして使って暗号化します。そのため、コンシューマシークレットとトークンシークレットは不要です。

逆にサービスプロバイダは、公開鍵を使って署名が正当なものであることを確認します。

[sourcecode language='php']
$publickeyid = openssl_get_publickey($cert);
$ok = openssl_verify($raw, $signature, $publickeyid);
openssl_free_key($publickeyid);
[/sourcecode]

$certは公開鍵、$rawは署名の基本文字列(Signature Base String)、$signatureは署名文字列(oauth_signature)を表しています。$rawと$signatureはコンシューマからのリクエストで生成することができますが、$certについてはちょっと考察が必要です。

RSA-SHA1の公開鍵の扱い


OAuthの拡張としてOAuth Key Rotation Extensionが提案されています。これはコンシューマがサービスプロバイダにリクエストする際、公開鍵のIDをリクエストと一緒に渡すことで、サービスプロバイダに鍵をダウンロード/認識させるための仕様です。公開鍵のIDはxoauth_signature_publickeyパラメータで渡されます

OAuth Key Rotation Extensionのドラフト、OpenSocial/Gadgetの仕様書など、いくつかのドキュメントにxoauth_public_keyと記述されていますが、Shindigの実装でxoauth_signature_publickeyが使用されており、こちらが正式なものとなるようです。

ここで公開鍵のIDと言いましたが、もちろん、これだけでは公開鍵を取得することができないので、これを使ってゴニョゴニョする必要があります。

が、、、。

OpenSocial/Gadgetの仕様書には
The container should make its public key available for download at a well-known location. The location https://container-hostname/opensocial/certificates/xoauth_public_keyvalue is recommended.

と書いてあるのですが、Shindigの実装ではhttp://container-hostname/public.cerになっていたりと、仕様が一貫していません。

現実はどうしているかというと、xoauth_signature_publickeyを無視して、コンテナのドキュメントに書いてある公開鍵をコピペしてソースコードにハードコーディングしています。hi5、Orkutについては動作確認ができました。iGoogleについてはここに公開鍵が書いてありますが、動作しませんでした。

OAuthが広まって様々なコンシューマが登場するまでは、まだまだこの中途半端な状態が続くのではないでしょうか。

コンシューマは誰か


ここで勘のいい方は気付かれたと思いますが、RSA-SHA1方式の場合、署名元がOpenSocialのコンテナサイトそのものになっています。MySpaceのように、ガジェットではありません。ということは、もちろんコンシューマキー(oauth_consumer_key)もOrkutなら"orkut.com"、hi5なら"hi5.com"といった具合に、コンテナサイトを表すものが使用されます。

またこの方式の場合、どのガジェットがリクエストを投げているのかを表すため、xoauth_app_urlというパラメータが追加されます。これを提案しているのがOAuth Gadget Extensionです。

MySpaceのようにHMAC-SHA1を使っている場合は、ガジェットごとにコンシューマキーを設定し、ガジェットのリクエストをコンテナがProxyするという形を取っていました。これはShindigを使っているiGoogle、Orkut、hi5と、独自にOpenSocialを実装しているMySpaceとの方針の違いから来るものです。

HMAC-SHA1方式でコンテナをコンシューマとして扱おうとすると、シークレットは2者間のみで共有されなければならないため、コンシューマは、サービスプロバイダごとにキーとシークレットを発行しなければなりません。しかし、RSA-SHA1方式であれば、コンテナがコンシューマでも、公開鍵と秘密鍵の組み合わせは一つだけあれば使い回せるため、OpenSocialにおけるmakeRequest (Outbound OAuth)のように、コンテナが外部サービスからデータを取得するアーキテクチャの場合、RSA-SHA1方式にした方がコンシューマにとってサービスプロバイダの追加も容易になりますし、サービスプロバイダにとってコンシューマの署名を確認する作業も楽になるのが利点です。

ShindigがRSA-SHA1方式を中心に実装されているのはそんな理由がありそうです。ちなみに、Shindigの開発はGoogleが中心になって行われており、HMAC-SHA1方式についても現在実装中らしいですが、iGoogleでのコンシューマキーとコンシューマシークレットの発行は、メールで依頼することになっているため、今のところ本気で考えてはいなさそうです。
In the case of the iGoogle sandbox, you can send mail to oauthproxyreg@google.com with the following information to register your shared secret:
* URL of your gadget
* The shared secret assigned to you by the service provider
* The consumer key assigned to you by the service provider
* Whether to use symmetric or asymmetric signing with the service provider (or say that you don't know)
Until your shared secret has been registered, your gadget will not work.  If you change the URL of your gadget, you will need to re-register the secret for that gadget.

まとめ


現時点ではOpenSocialのOutbound OAuthではMySpaceがHMAC-SHA1方式でガジェットをコンシューマに、Shindig系コンテナはRSA-SHA1方式でコンテナをコンシューマにしていますので、外部サーバーとやり取りを多なうOpenSocialガジェットを作る場合、どちらからのリクエストも受け付けられるよう構築しておく必要がありそうです。

参考サイト



2008年9月28日日曜日

OpenSocial v0.8.1が公開

OpenSocial v0.8.1仕様が公開されました。

※翻訳については一部ベータ版からの修正内容が反映されていない箇所があります。誤りを見つけた際はご指摘ください。

リリースノートは下記の通り:

OpenSocialリリースノート


OpenSocialの仕様変更点

  • サーバーサイドAPIの変更 サーバー間通信機能に、よりシンプルなバッチ処理を可能とするJSON RPCプロトコルが追加されました。名前の一貫性を保つため、RESTful APIは今後RESTfulプロトコルと呼ばれます。

  • OpenSocial IDで許可する文字に"-", "_", "."を追加 OpenSocial IDは従来の英数字に加え、"-", "_", および"."を含むことができます。

  • Portable Contacts仕様にアライン


互換性のない変更点


  • RESTfulプロトコルの非互換性 RESTfulプロトコルから多くのクエリやレスポンスフィールドが名称変更/削除されました。RESTfulプロトコルの変更点全てを下記に示します。


RESTfulプロトコルの変更点

  • PortableContactsとの互換性 RESTfulプロトコルを実装することで、コンテナはPortableContacts仕様と技術的互換性を持つことになります。下記の変更点はこの互換性実現のために実装されました。

  • 新しいレスポンス型format=xml リクエストがformat=xmlパラメータをサポートするようになりました。Peopleのリクエストはformat=xmlかformat=jsonで行われなければなりません。

  • コンテナはランダムアクセスなページングを実装しなければならない コンテナはstartIndexとitemsPerPageパラメータを使ったページングの実装が必須となりました。

  • コレクションのフィールドからrel=nextリンクが廃止 このパラメータはJSONコレクションレスポンスから削除されました

  • コレクションのフィールドからauthorが廃止 このパラメータはJSONコレクションレスポンスから削除されました

  • コンテナは全てのコンタクトを一度に返せなければならない コンテナは一度のリクエストで全てのコンタクトを返すことができなければなりませんが、パフォーマンス上の理由から返すコンタクトの数に上限を設けることができます。

  • itemsPerPageのデフォルト値 itemsPerPageパラメータがリクエストで指定されていない場合のデフォルト値はコンテナに依存します。

  • ソートパラメータの変更点 orderByパラメータはsortByに名称変更されました。また、sortOrderパラメータが追加され、ascending(昇順)とdescending(降順)を与えることができます。デフォルトはascendingです。

  • updatedSinceパラメータの追加 クエリで、指定された期間内に更新されたエントリのみを返すよう指定することができます。

  • ソートおよびフィルタリングが行われたかをレスポンスに表示 ソートやフィルタリングはコンテナにとってコストが高いため、実際にリクエストと同じ内容のフィルタリングが行われたかを示す、トップレベルのレスポンスフィールドfiltered, sorted, updatedSinceがレスポンスに含まれるようになりました

  • 削除されたPersonオブジェクトのリクエストが可能に 新しく追加された@deletedセレクタとupdatedSinceパラメータを利用することで、指定された日時以降に削除されたコンタクトの取得が可能になりました。

  • Personレスポンスは最低でもidとnameフィールドを含まなければならない コンテナはnameおよびidフィールドをPersonデータに含まなければなりません。

  • profile URLはURLでもなければならない PersonのprofileUrlフィールドで返される値はtypeがprofileのエントリのurlsフィールドでも返されなければなりません。

  • Personにphotosフィールド追加 Personにurl, type, primaryサブフィールドを持ったエントリのリストを含む、photosフィールドが追加されました。PersonオブジェクトでthumbnailUrlフィールドが返された場合、このurlはtypeがthumbnailであるエントリのphotosフィールドにも存在しなければなりません。

  • Personにimsフィールド追加 Personにvalue, type, primaryのサブフィールドを持ったimsフィールドが追加されました。type値としてよく使用される"aim", "gtalk", "icq", "xmpp", "msn", "skype", "qq", "yahoo"が定義されていますが、新しいtypeを定義することもできます。

  • Personにaccountsフィールド追加 Personにその人がアカウントを所有する他のサービスを表すaccountsフィールドが追加されました。このフィールドはdomain, userid, username, primaryサブフィールドを持ったエントリのリストを含みます。

  • Personの複数フィールドにprimaryサブフィールド追加 Personのemails, urls, ims, phoneNumbers, addresses, organizations, photosフィールドに、リスト中どのフィールドが主たるものか(存在する場合のみ)を示すprimaryサブフィールドが追加されました。

  • jobsおよびschoolsの複数フィールドをorganizationsに統合 jobsおよびschoolsのエントリはorganizationsという名前のOrganization構造の配列にまとめられました。Organization構造は"job"、"school"を正規値とするtypeサブフィールドで拡張されます。

  • Personの複数フィールドをvalueフィールドに標準化 Personの複数フィールドで主となるテキスト値はvalueというサブフィールドに保存されるべきです。これはemails.address, phoneNumbers.number, urls.addressおよびすべての{Enum}.keyフィールドのインスタンスを{Enum}.valueに名称変更することが必要となります。addresses, accounts, organizationsフィールドは複雑なため、valueフィールドのコンセプトが存在しません。ソートやフィルタリングを行うため、これらのフィールドの"主たる"サブフィールドに該当する部分は、addresses.formatted, accounts.domain, and organizations.nameとなります。

  • Person.genderフィールドは文字列に Personではgenderを文字列フィールドとして扱い、"male"および"female"を正規値とします。

  • AddressesからextendedAddressまたはpoBoxサブフィールドが廃止 streetAddressサブフィールドに完全な(複数行の場合もある)住所を保存することができるようになったため、AddressサブフィールドのextendedAddressおよびpoBoxが廃止されました。

  • unstructuredAddressをformattedに変更 AddressのunstructuredAddressサブフィールドはformattedに名称変更されました。

  • dateOfBirthをbirthdayに変更 PersonのdateOfBirthフィールドはbirthdayに名称変更されました。

  • timeZoneをutcOffsetに変更 PersonのtimeZoneフィールドはutcOffsetに名称変更されました。

  • nicknameの定義 Personのnicknameフィールドは"現実世界でこの人物を指すくだけた方法"と定義されました。

  • Personフィールドのデフォルトセット Personリクエストでクエリパラメータfieldsがない場合、JS APIのデフォルトと一致させるため、最小限必要とされるデフォルトセットとしてid, name, thumbnailUrlが定義されました。

  • supportedFieldsのクエリ RESTfulプロトコルにコンテナがサポートするPersonおよびActivityフィールドをリストで返す/people/@supportedFieldsおよび/activities/@supportedFieldsというエンドポイントが定義されました。

  • indexByの廃止 indexByクエリパラメータは廃止されました。

  • Activity.titleフィールドはHTML文字列に Activityタイトルフィールドは複雑なデータオブジェクトではなく、HTMLマークアップを含む文字列として扱われるようになります。

  • unstructuredをformattedに変更 名前フィールドのunstructuredはformattedに変更されました。

  • displayNameフィールドを追加 PersonフィールドのトップレベルフールドとしてdisplayNameが追加されました。


RPCプロトコルの変更点

  • RPCプロトコルが登場 バッチ処理や複雑なサーバー間処理を簡易化するためのオプションとして、新しくRPCプロトコルが登場しました。


opensocial.* JavaScriptの変更点

  • 新しいopensocial.IdSpec.GroupId enum IdSpecオブジェクトを構成するため、opensocial.IdSpec.GroupId.FRIENDSまたはopensocial.IdSpec.GroupId.SELFを使用することができます。

  • supportsFieldのレスポンスを定義 opensocial.Environment.supportsField()の戻り値として、コンテナがフィールドをサポートする場合はtrue、そうでない場合はfalseを返すことが定義されました。


gadgets.* JavaScriptの変更点

  • gadgets.* JavaScript APIに変更点はありません。


Gadgets XMLの変更点

  • 要素でOAuthをサポート 要素のauthz属性で"oauth"値がサポートされるようになりました。authzがoauthの場合、oauth_service_name, oauth_token_name, oauth_request_token, oauth_request_token_secret属性が取得されます。これらの属性はgadgets.io.makeRequestパラメータに一致するものと同様の意味とデフォルト値を持ちます。



2008年9月18日木曜日

オープンなコンタクトリスト仕様、Portable Contacts

PlaxoのJoseph Smarr氏が使う言葉に"Open Building Blocks for the Social Web"というものがあります。これはウェブをよりソーシャルにし、サービス相互の連携を深めていくために必要な"要素"を表しています。

この"要素"にはOpenID, OAuth, microformats, OpenSocialと、いずれもこのブログで取り上げてきたこれからのソーシャルウェブを占う重要な規格が挙げられていますが、そんな重要なピースのひとつに、Portable Contactsが加えられました。

Joseph Smarr氏の在籍するPlaxoにて、既に利用可能なAPIが公開されています。

Portable Contactsとは


Portable Contacts, is an easy-to-implement "people data" API that provides secure access to both traditional address book data and to modern social application data (profiles and friends lists).

PortableContactsとは、従来のアドレス帳データと最近のソーシャルアプリケーションデータ(プロフィールと友達リスト)のいずれにも、セキュアなアクセスを提供する、簡単に実装可能な"Peopleデータ"のAPIです。

現時点の仕様の中身を見てみると:

  • ディスカバリの方法(XRDS-Simple)

  • 認証/認可の方法(OAuth, Basic認証)

  • クエリパラメータ(ソート、フィルタ等)

  • 応答フォーマット(JSON, XML)

  • エラーコード

  • Contactのスキーマ


といった内容になっています。vCardやOpenSocial等、既存の仕様から大きく外れないよう意識して設計されているとのこと。

Portable Contactsの使いどころ


Portable Contactsはアドレス帳や友達リストを表すものですので、様々な分野で応用できることが予想されます。

ソーシャルネットワークサービス間の友達リスト交換


既にMySpaceのDataAvailabilityでサービスイメージが示されていますが、MySpaceの友達リストをTwitterにインポートする、なんてことが可能になります。

デスクトップアプリとのアドレス帳交換


例えばMac OS Xのアドレス帳アプリとMicrosoft Outlookのアドレス帳を、ウェブサービスを通じて同期するなんて事も、これまで以上に統一した規格の上で行う事ができるようになります。

携帯電話とSNSのアドレス帳を同期


自分が利用しているSNSの友達リストをそのまま携帯電話に乗せたり、その逆を行う事ができるようになります。ここでRipplexのようなサービスが間に入ると、さらに面白いことができるようになるでしょう。

OpenSocialとの関係


あれ、じゃあOpenSocialとPortable Contactsて同じじゃないの?と思った方もいるのではないでしょうか。そう、基本的にOpenSocialのPeople APIとPortable Contactsの役割は同じです。似た仕様が複数存在する事はあまり好ましくないため、個人的にも疑問に思っていました。

実はJoseph Smarr氏の働きかけにより、Portable ContactsはOpenSocial v0.8.1仕様で統合されました。言い換えると、OpenSocialのPeople APIの仕様とPortable Contactsの仕様は同じです。

OpenSocial v0.8.1の仕様はまもなく公開されると思いますが、内容はPortable Contactsに沿ったものになっていることが確認できます。

まとめ


ソーシャルウェブエコシステム構築の動きは、Portable Contactsのようなピースが揃う事でさらに加速してきています。今後もソーシャルウェブのメインプレイヤーたちの動向から目が離せません。

2008年8月6日水曜日

Data AvailabilityでOAuthを試す

前エントリでの予告通り、実際にサーバーサイドでコードを書き、MySpaceのData Availabilityを使ってOAuthを試してみます。Data Availabilityという名前は大げさに聞こえるかもしれませんが、実際はOpenSocial RESTful APIです。ちなみにData AvailabilityではまだJSON形式のみのサポートで、AtomPubには対応していません(しかも404が返ってくる。これに相当ハマった○| ̄|_)。

今回はOAuthを使って認証・認可を取得し、Data Availability APIを叩くところまでを解説します。

下準備


まずはサンドボックス環境にMySpaceにアプリを作ってください。細かい手順が分からない方はこの辺を参考にしてください。

MySpaceではガジェットアプリも外部アプリも同じように扱われるようです。



Edit Detailsを開くと、アプリケーションの詳細設定を編集することができます。

ここでOAuthの利用に必要なものを思い出してください。まずはコンシューマキー(consumer_key)とコンシューマシークレット(consumer_secret)です。



MySpaceの場合、アプリケーションを登録した段階でこれら2つが発行されます。コンシューマキーについては好きなものに変更できますが、ここではアプリケーションのガジェットXMLぽいURLにしてみました。後で必要になりますので、どこかにコピペっておきましょう。



次に、同じページの下の方にExternal Site Settingsという項目があります。これがData Availabilityの肝です。

  • Use External Domainにチェックを入れる

  • External URLにMySpaceからの誘導先URLを入力

  • External Domainに実際に外部アプリを置くサーバーのドメインを入力

  • 利用規約を読んで同意


これで準備オッケー。

OAuthを実装する




今回試すのは上図の外部サービス、つまりコンシューマに当たる部分です。サービスプロバイダに当たるのはMySpace。ゼロから実装してもよいのですが、せっかく便利なライブラリがありますので、これのPHP版を使って試してみます。また、署名方式はHMAC-SHA1を使います。

OAuthのフローは下記の通り。この辺りを読んで仕様を理解しておく事をお勧めします。

  1. リクエストトークンを取得

  2. ユーザー認証

  3. アクセストークンを取得

  4. リソースにアクセス


リクエストトークンを取得


必要なライブラリをインクルードします。
[sourcecode language='php']require_once 'oauth/OAuth.php';
require_once 'oauth/OAuth_TestServer.php';[/sourcecode]
各種変数をセットしておきましょう。先程メモったconsumer_keyconsumer_secretはここで使います。リクエストトークンを取得するためのエンドポイントはMySpaceのドキュメントに記載されています。
[sourcecode language='php']$consumer['key'] = 'http://devlab.agektmr.com/MyOpenSpace/DataAvailabilityExample';
$consumer['secret'] = '************';
$endpoint = 'http://api.myspace.com/request_token';[/sourcecode]
署名のロジックはめんどくさいのでライブラリにお任せ。
[sourcecode language='php']$server = new TestOAuthServer(new MockOAuthDataStore());
$server->add_signature_method(new OAuthSignatureMethod_HMAC_SHA1());

$sig_methods = $server->get_signature_methods();
$sig_method = $sig_methods['HMAC-SHA1'];

$consumer = new OAuthConsumer($consumer['key'], $consumer['secret'], NULL);
$request = OAuthRequest::from_consumer_and_token($consumer, NULL, "GET", $endpoint, null);
$request->sign_request($sig_method, $consumer, NULL);

$req = curl_init($request);
curl_setopt($req, CURLOPT_RETURNTRANSFER, 1);
$result = curl_exec($req);[/sourcecode]
ここまでのコードで$resultにリクエストトークンが返ってくることになります。URLのquery部と同じ形式で返ってきますので、必要に応じてパースしましょう。
[sourcecode language='php']parse_str($result, $tmp);[/sourcecode]
これで、oauth_tokenoauth_token_secretが取得できたはずです。

認証


次にユーザーに認証を行ってもらいます。エンドポイントはhttp://api.myspace.com/authorizeで行います。その際、先程取得したoauth_tokenoauth_callbackをパラメータとして付属します。oauth_callbackは認証後に呼び出されるページのURL。
[sourcecode language='php']$callback_url = 'http://devlab.agektmr.com/MyOpenSpace/access.php';
$auth_url = 'http://api.myspace.com/authorize?oauth_token='.urlencode($tokens['oauth_token']).
'&oauth_callback='.urlencode($callback_url);[/sourcecode]

アクセストークンを取得


先程指定したoauth_callbackのURLにoauth_tokenをパラメータとして付属してリダイレクトされてきます。これはこのoauth_tokenが認証済みであることを示しており、アクセストークンへの交換が可能となります。
[sourcecode language='php']$consumer = new OAuthConsumer($consumer['key'], $consumer['secret'], NULL);
$tokener = new OAuthConsumer($tokens['oauth_token'], $tokens['oauth_token_secret']);
$access = OAuthRequest::from_consumer_and_token($consumer, $tokener, "GET", $endpoint, null);
$access->sign_request($sig_method, $consumer, $tokener);

$req = curl_init($access);
curl_setopt($req, CURLOPT_RETURNTRANSFER, 1);
$result = curl_exec($req);[/sourcecode]
コードはリクエストトークン取得の際とあまり変わりありません。これでアクセストークンのoauth_tokenoauth_token_secretが返っきたら準備オッケー。

RESTful APIを叩く


ここまでに取得したconsumer_keyconsumer_secretoauth_tokenoauth_token_secretを使って署名したOAuthリクエストをRESTful APIに投げることにより、友達リストなどのデータ取得が可能になります。
[sourcecode language='php']$consumer = new OAuthConsumer($consumer['key'], $consumer['secret'], NULL);
$tokener = new OAuthConsumer($tokens['oauth_token'], $tokens['oauth_token_secret']);
$resource = OAuthRequest::from_consumer_and_token($consumer, $tokener, "GET", $endpoint, array('format'=>'JSON'));
$resource->sign_request($sig_method, $consumer, $tokener);

$req = curl_init($resource);
curl_setopt($req, CURLOPT_RETURNTRANSFER, 1);
$result = curl_exec($req);[/sourcecode]
これでエンドポイント($endpoint)を取得したいリソースのURLにすればOK。レスポンスボディにJSON形式でデータが返ってきます。

サンプルアプリ


上記コードを使って一連の流れを見ながら動作を確認できるサンプルを用意しました。どういうリクエストを投げるのか参考になると思います。

実際に動作するサンプルはコチラ



2008年8月2日土曜日

OpenSocialのOAuthまとめ

OpenSocialでは、コンテナが外部サーバーとの通信を行う際、または外部サーバーがコンテナと通信を行う際、OAuthを使用して認可を行います。今回はOpenSocialにおけるOAuthについて、現段階でのまとめを書いてみます。 ※追記(2008/10/20):2008/10/4に書いたコチラの記事も必読です。

OAuthって何だったっけ?


OAuthはユーザーコンシューマサービスプロバイダの3者間でデータのやり取りを行うとした場合、ユーザーがコンシューマにクレデンシャル(IDやパスワード)を渡すことなく、ユーザーが所有するサービスプロバイダ上のリソースにコンシューマをアクセスさせるためのものです。 例えばユーザーGoogle(サービスプロバイダ)アドレス帳(リソース)MySpace(コンシューマ)上で利用するシーンを思い浮かべてください。OAuthがなければ、MySpaceにGoogleのIDとパスワードを預けなければならなかったものが、OAuthを使うことで、ユーザーが直接Googleと認証のやりとりを行い、MySpaceにGoogleのID/パスワードを渡すことなく、アドレス帳のデータをMySpaceに渡すことができるようになります。

2種類のOAuth


さて、そんな便利なOAuthですが、OpenSocialで利用されるものには2種類あります。

OAuth Core


OAuth Coreでは、先程説明したように、ユーザーコンシューマサービスプロバイダの3者間でやり取りを行います。ベーシックなものですので、詳細についてはこの辺りを参考にしてください。

OAuth Consumer Request


一方OAuth Consumer Requestは、OAuthの仕様からユーザー認証部分を除き、コンシューマとサービスプロバイダのやり取りにフォーカスした仕様で、一般に"two-legged OAuth"と呼ばれます。これはコンシューマとサービスプロバイダの信頼関係だけで、ユーザーによる認証を伴わない仕様のため、コンシューマがサービスプロバイダからパブリックな情報を取得したい場合に利用するケースが想定されます。 (かなり恥ずかしい間違いです。正確にはコンシューマが署名を付加することで、サービスプロバイダがリクエスト元とリクエスト内容に間違いがないことを確認できる仕様、です。/ 2009年10月追記)ちなみにOpenSocial v0.7ではOAuth Coreの利用は仕様に含まれておらず、このtwo-legged OAuthを利用することになっています。OAuth Coreが利用できるのはOpenSocial v0.8以降での話になります(もちろん、two-legged OAuthも利用できます)。

OpenSocialにおけるOAuth利用パターン


OpenSocialでOAuthを利用する形態として、さらに2通りが考えられます。

ガジェットが外部サーバーとやり取りを行うOutbound OAuth


ここでは仮にOutbound OAuthと呼びます。type="html"で作られたガジェットが、SNSコンテナをプロキシとしてコンシューマの役割を果たし、サービスプロバイダとなる外部サーバーとmakeRequestで通信を行うケースです。

外部サーバーがコンテナとやり取りを行うInbound OAuth


ここでは仮にInbound OAuthと呼びます。コンシューマとなる外部サーバーがサービスプロバイダであるSNSコンテナのRESTful APIを叩くケースです。type="url"のガジェットが外部サーバーを通してSNSコンテナのRESTful APIを叩くケースもこれに該当します。

OAuthの利用に必要なもの


OAuthの利用には前提条件がいくつか存在します。細かい仕様は別途調べていただくとして、事前に必要な条件が下記になります。

  • コンシューマが、サービスプロバイダの発行する以下を事前に知っていること。

    • コンシューマキー(consumer_key)

    • コンシューマシークレット(consumer_secret)



  • コンシューマが、サービスプロバイダとOAuthのやり取りを行う以下3つのURLを知っていること

    • サービスプロバイダのリクエストトークンURL

    • サービスプロバイダのアクセストークンURL

    • サービスプロバイダの認証URL




※追記(2008/10/20):コンシューマシークレットについては、署名方式がRSA-SHA1の場合、必須ではありません。詳しくはコチラ。 OAuth利用パターンごとにどのようにしてこの条件をクリアするかを検証してみます。

Outbound OAuthのケース


ガジェットが外部サーバーとやり取りを行うケースですので、まずはガジェット開発者がSNSコンテナにコンシューマキーとコンシューマシークレットを登録します。ですが僕の知る限り、まだOutbound OAuthを実装しているSNSはありません。なので、ここでは何かしらの手段を用いて(SSLページでFormを使って投稿等)、コンシューマキーとコンシューマシークレットをコンテナに渡したものと想定してください。(今後順次、これを実現する方法は登場するものと思われます。) 次に、サービスプロバイダの各種URLを渡す必要がありますが、v0.8ではガジェットXMLで渡すよう規定されています。OAuthをModulePrefsの中に作成してください。

[sourcecode language='xml']







[/sourcecode]

OAuthは必ずしも1つのサーバーとやり取りするとは限りませんので、Serviceを追加することで複数をサポートすることができるようになっています。Service@nameで使い分けることが出来るようになっていますので、必要に応じてmakeRequestのopt_paramsに下記のパラメータを加え、サービスを指定してください。
gadgets.io.RequestParameters.OAUTH_SERVICE_NAME

サービスプロバイダとOAuthのやり取りを行うURLについては、XRDS-Simpleによって解決する方法もありますが、こちらについては別の機会にまとめてご紹介します。

Inbound OAuthのケース


外部アプリケーションがSNSコンテナのRESTful APIにアクセスする場合になります。これはまさに、FacebookのFacebook ConnectやMySpaceのData Availability、GoogleのFriendConnectに該当するもので、まだ実験的な段階にあると言えるものです。 コンシューマキーとコンシューマシークレットですが、SNSコンテナ上でアプリケーションを登録することで発行されます。それをディベロッパがメモ/コピペしてコンシューマとなるサーバーのコードに埋め込みましょう。URLについては、単純にヘルプページを見る方法と、XRDS-Simpleによるオートディスカバリを行う方法が考えられます。

まとめ


今回は大まかな話を書きましたが、次回は実際にMySpaceのData Availabilityを使ってOAuth認証を行い、データを取得するところまでを試してみたいと思います。

2008年7月10日木曜日

OpenSocial API仕様(v0.8)を翻訳しました

OpenSocial API仕様(v0.8)

一ヶ月くらい前から出来てたのですが、一応ブログ記事にも書いておきます。何か間違い等ありましたらお知らせください。

2008年6月20日金曜日

FriendConnectから垣間見える未来のソーシャルウェブ

今更ですが、先日サンフランシスコで開かれたGoogle I/Oに参加してきました。

その中でも特に印象に残ったのが、PlaxoのJoseph Smarr氏によるOpenSocial, OpenID, and OAuth: Oh My!というセッション。僕が見たセッションの中ではダントツの人気で、部屋に用意された椅子はもちろん、立ち見で人が溢れ返るほどの盛況ぶり。

内容は、ソーシャルウェブの未来について。現在はOpenSocialというソーシャルグラフを所有するサービスに閉じた世界が中心となりつつありますが、少し未来のウェブはOpenSocial, OpenID, OAuth, PortableContacts等の技術によって、よりグローバルな意味でのソーシャル化が図れるようになる、というものです。

詳細はGoogle Codeにビデオとスライドがアップされていますので、ご覧ください。かなり早口ですが、大変面白い内容です。


OpenSocialとFriendConnectの持つ意味


OpenSocialにはv0.7まで、JavaScriptのAPIしか存在していませんでした。これはOpenSocialコンテナにとっては外部サービスからガジェットとしてアプリケーションを追加してもらい、そのOpenSocialコンテナが持つソーシャルグラフに閉じた形で利用されるものでした。アプリケーション開発者はOpenSocialのJavaScript APIを使い、ガジェットが置かれているコンテナサイトの友達リストを取得し、そこでアプリケーションを動かすことができます。もちろん、ガジェットを自分のサービスドメイン上でホスティングすることも可能ですが、ガジェットはコンテナ上でしか動作せず、友達リストを外部サービスとしてインポートしたりといったことも不可能で、実質的に囲い込みサービスしか生まれないものと言えたでしょう。

それがOpenSocial v0.8 + FriendConnectによって一気に世界を広げます。ユーザーはFriendConnect対応サイトを利用するに当たり、OAuthを使って自分が利用したいSNSサービスを選ぶ権利が与えられています。同時に、そのサイト上での活動内容は連携を選択したSNSサービスに戻されます。

ここでソーシャルサービスの要素を思い出してください。

  1. アイデンティティ

  2. ソーシャルグラフ(友達リスト)

  3. エントリの公開範囲の制御(プライバシー)

  4. フィード


FriendConnectはアイデンティティをOpenIDで、ソーシャルグラフをOpenSocial v0.8のRESTful APIで、エントリの公開範囲の制御をOAuthで、フィードをActivity Streamで解決しようとしています。

これらの意味するところを深く見つめて行くと、未来のソーシャルウェブが自ずと見えてきます。

Joseph Smarr氏(Plaxo)による未来のソーシャルウェブ論


FriendConnectのイメージをさらに深めるため、Joseph Smarr氏が、PlaxoのFriendConnect対応に際してアップしていたブログエントリをご紹介します。

Plaxo and FriendConnect are now Best Friends
Plaxoが完全にFriendConnectと連携した。FriendConnectとは、あらゆるサイトをソーシャル化する、Googleによるウィジェットベースのツールである。これにより、FriendConnectに対応していれば、どんなサイトでもPlaxoアカウントに安全に接続し、サイト上に自分の友達がいるかを確認したり、友達を招待したりといったことができるようになる。何よりも素晴らしいのは、そのサイトでの活動内容をPulseに流し込むことができるようになり、Plaxoでの友達がウェブを跨いであなたと連絡を取り合うことができ、あなたが発見した新しいサイトを知ることができる点だ。

これは本当に便利でわくわくする連携機能だ -- これはユーザーが自分のアイデンティティと関係をウェブ上のどこでも利用できるようにし、新しいサイトで知人を見つけ出し、活動内容を既存の友達に共有し、よりソーシャルな発見と共有という徳の高いサイクルを生み出す、シームレスソーシャルウェブエコシステムにさらに近付いたと言える。これこそソーシャルウェブの進むべき道だ -- (現在あるほとんどのサービスがそうだが)新しいソーシャルサイトを使い始める度に最初からやり直さなければならないなんてとんでもない。あなたの新しい体験全てが、他の人をも魅了すべきだ。

これはサービスがユーザーに自分の持つデータの制御を与え、オープンスタンダードを使って安全なアクセス権を提供することによってのみ成り立つ。そしてこれこそまさに、PlaxoがFriendConnectを使ってやりたかったことだ。Plaxoアカウントを接続する際、我々はOAuthを使う。そのため、Plaxoのパスワードを渡す必要もないし、後で接続を断つことも可能だ。FriendConnectを使ってあなたが活動内容をPulseに共有する際は、OpenSocial 0.8 RESTful Activities APIを利用する。オープンスタンダードではない連携はアドレス帳APIのみであり、我々はこのスタンダードについても取り組みを開始している。我々はアイデンティティプロバイダとして、ソーシャルグラフプロバイダとして、そしてコンテンツアグリゲータとしての役割を果たしていると強く信じている -- つまり、我々はユーザーが自身のデータと関係性をウェブ上のどこにでも持ち回り、どこからでも共有できるようにしている -- これはユーザーにとっても、Plaxoにとっても、ウェブ全体にとっても有益なことだ。だが、まだこの取り組みは始まったばかり -- FriendConnect対応サイトから活動内容を共有する際、家族や友達、仕事関係など、共有相手をより細かい粒度で制御するなどの、更なる拡張を楽しみにしていて欲しい。

下のスクリーンショットはPlaxoとGoogle FriendConnectの連携したものだ -- FriendConnectを利用しているサイトでも体験してもらうことができる。

画像は実際のページをご覧下さい。

まとめ


ガジェットコンテナとしてのOpenSocialには正直、懐疑的な部分があったのですが、FriendConnectの描く未来を想像し、またわくわくしています。今後もこの辺りの動向を追って行きます。

追記


似たような話題に触れた記事を見つけたので追記し、トラバっておく。(失敗したので断念○| ̄|_)

グーグルが見たソーシャルネットワーキング--その3つの傾向:スペシャルレポート - CNET Japan

2008年6月17日火曜日

OpenSocial RESTful API Specificationを翻訳しました

これまで公開していたOpenSocial RESTful API Proposalの翻訳を、OpenSocial v0.8仕様のリリースで公開されたOpenSocial RESTful API Specificationに置き換えました。

ただし部分更新処理の項目についてはTBD(To Be Determined)のままになっています。問い合わせしているので、最新版に更新され次第アップします。

2008年6月12日木曜日

OpenSocialのAtomPubはXRDS-Simpleでディスカバリ

OpenSocial v0.8のRESTful API仕様では、オートディスカバリにXRDS-Simpleを利用するよう規定されています。

他方、OpenSocial v0.8で利用されるRESTful APIはAtomPub形式となっており、AtomPubではService Documentを利用するよう規定されています。

これではコンテナサイトがどちらを使うのか、両方使うべきなのか疑問が残ってしまいます。この件について、Google GroupsのOpenSocialの仕様を検討するグループ質問を投げてみました。

質問
コンテナサイトはAtomPubのService DocumentとXRDS-Simple、どちらを採用すべきなのでしょうか?両方サポートすべきでしょうか?

David Primmer氏の回答
AtomPubのService DocumentはURLの一部をテンプレート的に定義して変数を当てはめる用途には向いていない。ある程度固定されたURL上で指定することを想定されているようだ。
その点、XRDS-Simpleは空白に値を埋める形でURLをディスカバリできる点で優れている。

この点に関しては、AtomPubのPerlライブラリを実装されたたけまるさんも指摘されていて、XRDS-Simpleを利用する方が合理的であるという点では一致しています。

ただ、仕様に適合しないという意味では気持ちの悪いものであることは間違いなく、この点をどこかで解決できないかと考えています。先ほど紹介したGoogle Groupsで「AtomPubの仕様作成者に仕様変更の提案を行う予定はあるか」との質問を投げたのですが、その後応答はありません。

現時点でRod Yatesという方からこちらの仕様書から適用できるのではないかとの提案を頂いているので、AtomPub識者の方と相談して何かしらの働きかけを行っていこうと思います。

2008年6月3日火曜日

オープンソースのShindig対応SNS - Partuza!

OpenSocialのコンテナと言えばShindigですが、PHP版は既にOpenSocial v0.7への対応を完了しています。Partuza!はPHP版Shindigの開発者であるChris Chabot氏がオープンソースで開発したShindig対応SNSです。

Shindigがコンテナなのに、じゃあPartuza!は何をするの?と思われるかもしれません。今回はインストール方法と、Shindigとの関係について解説します。

Partuza!をインストールする


Shindigのインストール方法は以前解説しましたので、ここでは割愛します。仮に、Shindigが~/shindig配下にインストールされ、http://localhost:8080/gadgets/...でアクセスできるものとします。

まず、環境としてApache、PHP5(要mcrypt)、MySQL5が必須となります。

レポジトリからチェックアウト


Google CodeのレポジトリからSVNでチェックアウトします。
> svn checkout http://partuza.googlecode.com/svn/trunk/ ~/partuza

データベースを用意


適当なデータベース名、ユーザー名、パスワードで空のDBを作ってください。ひとまずここではそれぞれ、partuza、root、パスワードなしとします。この状態で、~/partuza/partuza.sqlをダンプします。
> mysql -u root partuza < partuza.sql

DocumentRootを設定


Apacheの設定(httpd.conf)でDocumentRootを~/partuza/htmlに設定し、http://localhost/でアクセスできるようにします。もちろん、Shindigとは別ドメインを用意する必要がありますので、バーチャルホストを使う等してください。

設定ファイルを修正


~/partuza/html/config.phpを編集します。ここでは先程作成したデータベース関連の情報とガジェットサーバーのルートURL(gadget_server)を設定します。ガジェットサーバーのURLが、ここではShindigのURLとなりますので、http://localhost:8080/になります。

データベースハンドラをコピー


~/partuza/Shindig/PartuzaDbFetcher.phpと~/partuza/Shindig/PartuzaHandler.phpを~/shindig/php/src/socialにコピーします。
> cp ~/partuza/Shindig/Partuza* ~/shindig/php/src/social

Shindigのデータベース設定を修正


~/shindig/php/src/social/PartuzaDbFetcher.phpにもデータベース関連の情報があるので修正します。加えてShindigがデータベースハンドラを利用するよう、~/shindig/php/config.phpも修正します。ここでは、"handlers => PartuzaHandler"としてください。

これで一通りの準備は完了。http://localhost/にアクセスしてウェルカム画面が出れば成功です。このまま登録し、Orkutライクな一般的なSNSとして利用することができます。


Partuza!とShindigの関係


OpenSocialのガジェットがiframeを介して表示されていることは以前も解説しましたが、簡単に言ってしまえば、iframeの手前がPartuza、後ろがShindigになります。Shindigでは以前から下記のURLにアクセスすることで簡易的なHTMLからOpenSocialぽい表示を行うことはできていましたが、Partuzaを使うことで完全なSNSとなります。

http://localhost:8080/gadgets/files/samplecontainer/samplecontainer.html
とはいえ、PartuzaHandlerを指定したところからも想像できるように、データベースは共有されます。なお、Chris Chabot氏のサイトで実際に動いているものを確認することができます。

Partuza!を使うことで、どうすればShindigをSNSに組み込むことができるかの解析をすることができるだけでなく、そのままちょっとしたSNSを開発することもできてしまいます。ぜひお試しください。

OpenSocialコンテナの対応状況を調べるガジェット

OpenSocialコンテナにもOrkut, hi5, MySpaceだけでなく、iGoogle, hyves, Netlogなどが登場してきました。

それぞれのSNSには特徴がありますが、仕様をいちいち調べたり、開発に当たって動作確認を行うのは面倒です。現在OpenSocial v0.8は登場したばかりということもあり、ほとんどがv0.7対応のものですが、v0.7への対応状況を確認できるガジェットというのがあります。

http://opensocial-resources.googlecode.com/svn/tests/trunk/compliancetests.xml


これで開発も少しは楽になるのではないでしょうか。

2008年5月22日木曜日

Mac OS Xアプリを管理する強力コンボ AppFresh / iusethis.com

最近のMac OS X用アプリには、自動的に更新をチェックしてアップデートしてくれるものも少なくありませんが、常に最新版を使いたい人にとって、そうでないアプリを管理するのは面倒なもの。チェック方法としてVersionTrackerや、デスクトップアプリケーションのLogicielMac Updateといった選択肢がありますが、いずれも今日紹介するコンボと比較すれば、つまらないものに思えてきます。

iusethis.com


iuserthis.comは使っているMac OS X用アプリを登録して共有するSNSです。



サイトにサインアップしてからimakeprofileというアプリを使うと、Macにインストールしてあるアプリを自動的にスキャンして、自分が主に使用しているアプリをiusethis.comに登録することができます。使用しているアプリが未登録の場合は、自分で追加することも可能。

登録したアプリは、サービスが最新版の情報を取得するので、更新が可能かどうかを調べることができます。もちろんレビューや、誰がそのアプリを使用しているのかを確認することもできます。さらには簡易的なSNS機能として、TwitterのようなFollow機能があるので、他の人のアプリ使用状況を追跡することもできます。

ちなみに僕が使用しているアプリはこんな感じ。



Facebookアプリも提供されているので、「俺こんなアプリ使ってんだぜ!」と叫びたいニーズも満たしてくれます。そのうちきっとOpenSocialにも対応してくれるでしょう。

AppFresh




AppFreshiusethis.comと連携して使えるソフトウェア更新ツールです。iusethis.comのデータベースから自動的に最新版を確認して、どれが更新できるかを知らせてくれます。その場でダウンロードからインストールまでまとめて行うこともできますし、ダウンロードのみ行うこともできます。Growlに対応しているので、ダウンロードやインストールが完了すると通知もしてくれます。

まとめ


AppFresh / iusethis.comは、SNSの楽しさで集めたユーザーに、アプリ開発者やサイト管理者の煩雑な作業を集合知として解決してもらうことで、くまなく幅広いアプリケーションの更新情報を提供可能とした最強のコンボと言えるのではないでしょうか。

※ちなみに、アプリの自動更新チェックには、RSS2.0のenclosureにアプリのリソースURLを入れるAppCastなるプロトコルが使われるケースが多いようです。

2008年5月14日水曜日

SNSのオープン化

SNSをオープン化する動き


Facebookの開発者向けプラットフォーム公開に始まったSNSのオープン化は、さらに加速度を増しています。Facebookの対抗と言わんばかりに登場したGoogle主導のOpenSocial。Facebookが自社サービスをプロプライエタリな基盤にする動きであったのに対し、Googleはその他大勢の連合を擁して、基盤の標準といえる規格を作りました。

両者のこの動きは、外部サービスをSNSの一部であるかのように取り込むという意味で共通しています。

SNSアグリゲートサービス


日本でSNSというとmixiを代表とした日記交換サイトがイメージされがちですが、Twitterのように一方通行の「Follow」が可能なものや、Flickr、Lastfm等のジャンルに特化したものもSNSと呼ぶことができます。

最近FriendFeedのように、こういった各種SNSをアグリゲートすることに特化したサービスも登場してきました。サービスに各種SNSのIDを預けることで、フィードのアグリゲーションが行われ、ユーザーはそのサイトさえ追いかけていれば必要な時だけ連携サービスを見に行くことができるようになります。

このように、ウェブの求める方向性はSNSの登場以降、IDがウェブ上のあちこちにあったとしても、使っている本人は一人であり、友達も同じなのだから、まとめちゃえばいいじゃん、にシフトしてきています。

DataPortability


DataPortabilityはそんな各SNSサービスに囲い込まれつつあるデータを解放して相互に利用できるようにしよう、という動きです。


DataPortability - Connect, Control, Share, Remix from Smashcut Media on Vimeo.

DataPortability - Join The Conversation from Smashcut Media on Vimeo.

詳細は僕もつかみきれていませんが、MySpaceのData Availability, FacebookのFacebook Connect, GoogleのFriend Connectと役者が揃ってきました。それぞれがどういう特徴を持っているのかを、追って紹介していきます。

2008年5月4日日曜日

Shindigを読み解く

以前インストール方法をご紹介した(Java版PHP版)Shindigですが、ようやくPHP版も使えるレベルになってきましたので、ソースを読み解いてみました。なお、Java版の方が実装は進んでいますが、今回はPHP版に限った話ですのでご注意ください。

Shindigとは何なのか


そもそも、の話です。

Shindigはひとことで言うと「OpenSocialコンテナのサンプル実装」です。これをダウンロードして動かすだけで、iGoogleガジェットとOpenSocialガジェットの動作テストを行うことができます。実際はOpenSocialを広く普及させるよう、数多あるSNSがShindigを参考に、もしくは流用してOpenSocialに対応することを目的にしています。

主なディレクトリ構成



  • config: コンテナ設定

  • features: 各種機能セット(JavaScriptコード)

  • java: Javaソースコード

  • javascript: HTML, JavaScriptコード

  • php: PHPソースコード


ディレクトリ解説


config


container.jsというファイルがコンテナのデフォルト設定となり、プロキシやOpenSocial APIのパス等の設定を行います。設定を変更したい場合はこのディレクトリにファイルを追加して、必要な部分のみをJSON形式で追記すれば、デフォルト設定が引き継がれます。なお、JSON形式なのは、PHPやJavaだけでなく、他の言語からも読み込むことを想定しているためと思われます。(Perl版やRuby版のShindigも開発される予定だそうです。)

features


ガジェットXMLにという形式で記述される機能(features)をセットとして読み込みます。featuresディレクトリ内は機能セットごとにさらにディレクトリに分けられていて、各ディレクトリにあるfeatures.xmlファイルで必要なJavaScriptライブラリセットが指定されています。

php


PHPのソースコードはJava版を参考にしているためか、あまりPHPらしくない実装になっています。

まずMVC形式を取っていません。オブジェクトの分け方は色々な方法がありますが、ウェブアプリケーション的なものと言うよりは、Java的な方法で(?)機能や設定ごとに、非常に細かく分けられています。メンバ変数にいちいちget〜やset〜メソッドを用意しているのもJavaっぽい。

PHPへのリクエストはリライトされ(.htaccessファイルで指定)、すべてindex.phpに読み込まれます。index.phpはリクエストのパラメータに応じて処理を6種類のサーブレットに振り分けます。

  • 静的ファイル(/gadgets/files)

  • JavaScript(/gadgets/js)

  • プロキシ(/gadgets/proxy)

  • ガジェット(/gadgets/ifr)

  • メタデータ(/gadgets/metadata)

  • OpenSocial API(/social/data)


クラスのインクルードは__autoloadが使用されているため、ほとんど書かれていません。

config.phpには各種ファイルへのパスなど、設定が記述されています。(config/container.jsとは別物です)

なお、Shindigはデータベースを使っていないので、キャッシュは/tmpディレクトリ、設定はcookie、友達リストは静的XMLファイルでそれぞれ管理されます。

まとめ


ソースコードは一見シンプルですが、かなり複雑です。Java的な実装方法に加え、他言語版Shindigとの設定等の共有を想定した汎用化など、オプティマイズする余地はかなりありそう。PHP版Shindigを既存フレームワークに取り込むのは難しくはありませんが、あくまでも参考にする程度にした方がいいと思われます。

なお、今のところOpenSocialバージョン0.7対応ですが、まだまだバグも存在しています。バージョン0.8の機能仕様が出揃ってきたところですが、Shindigでの対応は時間差が出そう。

OpenSocial APIは実装されていますが、ShindigでOpenSocial機能が使えるようになったというには、まだまだ足りない感じ。あとはOAuthとか、RESTful APIとか、、、。

2008年4月29日火曜日

オフラインでも使えるマインドマップサービス - MindMeister

今日は久々にいけてるサービスを見つけたのでご紹介。

MindMeister




マインドマップとは、言葉を枝上に分岐して記述することで、アイディアの整理するのに役立つ記法/ツールです。僕なんかは、TODOとかアイディアはポンポン出てくるんだけど、体系的にまとめることが苦手なため、これまで無料のマインドマップツール、FreeMindを利用してきました。

利用法としては

  • 議事録や講演会のメモ

  • やることメモ

  • 仕様書作成中の頭の整理

  • プレゼン資料作成中の頭の整理


という感じで、いずれもとにかく書きなぐり書きなぐり、後でグループごとにまとめる、という感じ。

なんですが、問題は、FreeMindのスピード。Mac OS Xバージョンだと、Core2DuoのMacBookですら起動に数分かかるという状況(バージョン0.8.1以降?)で、最近は立ち上げるのが億劫だったところに、MindMeisterのバージョンが2になったというリリース。

というわけで、早速試してみました。

編集機能




見ての通り、(MindManagerは使ったことないですが)FreeMindよりも多機能です。ノードごとにアイコンを付けられるだけでなく、色や文字の大きさ、メモも加えることができます。もちろん日本語も問題ありません。メモ機能は個人的にFreeMindにぜひ欲しかったものです。

さらに、まだ試していませんが、TODO管理的な機能もあるようです。

OpenID対応


最近人気が出てきたOpenIDにも対応しています。OpenIDはYahooなど、他サービスのID認証でサービスが利用可能になる共通プロトコルです。(※OpenIDを使うと認証できないため、後で紹介するウィジェットが使えません)


FreeMindやMindManagerからのインポート


マインドマップツールとしてはメジャーなFreeMindとMindManagerのマインドマップをインポートすることができます。これはありがたい。

ウィジェットやブラウザから一発投稿




箇条書きにするのがもったいないくらいですが、下記ウィジェット/ガジェットに対応

  • WIndows Vistaのサイドバーガジェット

  • iGoogleガジェット

  • Yahoo! Widget Engineウィジェット

  • Mac OS X Dashboardウィジェット


ウィジェット/ガジェットから一発投稿で、デフォルト指定されたマインドマップに追記されていきます。TODO管理で役立ちそう。これはありがたい。

他にも、IE/Firefoxの機能拡張、iPhone用追加ページなどが用意されています。

オフラインでの利用が可能




なんといってもこれでしょうか。オフライン機能。

FirefoxまたはInternet ExplorerでGoogle Gearsが必要ですが、オフラインでMindMeisterを利用することができます。これで、いつでもどこでもアイディアを書き留めていくことができますね。

まとめ


ここでは書ききれませんでしたが、実はマインドマップを共有して編集する機能や、APIまで提供されています。(今となっては古臭さすら感じる言葉ですが)Web2.0を絵に描いたようなサービスではないでしょうか。

ただ、オフライン機能等はまだ成熟しきった技術とは言えないため、今後の動向が気になるところ。Google Gears / Prism / HTML5の棲み分けはどうなっていくのか?また、ウィジェット/ガジェットの重要性は日に日に高まってきています。JavaScriptの技術は今のうちに磨いておかなければ...!

2008年4月23日水曜日

Cajaとは何か

OpenSocial周りの調査をしていると、Cajaという言葉に遭遇します。セキュアなJavaScriptを実現するもの、ということだけ分かっていたのですが、詳細を調べてみました。

クロスサイトスクリプティングとブログパーツ


gooやlivedoor、fc2などのホスティングを含めたブログサービスを使ったことのある方はご存知と思いますが、サービスによってブログパーツが貼れるもの、貼れないもの、一部だけ許可しているものがあります。なぜでしょうか?

Cookieには同一ドメインから実行されたスクリプトしか参照できないという特徴があります。これを利用して、Cookieをセッション情報や閲覧履歴の保存場所として活用しているサービスは少なくありません。上記ブログサービスがブログパーツを許可しないのは、これらの情報を悪意のあるJavaScriptから守るためです。逆に言うと、同一ドメイン上でJavaScriptが実行できれば、そのセッション情報や閲覧履歴を盗むことができてしまいます。これをXSS(クロスサイトスクリプティング)と言います。

XSSが発生するのは、投稿フォームを使って、そのドメイン上のページにJavaScriptを埋め込み、実行できるケースが挙げられますが、ブログパーツが貼れること自体もJavaScriptが埋め込めるという意味では同じであり、まともに作られたサイトであれば、まずこういったことは出来ません。

とはいえ、実際にブログパーツを貼付けることができるブログは存在しますし、セキュリティの問題を回避しつつこれを実現するためのアプローチがいくつか存在します。

JavaScriptを貼付けるためのアプローチ


ドメインを分ける


ブログを表示するドメインをセッション情報等のクリティカルなCookieを保存していないものにしてしまいます。盗むものがなければ、泥棒が入ったところで何も困ることはありません。このアプローチをとっているものにはlivedoorブログが挙げられます。

安全性の確認できたJavaScriptのみ許可する


サービス提供者が安全なブログパーツのリストを作り、ブログ管理者がそこから選ぶ、というアプローチです。ブログパーツの選択肢が狭くなるためユーザーには好まれませんが、全く貼れないよりはよいはず。gooブログやはてなダイアリがこのアプローチをとっています。

iframeで表示する


iframe内に別ドメインで表示してしまえば、上記「ドメインを分ける」と同様に扱うことができます。このアプローチを取っているものにiGoogleが挙げられます。iGoogleはブログではありませんが、ブログパーツ=ガジェットと捉えれば同じ問題を扱っていると言えます。

JavaScriptの危険な部分を無力化する


サーバーがJavaScriptを出力する前に危険な部分を書き換え、無力化してしまいます。このアプローチをとっているブログがあるか知りませんが、やり方としては誰でも思いつくのではないでしょうか。ただ、これを実現するためには膨大な労力と知識が必要となります。これがオープンソースで存在しているとすれば、どんなに素晴らしいでしょう。そして、これを実現することができるのが今回紹介する、Cajaです。

Cajaで実現できること


Cajaはカハと読みます。CajaはGoogleのオープンソースプロジェクトの名前で、これを使うことで、同一ドメイン上のページに安全に外部のJavaScriptを貼付けることが可能になります。

Caja紹介(日本語訳)

開発に当たってCajaを使って防がれるべきとされた攻撃方法の一覧

どこでCajaを使うのか


CajaはOpenSocialコンテナ上での利用を想定して作られているようです。Caja紹介(日本語訳)の説明も、Shindigでアプリケーションを利用することが前提となっており、Cajaを使ってガジェットをインラインで表示した方がパフォーマンスが向上する旨が記載されています。

Cajaの形態


実はここがまだ調べきれていない部分なのですが、どうやらJavaによるサーバーサイドでのリライトと、JavaScriptのライブラリで構成されている、ぽいです。この辺はもう少し調べる必要がありそうです。

何か他に情報をお持ちの方がいらっしゃいましたらぜひ、教えてください。

ついにiGoogleがOpenSocial対応へ

今日から、OpenSocial機能提供に向け、iGoogleでsandboxの利用が可能になりました。これは明白に、Google自身がソーシャルネットワークを基盤とした仕組みになっていくことを意味しています。以前Maka-Makaと呼ばれるプロジェクトが存在し、Google独自のSNSサービスが始まるという話題がありましたが、それがOpenSocialというオープンな形を取り、予想していたとはいえ、iGoogleという形で現実のものにされると、さすが、としか言いようがありません。

で、早速試してみました。

まずはサインアップ。こちらからできます。(言語設定は英語にしておかないと、サインアップしてもsandboxが利用できないようです。)



http://code.google.com/apis/igoogle/docs/anatomy.html

これが新しいiGoogleの画面。



画面左にあるのがインストールしたアプリケーション/ガジェット。これをクリックするとキャンバスビューが開きます。



画面右側にはUpdateとしてアクティビティストリーム(行動履歴)が表示されるとのことですが、まだ確認できていません。SNSですから、友達リストがあってもおかしくないのですが、sandboxでは友達なしの状態からスタートし、sandboxに登録しているユーザー同士でなければ友達になれないとのこと。どうやって友達になれるかは、まだ不明。実際のサービス時はGoogle Talk/Gmailのアドレス帳からスタートすることは容易に想像できます。

また他にも、ガジェットごとの設定項目の表示方法が変更されているようです。

で、せっかくのsandboxですから、早速以前作ったFriendIntroducerを試してみました。OpenSocialとはいえ、コンテナごとにビュー名は若干違うよね、ということで、ガジェットXMLにhomeビューを追記し、Developerガジェットから追加。



んー。友達がいないので、当然こういう表示になってしまいますが、動いていることは確認できました。やはりそこはOpenSocial。

まとめ


あくまで基盤とはいえ、Googleは本当に恐ろしい存在です。すべてのウェブサービスを飲み込めるくらい、地を這ってる。auやlivedoorのGmailしかり、Google App Engineしかり。何でもかんでもGoogleに乗っけてしまえってくらい。

そしてGoogleにはAndroidもあります。そう、携帯電話のアドレス帳もこの友達リストに接続できるようになるでしょう。そうすると、友達のブログ更新をメールで受け取ったり、そのままケータイで閲覧したりといったことがユーザーに何のストレスも与えずに可能になります。

あと足りないのはプロフィールビューでしょうか。Google MapやGoogle Groupsで部分的に実現されてはいますが、これがどういう形で結実していくか、見物です。

2008年4月19日土曜日

MySpaceのRESTful APIでOAuth認証を試してみる

MySpaceで公開されているMDP(MySpace Developer Platform)には、OpenSocialだけでなく独自のRESTful APIも含まれており、これを使うことでサーバーサイドにアプリケーションを作ることもできるようになっています。今回は、MDPのRESTful APIのOAuth認証にフォーカスを当ててみます。

OpenSocial/MDPのOAuthについて


OAuthとは、ユーザーとユーザーが利用したいサービス(以後サービスプロバイダ)を仲介するOpenSocial等のコンテナ(以後コンシューマ)が、サービスプロバイダの認証情報を知ることなくAPIを操ることを可能にする、認可のためのプロトコルです。

例えばユーザーがコンシューマ上でサービスプロバイダのアプリを利用しようとすると、サービスプロバイダのドメイン上にある認証画面にリダイレクトされ、ユーザーが許可をし、そこではじめて、コンシューマがサービスプロバイダのAPIを利用可能になる、という使い方が想定されています。

しかし、現在のところOpenSocialで規定されているOAuthはフルスペックではありません。ユーザーがサービスプロバイダの認証画面にリダイレクトされたり、コンシューマとサービスプロバイダがトークンを交換したりといった仕様は想定されていないのです。

これはOpenSocialガジェットがJavaScriptで動作しているためトークンを管理できない、等の理由があるようですが、MySpace独自のRESTful APIでも条件は同じようで、コンシューマキーとコンシューマシークレットがあれば、トークンなしでOAuth認証を行うことができます。

※OAuthの詳しい仕様に関してはこの辺りを参考にしてください。

アプリケーションプロフィールを作る


まずはMySpaceでアプリケーションを作る準備をします。

MySpaceでアプリケーションを作るためには、ユーザーアカウントとアプリケーションのプロフィールアカウントが必要です。下記のサイトにスクリーンショット付きで解説がありますので、参考にしてください。

MySpaceアプリケーションを作ろう - ラーニング人生。

OAuth認証の準備


アプリケーションプロフィールが作れたら、XMLやJavaScriptのコードは不要です。今回の目的はRESTful APIの認証を試すところにありますので、画面左のMy Appsをクリックし、作成したアプリケーションプロフィールのEdit Detailsをクリックしてください。



画面下部にOAuth Consumer KeyとOAuth Consumer Secretという部分があります。RESTful APIにアクセスするには、これらが必要になりますので、メモ帳などにコピペしておいてください。OAuth Consumer Keyは任意に変更できますので、変更してもよいかもしれません(保存は忘れずに)。 


OAuth Toolで認証してみる


OAuthではコンシューマキーとNonce、Timestampなどから署名(Signature)を作って認証を行います。署名の作り方は複雑なので、今回はMDPで提供されているOAuth Toolを使って試してみます。



画面右にある項目を埋めていきます。

  • Server: サーバーURL。RFC3986で言うschemeとauthorityに当たります。ここではhttp://api.myspace.comとします。

  • ResourceURL: サーバーURL以降のパス。RFC3986で言うpathに当たります。queryとfragmentは含みません。ここは/users/{user_id}/friendsとして、user_idにはあなたのユーザーIDを入力してください。他の利用可能なエンドポイントはここに記載されています。

  • Request Method: HTTPメソッド。GETとします。

  • Consumer Key: OAuthのコンシューマキー。先程メモったConsumer Keyを入力してください。

  • Consumer Secret: OAuthのコンシューマシークレット。先程メモったConsumer Keyを入力してください。

  • OAuth Token: トークン。正式なOAuthではサービスプロバイダに許可を受けてアクセストークンと交換し、初めて認可されます。今回は空の状態にしてください。

  • OAuth Token Secret: トークンシークレット。正式なOAuthでトークンの交換に必要になります。今回は空の状態にしてください。

  • OAuth TimeStamp: TimeStamp。UNIXタイムで現在時刻を入力します。今回は空の状態にしてください。

  • OAuth Nonce: Nonce。何でもよいですが、毎回必ず違う値を送る必要があります。今回は空の状態にしてください。

  • Signature Method: 署名方式。HMAC-SHA1を選択。

  • Version: OAuthのバージョン。1.0とします。

  • OAuth Mode: OAuthモード。Authorization Headerとしてください。

  • Query options: OAuth Toolの使い方。Generate URI and Submitとしてください。




これでOK。executeをクリックします。

Response Bodyにどんな表示が返ってきたでしょうか。自分の友達リストが返ってきていれば成功です。Resource URLの最後に".json"を付け加えると、結果をJSON形式にすることもできます。

まとめ


実はこのやり方のOAuthは、外部サーバーからコンテナであるMySpaceに対してリクエストを投げる場合だけでなく、OpenSocialのmakeRequestで、コンテナのプロキシを介して外部サーバーに送られるリクエストでも同じやり方が利用されます。その際は当然、自分で用意するサーバーの受け口がOAuthをサポートしている必要があります。

気になるのは、やはりトークンの交換や、サービスプロバイダ側に認証を行わせる部分が省かれていること。OpenSocialとOAuthは非常に相性が良いと思っていたのですが、認証が出来ないとなると、サービスプロバイダが持つUserIDとコンテナのUserIDを紐付けたりといったことができないことになります。僕が仕様を勘違いしているだけなのか、今後OAuthにもちゃんと対応して行くのか。

makeRequestを使った外部サーバーとのデータ交換については、また別の機会に解説します。

※API(OAuth Tool?)が不安定なようで、お昼はうまくいったのにこの記事を書いている時点では、なぜかNot Foundが返ってきてしまいました・・・

2008年4月17日木曜日

OpenSocialアプリケーションを作る(2)

OpenSocialアプリケーションを作る(1)では、ガジェットの仕組みと、Orkutでアカウントを取得するところまで書きました。今回は、前回紹介したアプリケーションのコードを解説します。

このアプリケーション(FriendIntroducer)は、自分が見た場合は友達の紹介文を書くことができ、他人が見た場合はその人に向けて書かれた紹介文を読むことができる、というmixiなどにもよくある簡単なアプリケーションです。JavaScriptやjQuery的にはもっと賢い実装方法があると思いますが、今回はOpenSocialのコードにフォーカスしますので、アホなコードは大目に見てください。

ガジェットXML


[sourcecode language='xml']< ?xml version="1.0" encoding="UTF-8" ?>


 
 
 
 


  < ![CDATA[
 
 
 
 

 

 

  ]]>
 

[/sourcecode]
ここでは

  • ガジェットの設定

  • 外部のCSSやJavaScriptを読み込み

  • 初期化スクリプトの呼び出し

  • 表示用DIV指定


を行っています。
[sourcecode language='xml'][/sourcecode]
Contentはhtmlタイプ、profileビューと指定しました。typeにはhtmlとurlが選択可能ですが、htmlとして内容をContentタグで囲まれた部分に記述しています。viewはOpenSocialの仕様上profile、canvasが想定されていますが、コンテナによってhomeやpreviewが存在するようです。ここでは例としてcanvasを使用しています。

また、viewを指定しない場合はdefaultビューとして扱われます。コンテナは表示場面(コンテキスト)によってビューを切り替えますが、Content内でviewを取り出してJavaScriptで処理を分ける方法もあります。

Contentの内容


Contentの内容は、基本的に通常のウェブページと同じように扱うことができ、HTMLで書くことができますが、
[sourcecode language='xml']  [/sourcecode]
このようにgadgets.util.registerOnLoadHandlerを使って初期化処理を入れることができます。

このアプリケーションでは、表示テンプレートとして空のdivタグを3つ用意しています。

JavaScriptのコード


JavaScriptのソースコードはここにありますが、抜粋して紹介します。
[sourcecode language='js'] $('#friends').html('Requesting friends...');
  var req = opensocial.newDataRequest();
  req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
  req.add(req.newFetchPeopleRequest('VIEWER_FRIENDS'), 'friends');
  req.add(req.newFetchPersonAppDataRequest('VIEWER', 'Introduction'), 'intro');
  req.send(FriendIntroducer.onLoadViewerFriends);[/sourcecode]
最も基本的な処理となる、閲覧者、閲覧者の友達、保存したデータを取り出す処理です。

opensocial.newDataRequest()でデータリクエストオブジェクトを作り、addで3種類のリクエストを追加、最後にsendでコールバック関数を指定した上、データリクエストを送信しています。3種類のリクエストにはそれぞれ後で区別するためviewer, friends, introという名前(キー)を付けています。
[sourcecode language='js'] var viewer = response.get('viewer').getData();
  var friends = response.get('friends').getData();
  var intro = response.get('intro').getData();[/sourcecode]
コールバック関数では、引数(response)を使って、response.get(キー名).getData()でリクエストしていたデータを取り出すことができます。
[sourcecode language='js'] var viewer_id = viewer.getId();
  var json = null;
  if (intro[viewer_id]) {
  if (intro[viewer_id].Introduction) {
  var json_str = gadgets.util.unescapeString(intro[viewer_id].Introduction);
  var json = eval(json_str)[0];
  }
  }[/sourcecode]
introは、このアプリケーションを使ってコンテナのデータ保存領域に予め保存しておいた内容、つまり「以前保存した友達の紹介文」です。
[sourcecode language='js'] $('#title').html('

Friends of '+viewer.getDisplayName()+':

');
  var html = '';
  if (friends.size() == 0) {
  $('#message').html("

You don't have any friends yet!

");
  }[/sourcecode]
友達が誰もいない場合を考慮して、メッセージを表示しています。
[sourcecode language='js'] friends.each(function(person) {
  var t = FriendIntroducer.template.friend_list_canvas;
  t = t.replace('##thumbnail_url##', person.getField(opensocial.Person.Field.THUMBNAIL_URL));
  t = t.replace('##profile_url##', person.getField(opensocial.Person.Field.PROFILE_URL));
  t = t.replace('##display_name##', person.getDisplayName());
  t = t.replace('##input_id##', 'input_'+person.getId());
  if (json) {
  t = t.replace('##intro_text##', json[person.getId()] ? json[person.getId()] : '');
  } else {
  t = t.replace('##intro_text##', '');
  }
  html += t;
  });
  $('#friends').html('
    '+html+'
');[/sourcecode]
OpenSocialでは配列をなめる、いわゆるiterationも仕様に含まれていて、eachを使うことができます。ここでは、友達のリストをループして、友達の名前やサムネイル画像、保存されていた紹介文をHTMLテンプレートに埋め込んでいきます。



ここまでで、友達の紹介文を書き込むことができるcanvasページの表示することができました。次に、友達の紹介文をユーザーが書き込んだものと想定し、投稿して保存するところまでを解説します。

データの保存


OpenSocialはコンテナにデータ保存領域を持っており、アプリケーションがデータを保存することができます。これはパーシステントデータ(Persistant data)や、アプリケーションデータ(AppData)と呼ばれています。アプリケーションデータはバージョン0.7ではエスケープした文字列のみサポートしています(次のバージョンではJSONそのものの保存も可能になるようです)。
[sourcecode language='js'] var list = $('#friends ul li');
  var intro = "{result:[{";
  for (var i=0; i < list.length; i++) {
  var textarea = list[i].lastChild.lastChild;
  var uid = textarea.id.substring(6);
  var intro_text = textarea.value.replace("'", "\'");;
  intro += "'"+uid+"':'"+intro_text+"'";
  intro += (list.length-1)==i ? "" : ",";
  };
  intro += '}]};';
  var req = opensocial.newDataRequest();
  intro = gadgets.util.escapeString(intro);[/sourcecode]
この処理は、ユーザーが友達の紹介文を書き終わって「投稿ボタン」を押すことでトリガーされるものです。DOMを辿って各友達のユーザーIDと紹介文の内容を取得する、普通のJavaScriptです。取得した内容はJSONの文字列になるよう連結し、エスケープすることで、アプリケーションデータとして保存が可能になります。
[sourcecode language='js'] req.add(req.newUpdatePersonAppDataRequest('VIEWER', 'Introduction', intro));
  req.send(function() {
  $('#message').html('

Your introduction has been submitted.');
  });[/sourcecode]
最後に、JSON形式になった文字列をデータリクエストオブジェクトに追加して送信して、完了です。

まとめ


解説というよりはソースコード並べただけみたいな記事になってしまいましたが、OpenSocialアプリケーションのほとんどがJavaScriptでできてしまうということは、分かったかと思います。次回は外部サーバーとの連携を行うmakeRequestに触れたいと思います。


OpenSocial API仕様を翻訳しました

OpenSocial API仕様 (v0.7)を翻訳しました。

Tender Surrender » OpenSocial/OpenSocial API仕様 (v0.7)

2008年4月8日火曜日

OpenSocialとかどうよ?的な勉強会(!?)に参加してきた

百式の中の人がやっているIDEAxIDEAというブログで募集があった「OpenSocialとかどうよ?的な勉強会」に行ってきました。場所は汐留のMySpaceジャパンオフィス。本国からエンジニアが来日しているとのことで、聞きたいことリストを用意しての参加です。

MDPとOpenSocialの関係


MDPとはMySpace Development Platformの略。MDPはOpenSocialより広い範囲のAPIです。言い換えると、OpenSocialはMDP上に作られている、とのこと。



OpenSocialではJavaScriptが先行して仕様決定されていっていますが、コンテナプロバイダはAjaxを受け付けるREST APIを作らないとRequestに対して応答を返すことが出来ません。そこでMySpaceの開発した仕様がMySpace REST APIでした。(当然、Orkutやhi5にもこれに類するものがありますが、仕様は未公開です。hi5はあったかな?)

MySpaceにはOpenSocialとは別にMyOpenSpaceという拡張があり、opensocialreference.jsとMyOpenSpace.jsとして区別されています。位置付けとしてはMyOpenSpaceがまずあり、それをラッピングする形でOpenSocialが存在する、と言った方が正確でしょう。OpenSocialは様々なSNSの持つAPIの最大公約数を取る形でデザインされているため、独自のAPIをラッピングすれば十分な訳です。確かにこれなら、他社SNSからアプリを持ってきたとしても、OpenSocialに対応したJavaScriptでさえあれば、互換性が保てますね。

また、RESTful APIについてはOpenSocial版が登場したときにどうするつもりか?という質問をしてみたのですが、「APIを増やすだけだよ」という回答。なるほど。そりゃそうだ。現行バージョンでアプリを開発した人向けに、古いバージョン用のAPIも残していくようです。

これで、以前から気になっていたMySpaceはまだ仕様が固まっていないはずのOpenSocial RESTful APIをどうやって実装したのか?という疑問が解決しました。

OpenSocialの拡張に当たる部分とは?



  • フォトアルバム

  • ヒーロー

  • 好みの映画


等々が既に存在する独自拡張で、最も利用されているのがフォトアルバム。確かにフォトアルバムはSNSによってあったりなかったりしつつも、使われそうな機能ですね。

また、個別送信可能なメッセージ機能は?と聞いたところ、今まさに開発中だそうです。(今見たら、OpenSocialにもうあるような、、、)他にも、音楽やコメディなど、様々な分野のAPIを作っていきたいとのことでした。

アプリケーションの登録について


アプリ開発者はSandboxのアカウントを取得すればすぐに開発を始めることが出来ますが、実際にアプリを公開するためには審査を通る必要があります。審査はコードのレビューやリーガルチェック(著作権侵害等)を経て、だいたい24時間〜48時間で公開されますが、権利関係が微妙な場合はもっとかかることもあるとのこと。

聞きそびれてしまいましたが、アプリをXMLでリモートサーバーに置いた場合でも、一度アプリが審査を通過してしまうと、GoogleGadgetのようにそれ以降のサーバー上のXMLの変更は反映されないと思われます。

メモ



  • Install Callback URL、Uninstall Callback URLはそれぞれ、ユーザーがアプリをインストール、アンインストールした直後にリダイレクトされるページのURLを指定できる。デフォルトはアプリのキャンバスページ。

  • OAuthの認可用にキーとシークレットが発行される。


マネタイズ


当然メインは広告収入になると思われますが、Facebookのようにある種のレコメンド広告で収益を得る方法もありえます。他にも、アプリ開発者に対して課金することで表示位置を優遇したり、といったことも考えられます。

今のところアプリ開発者は、自社サービスの会員獲得を目的としてアプリを提供するケースが多いようですが、キャンバスビューで全画面を使うことができますので、ここに好きなように広告を入れて収益を上げてよいとのこと。将来的にはアプリを使って物販や課金する方法の提供も検討しているとのことで、夢が広がります。

アプリケーションの互換性


以前から疑問だったOpenSocialアプリケーションのSNS間の互換性について。実は自分の中では答えが出てたのですが一応聞いてみました。

まず、MySpace独自拡張の部分を利用しなければ、当然他のSNSに持って行っても使うことが出来ます。まあ、そりゃそうですよね。でも、viewやcssはサイトごとに切り替える必要があるはず。例えばOrkutではcanvas、profileという2つのviewしかありませんが、MySpaceにはhome,canvas,profile.left,profile.rightの4つが、hi5にはhomepage,canvas,profileという3つがあります。この時点で、うーん、ですね。

ただ、やり方として、コンテナのメソッドにアプリが動いているコンテナの名前を取得するAPIがあるので、それによって動作を切り替える方法もあるよ、と教えてもらいました。なるほど。

リモートサーバーにアプリを実装できるか?


RESTful APIを使えば当然外部サイトでもアプリを使えるのですが、ここではGoogleGadgetのContent type='html'をtype='url'にできるか?という話です。

答えは、イエス。

当然、同じドメイン配下にプロキシを作って、OAuthでMySpaceのAPIを叩く仕組みを作らなければならない訳ですが、サーバー用ライブラリも用意(準備中?)されているそうです

アプリケーションディレクトリ公開後の伸び


Facebookはアプリケーション機能公開後に急激な伸びを示した訳ですが、MySpaceについてはどうか?聞いてみたところ、今のところ目立って急激な伸びは見られないとのこと。サイト上にもあまり誘導を貼っていないことから、まだその段階に達していないとの判断と伺えます。今後APIがもっとしっかりしたものになってから、色々やるんでしょうね。メッセージ機能等による口コミにも期待しているそうです。

escapeStringとunescapeStringについて


パーシステントAPIを使う際、文字列情報しか保存できないため、JSON形式でやりとりされます。その際文字列をエスケープしてから投げたり、受け取った際はアンエスケープする必要があるのですが、Orkutやhi5で使えたgadgets.util.escapeString()とgadgets.util.unescapeString()がMySpaceで使えなかったため質問してみました。

答えはescapeStringとunescapeStringはもう使われていないはずで、今はencodeURIComponentが推奨のはずだよ、とのこと。今OpenSocialの仕様を見てみたところ、まだgadgets.util.scapeString()もgadgets.util.unescapeString()も有効のようですが、、、。

MySpace用のサンプルアプリ


以前作った友達紹介アプリのMySpaceバージョンを公開します。
http://devlab.agektmr.com/OpenSocial/MySpace/FriendIntroducer.xml

別の人がこのアプリを自分のSandboxアカウントに入れることができたか分かりませんが、参考になれば。MySpaceに2つアカウント作って試すところまではまだやっていないため、物好きな方はMySpaceの僕のアカウントに友達申請してください。

感想



  • MySpaceのエンジニアの方はAptanaを使う人が多いみたい。Javaアプリはもっさりしてて嫌いなので基本的に使わないのですが、もう一回チャレンジしてみようかな・・・。

  • 何が驚いたって、参加者10人中パソコン出した人が4人。その全員がMacBook Airユーザーだったこと!
    みんなリッチだなあ。 

  • Ozzieと写真撮ってもらった!


参加者の皆様、お疲れ様でした。

※追記(4/12)


「escapeStringとunescapeStringがもう使われていない」というのは間違いではないか?の件について、当日教えてくれたTerrenceにメールで確認しました。

どうやら「escape」と言ったのを、一般的なJavaScriptのescapeと勘違いしたらしく、彼が言っていた「escapeはもう使われていない」というのは、そちらを指していたとのこと。確かに、今はescapeよりもencodeURIComponentを使うように推奨されてますね。

で、本題のgadgets.util.escpeStringとgadgets.util.unescapeStringについては、確かに、MySpaceでは実装されていないそうです。自分で解決するしかないみたい。