コミュニティをわれらの手に取り戻す：Socnodeのアイデア
すでにsocnode.orgというサイトが立ち上がっているので、可能なら、そちらを読んでほしい。Mettlach.org | Ein weiterer EU City Media Seite
ひとつだけ注意して欲しいのは、socnodeというのは、まだアイデアの提示の段階であって、サンプルとして用意されたサイトや、directeurが公開してくれたコードは、実用のためではなくて、アイデアを理解するためのものだということ。
ネタを理解したら、より具体的なアイデアと賢い実装求む、ということなのだ。
もっと望ましいのは、もっとカッコいいアイデアを提示してくれることだ。
以下は自分なりの解釈＋自分の行動方針（といっても遅々として進まないが）の表明だ。
縁起
FriendFeed(以下ff)がFacebookに買収されて、サービスの存続が危ぶまて、ff上に生まれていたコミュニティも崩壊しようかというとき、ffをオープンにするという話が出たが、それとは別にdirecteur氏が考えていたのは、以下のようなことだったと思う。
- 営利を目的とするサービスに依存するリスク（買収で消滅とか、有料化とか）を回避したい
- サービスの一極集中による全面的なサービスダウンのリスクを回避したい
- コミュニティ自体でインフラを確保したい
- 自宅サーバとか、VPSの1台くらいで知り合い達を収容できるならなんとか,,,
- コミュニティ自身で運営ポリシーを決めたい
したがって、ほぼ必然的に、サービスの分散処理というアイデアが浮上してくる。古くはnetnewsの時代から、いや、internetのほぼ全ての基幹サービスが協調型分散処理なわけだから、車輪の再発明どころではないかもしれないけれど、ベンチャーで一山当てるネタとしてではなくて、コミュニケーションツールとして何が欲しいか、開発者として何が作って楽しいか、という原点に回帰するのだということにしておきたい（笑
トータルのコストやパフォーマンスは、システムを分散しないほうが有利かもしれないし、システム全体としての機能追加などが難しくなるだろうが、ひとまずsocnodeは分散処理に舵を切った。
nodeのイメージ：メールアドレスのようなidentity付けとか
コミュニティは何人かの人間が集まってできる。コミュニティの単位として１つサーバを割り当てる。すると、特定のユーザはサーバ名（コミュニティ名）を使って「ユーザ名＠サーバ名」という名前というかidentityを持つことになる。
ところで、現状のSNSは、上記の図式で言えばサーバ名が固定された１つのコミュニティの中でのつながりしかなかったが、ffはさまざまなサービス、コミュニティを集約(aggregate)したユーザの間でのコミュニケーションを成立させた。ffのユーザが考えたsocnodeがinter-communityなものになるのは当然だろう。
ポリシー
まずお断りしておくと、この点については、現状のsocnodeのサイトではそれほど明確な話が書いてあるわけではない。
とはいえ、分散されたsocnodeは、それぞれが全く同質のサービスを提供するわけではなくて、ベーシックな部分を除けば、それぞれのnodeに情報の取捨選択に裁量の余地がある。例えば、
- feedに署名をつけて正統性を保証するnodeがあってもいい、とか
- どのnodeからのデータを信頼するかどうか、とか
- feedに対するコメントのやりとりを許可するルールはnodeごとに違っていてもいい、とか
- ユーザの友達関係に関する情報の開示のルールはnodeごとに違ってもいい（それぞれのユーザがprivateの設定にすることもあるだろうが、そもそもprivateな設定を許さないようなnodeだってあり得る）
とかである。
それらをいちいち仕様で決めていく作業には終わりが無いが、その結果としてのvalidationのツールが作れれば、多様なサービスの開発が活性化されるに違いない。
そして、流行っていて、安定して相互運用できているnodes(複数形じゃないと意味がない)が正義、ということになるだろう。
Overlay networkの仕様としてのsocnode
サンプルサイトはバックエンドにGoogleが公開しているPubSubHubbubサーバを利用している。もし、これが流行るのであれば、PubSubHubbubを複数コミュニティ（サーバ）で共有することも考えられるだろう。
Google Waveの技術がメジャーになるのであれば、それを使うことが流行るかもしれない。
つまり、socnodeは実装のかなりのレベルまで何も決めない。
今のところ変化しなさそうなのは以下のような感じだろうか。
- ユーザは「ユーザ名@サーバ名」というidentityを持つ
- ユーザは各種feedの情報を自分のidentityのもとに集約して表示できる
- ユーザは他のユーザの情報をsubscribeすることができる。subscribeした相手をfriendと呼ぶ。
- 自分のfriend(達)の情報を集約したものを http://サーバ名/ユーザ名/friends というURLでアクセスできる
- 他人のfriendsをsubscribeできる(ポリシーで許可されていれば)。すると友達の友達の情報も得られる。友達の友達が誰かの友達の情報にsubscribeしていれば、友達の友達の友達の、、、ｗ
個人的には、サーバの存続がコミュニティやidentityの存続の問題に直結してしまうのはちょっと不安なので、サーバ名とコミュニティ名を独立させておいたほうが良いと思うのだが、コミュニティ間での引越し(subscribeの付け替えを伝播させる方法が必要)をサポートできるようになるのであれば、DNSによって一意性を保証してくれるサーバ名のほうが楽かもしれない。
