次の SNS が始まっている -2

アーキテクチャ

Identity

ソーシャルネットワーク (以下 SN) は要するに "John knows Mary", "誰が誰を知っている" の定義なので, まず "私は誰" を web-wide で解決する (John を web-wide でポイントするための) システムが必要になる。
この "誰" を解決するためのシステムは, 例えば前 web 的なものでは LDAP などが該当するが, ちょうど今, 従来のシステムのインターネット対応化や, 新しいインターネットスケールでの運用を前提とした "私は誰" を指し示すシステムの開発が盛んになっており, 特にコミュニティベース, オープンアーキテクチャ, オープンフォーマット, web 対応のものを指して Identity2.0 という buzz-word が割り当てられて web のホットスポットのひとつになっている (http://identity20.com/media/ETECH_2006/)。

Identity が熱いのは web-wide なサービス/アプリケーション生態系 (または web を内部に取り入れて包括したシステム) を構築する上で欠かせない中核技術のひとつに数えられるからだ。
OpenId, TypeKey, LID, SXIP, PASSEL, iname, XDI/XRI, CardSpace(InfoCard) etc, etc と様々なベンダが絡んで様々な規格が生まれており, VeriSign のような大手ベンダも加わっている。Microsoft も新たに設計した CardSpace を投入し, CardSpace/Identity システムは Windows 戦略に於いて重要な位置を締めるように見受けられる。
SNS もこの流れに影響を受けざるを得ず, ミニマムに考えても Identity システムに対応したアプリケーションやサービスが増えればコンタクトリストやアドレスリストレベルの SN を SAML のようなフォーマットに変換して流通させる, といったことは当然考え付くわけで, Identity 方面の動きは SNS を web-wide にスライドさせるための圧力になると考えている。

SN

次に web-wide な Identity システムを元にしたソーシャルネットワークシステムを考えてみる。

まず考えられるのは Amazon のビジネス/サービスモデルのようなピラミッドモデルだ。
ある事業者が自サービスの機能を API 提供して子を作っていくモデルで, 実現シナリオとしては Identity システムを拡張した SN システムや既存の SNS 機能を API で提供する, という簡単なモデルが考えられる。
実際にこういったピラミッド型の SNS が今後幾つか出てくるだろう。幾つかは "オープンな SNS" という看板を掲げるかも知れないが, 単に接続性があるというだけだ。

次に分散型の SNS が考えられる。
これは SNS の機能を水平分離し, 例えばインフラとサービスといったレイヤに分離して, 何れのレイヤに於いても寡占モデルを作らず複数の事業者によって運用される web 的なシステムの実現を目指す。
コミュニティベースの仕様策定, オープンアーキテクチャ, オープンフォーマット, 開かれた参加性の元に実現されるだろう。
こちらが真にオープンな SNS と言え, 最初に掲げたモチベーションである SN 情報の情報財化とサービスと SN システムの分離 - もっと言えば複数レイヤに分割するというのは多対多の関係性を作り出すレイヤフリー化 - を果たすのはこちらだ。詳しくは次章に譲る。

分散型 SNS にはまだ解決されるべき課題が残っており, チャレンジャーの数もまだまだ足りない。ピラミッド型の方は幾らでも実装例も事業者もいるので放置出来るが, 分散型 SNS の実現は皆で考える問題として残っている。
今回は簡単に述べるに留まるが, 今後も分散型 SNS の実現に向けて微力でもアウトプットできるものがあればアウトプットしていきたいと思っている。まだまだ学習中, 実験中で勉強不足の部分も多いので, 是非突っ込んで欲しいし, 興味を持った人がいれば集まって一緒に出来ればとも思っている。

まず SN の情報財化を考える。
情報財 = web-based で価値を持つ事なので web-wide で機能する Identity を基に, knows(John, Mary) を FOAF, FOAFnet, XFN + XML フィードフォーマットといったオープンフォーマットで記述することになる。
既に幾つかのサービスプロバイダでこの試みは行われており, 例えば Tribe.net は FOAFnet をサポートしており, Flickr も最近 XFN によって SN をデータ的に扱えるようになった。
ローカルアプリケーションの側も, Windows Vista/Live 戦略が進むことでサポート状況がよくなるのではという期待が幾らかある。
SN 情報に記されている ID がサービスローカルの ID であるという問題が残るが, これは SN サービスプロバイダがそのまま Identity サービスプロバイダにスライドすればいい。例えば gree.jp/johndoe で OpenId のような, web-wide な identity システムをサポートすればいい。これは SNS 事業者にとっても可能性のある話だと思うので時期が来れば是非検討して欲しい。

さてここからが挑戦だ。
欲しいのはオープンな "SN 情報" だけではない。それをドライブするオープンな仕組みも必要だ。それこそが肝心だ。

ここはほとんど未知の分野なので様々な実装が考えられる。簡単ながら二点ほど挙げておく。

まず Beyond the Walled Garden (via kokogiko.net, 以下 btwg) を挙げてみる。FOAF を同期させるか, (おそらくは) 抽象化させたレイヤを作って統合していこうという仕組みだ。
btwg では API により add/remove/delete の解決が提案されているが, 個人的には API を使わなくてもより単純なアーキテクチャ, 例えば URI + XPath + REST で実現できないかと考えている。URI + XPath でノードレベルの指定は可能で, 操作はメソッドで表す。AtomPP や認証付きなら GData のようなプロトコルが考えられそうだ (GData がオープンかどうかが問題だが)。
また FOAF を維持することに努めるより, ドキュメントは編集データのスタックだと思って編集データ自体を流通させるのもいいかも知れないと考えている (あまり詳しくないが, XCAP ?)。
この辺は web 方面の議論/成果を上手に取り入れ, 組み合わせていくのが上手いやり方ではないだろうか。
また, メッセージングのようなサービスの抽象化まで考えると問題の困難さが突然増すような感触があり, 最初のゴール設定 - まず何をやって何をやらないのか決めること - は大事だと思っている。

個人的には分散的な SN インフラ, SN システムといった, web 上に雑多な SN が分散して存在するようなモデルをのほほんと考え始めている。
サービス A にはプライベートな友達の SN が存在し (そして URI が振られ), サービス B には会社の SN, サービス C には昨日飲んだ人達のリスト (SN) とあちこちに SN がある。
SN は自分で引き出してより信頼できるレポジトリである SN プロバイダに預ける事が出来る。SN プロバイダはおそらく Identity プロバイダも兼ねているだろう。
さて, 例えば mixi のような SN サービス/アプリケーションを使いたいと思った場合, Identity/SingleSign-On を使ってログインし, サービスは Identity を認知しているために sousk の Identity プロバイダから SN 情報を引き出すことが出来る。ここで SN サービスが SN プロバイダから引き出す情報は sousk により完全にコントロールされており, 例えば "sn:private と sn:18a7edtoau0a8@BarFunDeli と sn:co-workers" といった複数の SN をユーザが選択的にキャストして SN 集合を作り今から使う SN サービスに預ける。

箇条書きにすると
1. SN は SN プロバイダによりホスティングされている (URI を与えられ web 上に散在している, SN は認証を通じて引き出せる)
2. SN はユーザが完全にコントロールできる (SN, Identity, 認証はセット (LID のように Identity に鍵付きがいいかも))
3. SN プロバイダの仕事は Identity, SN のホスティングと要求に応じて複数の SN リソースから SN 集合を作りユーザ承認の元に SN サービスに供給する事
4. (もしかすると) SN サービスは SN の利用に際し利用許諾が必要で (サービスが許諾を受け入れる側 =P ), そのネゴシエーションも SN プロバイダの仕事
みたいな。ぼんやり考えていることを文章にしてみたのが今で, どうやるのか, 何が足りないのかを考えるのはまだまだこれからという状態だ。

(つづく)

# 上記文書は予告無く書き換える/変更する可能性があります。
# 訂正は訂正でちゃんと入れていきますです。