無印吉澤（※新エントリはhatenablogに掲載中）

■[年表][P2P]年表ウェブ：年表データのポータビリティ（サーバとP2Pネットワークを行ったり来たり）

※年表ウェブ（Chronologic Web）の構成要素（2005/06/07）の続きです。

以前の日記でまとめた年表ウェブの構成要素の話を踏まえて、今回は年表データの流通について考えてみます。

今回の主張は以下の2点です。

• 良い年表を長く残すために、年表データは固定サーバと動的なP2Pネットワークの間を移動できた方が良い
• 動的なP2Pネットワークだけで年表ウェブを構成するよりも、固定サーバと併用した方がメリットが多い

■ サーバ型RepositoryとP2P型Repositoryの共存

年表ウェブでは、Repositoryという構成要素が、年表や出来事などの年表データを保管し提供する機能を持ちます（過去の日記を参照）。Repositoryは、以下の2通りの方法で実装することができます。

• サーバ型Repository：常時起動していることが保証されている固定サーバがRepositoryの機能を提供する
• P2P型Repository：出入りのあるノード（ピア）によって動的に形成されるP2Pネットワークが、仮想的な1つのサーバのように*1Repositoryの機能を提供する

（以前にも図で示した内容ですけど、今回は説明のため、それぞれの実装形態に名前を付けました。）

で、前回もチラッと書きましたけど、もし僕が年表ウェブと実装するとしたら、最初はサーバ型の実装でスモールスタートしてから、徐々にP2P型のネットワークに軸足を移していくのが良いと思っています。ただし、全ての機能をP2Pネットワークに移すのではなくて、最終的には下図のように、サーバ型のRepository/CertifierとP2P型のRepository/Certifierが共存する形が良いと思っています。

（クリックして拡大）

で、上記のようなネットワークの上で、ユーザの作った年表データが

• ユーザがCreatorで年表データを作る（このユーザを作者＝Authorと呼ぶ）
• 作者は自分のサーバ型Repositoryで年表データを公開する

• 作者以外のユーザも、気に入った年表データは自分のサーバ型Repositoryで公開できる

  • これは、年表データが二次配布可能なライセンス（Creative Commons等）に準拠することで実現可能
  • 作者のRepositoryが何らかの理由で閉鎖しても、良い年表データは失われない

• またユーザは、サーバ型Repositoryに限らず、P2P型Repositoryでも年表データを公開できる

  • サーバ型Repositoryを持たない（そこまでの手間を払いたくない）ユーザでも、気に入った年表データの流通プロセスに関われる

• 更に、P2P型Repository上で見つけた年表データを、再びサーバ型Repositoryに移すこともできる

（クリックして拡大）

という感じで流通できるようにするのが、今のところ僕が頭に描いている理想像です。

■ サーバ型Repositoryのメリット

と、こういう話をすると、ここをP2P関連サイトとしてチェックされている方からは「別に全部P2P型でもいいんじゃね？」と突っ込まれそうな気がします。が、一応、以下のような点がメリットになると思っています。

1. blog等、既存Webアプリとの連携
Webサーバとサーバ型Repositoryが同じ固定サーバ上で動作していれば、両者間での連携はいろいろと考えられます。

例えばWebサーバ上でblogを公開している場合、blogツールでエントリを書くのと同時に、そのエントリに関連する出来事（当然、関連サイトとしてそのエントリのURLを含む。年表ウェブの提案（2005/05/24）を参照）をRepositoryに登録できるようにする、と便利そうです。

また、blogのエントリ表示時に自分が作成した（または拾ってきた）年表データを利用して、そのエントリが書かれた前後の出来事も一緒に表示できるようにする*2、といった二次利用の方法も考えられます。

2. 責任範囲の明確化
少し話がズレるのですが、P2P BBSのような既存のP2Pアプリでは、「P2Pネットワーク上のコンテンツへアクセスするためのゲートウェイとして動作するHTTPサーバ」を固定サーバ上で運用することがあります。

そのような形でも、同じサーバ上でWebアプリとP2Pネットワーク（この場合はP2P型Repository）へのゲートウェイを動作させれば上記1.のような連携は可能になるのですが、このようなゲートウェイは、いつの間にかユーザの望まないコンテンツの公開に荷担してしまう可能性があります。

一方、サーバ型Repositoryでは自分が明示的に追加しない限りデータが増えることはありません（年表の継承は、元データの修正ではない）。つまり、BitTorrentのように合法利用と不正利用の世界を明確に切り分けられます。まあ、BitTorrentはかなり盛大に不正利用されているみたいですけど……それでもWinnyのように合法利用と不正利用が完全に混在してしまうものよりは合法利用しやすい、ということはありそうです。

3. サービスの継続性
以前、あるP2Pアプリケーションを利用していたときに、そのアプリが形成するネットワークが悪意あるユーザから攻撃を受けて、サービス全体が長期に渡って利用できなくなる、という出来事がありました。

もちろん、そのようなサービス妨害（DoS攻撃）に強いP2Pアプリケーションを作ることは可能だと思いますが、いきなり完全な仕組みを作れるはずもなく、完成までには何度も攻撃を受けるはずです。いや、むしろDoS攻撃への完全な対策なんてあり得ず、いつまでも悪意あるユーザとのいたちごっこが続く可能性さえあります。

しかし、サーバ型Repositoryだけでも使えるようにしておけば、年表ウェブのサービスはP2P型Repositoryが使えなくなっても、（これはおかしな話に聞こえるかもしれませんが）草の根で生き延びることができます。

----

少し長くなりそうなので、今日はここまで。次回はこのような年表のポータビリティを実現するための要求条件について考えてみます。