読者です 読者をやめる 読者になる 読者になる

コミュニティをわれらの手に取り戻す: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付けとか

コミュニティは何人かの人間が集まってできる。コミュニティの単位として1つサーバを割り当てる。すると、特定のユーザはサーバ名(コミュニティ名)を使って「ユーザ名@サーバ名」という名前というかidentityを持つことになる。
ところで、現状のSNSは、上記の図式で言えばサーバ名が固定された1つのコミュニティの中でのつながりしかなかったが、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のもとに集約して表示できる
    • アクセスする場合のURLは http://サーバ名/ユーザ名
    • 集約した結果は(現状ではAtomの)feedにできる
      • (上記URLの link alternate atomとかを見れば、feedの場所がわかる。feedにはHubの場所が指定されているので、subscribeしたければ、現在はHubに直接subscribeできる)
  • ユーザは他のユーザの情報をsubscribeすることができる。subscribeした相手をfriendと呼ぶ。
  • 自分のfriend(達)の情報を集約したものを http://サーバ名/ユーザ名/friends というURLでアクセスできる
    • 他人のfriendsをsubscribeできる(ポリシーで許可されていれば)。すると友達の友達の情報も得られる。友達の友達が誰かの友達の情報にsubscribeしていれば、友達の友達の友達の、、、w

個人的には、サーバの存続がコミュニティやidentityの存続の問題に直結してしまうのはちょっと不安なので、サーバ名とコミュニティ名を独立させておいたほうが良いと思うのだが、コミュニティ間での引越し(subscribeの付け替えを伝播させる方法が必要)をサポートできるようになるのであれば、DNSによって一意性を保証してくれるサーバ名のほうが楽かもしれない。

僕の行動規範

まず自分が目指しているのは、自分なりのsocnodeを作って愉しむことである。現在、Erlangを使ってPubSubHubbubのクライアントを作りながら苦しみ、愉しんでいる。(すでにejabberdという立派なXMPP agentが存在しているので、純然たる愉しみでしかないが)
そして、もし必要とされるのであれば、validationツールの開発などに協力できたらいいと思っている。