次世代P2P Perfect Dark mission10

内部的にファイル内容のみのハッシュを持っていればいいんじゃないか
MD5, SHA-1も持つようにしとけば、ny, Shareからの移行も進みやすいと思うし。(hashdbとかが使えるので)
pd自体のファイル管理はSHA-1でもいいかな。衝突が気になるなら256

それで、エンドユーザには現仕様のファイル名+内容+キーワードから生成したハッシュを使ってもらう。
掲示板へのコピペ・保管庫等はこれでいい。
同じファイルであるが、ファイル名等と一致していない情報はbad評価・無視リストでネットワークから排除できる。

いったん欲しいファイルのキーを入手できたら、他ノードへのダウンロード要求はファイル内容のハッシュでする。
これにより、多重ダウンロードが可能であるし、DL登録時に重複チェックをすれば
[合法] と 【合法】 のような微妙な違いで同じファイルを落としてしまうなどのトラフィックの無駄を省略できる。

MD5, SHA-1 ハッシュが分かっている場合は、通常の検索と同様に
そのハッシュ値を持つファイルを一覧表示するか、またはトリガでキーワードに指定する。

よって、キー情報は
ファイル名+ファイル内容のハッシュ(SHA-1, MD5も)+キーワード+現在の仕様のハッシュ値+ファイルサイズ・カウント数・日付などの付加情報
を流せばよい。

どんなもんでしょうか?

>>366
二重ハッシュか。トロンの実身/仮身みたいな感じにすればいいかな。

> BTRON の基本は仮身実身モデルである. かんたんに言うと OS でハイパーリンクがサポートされている.
> 一般の OS でいうとハードリンクがいちばんイメージが近い. ファイルシステムがハイパーリンクになっている
> と言えばいいだろうか.
>
> 実身は一般のファイルのようなシーケンシャルなデータ列ではなく, 複数のレコードを持ち, それぞれ別の
> データからなる. 付箋でアプリケーションとバインドされている. 仮身は実身を指すエイリアスである.
> 仮身を扱うときは必ず仮身を通じて実身が操作される. 仮身そのものが操作の対象になることはない.
> また, リンクの管理が OS で行われており実身のない仮身は存在しない. 実身名が重複していても区別して扱われる.
> 開いた仮身は埋め込みオブジェクトとして利用できる. これは OLE や OpenDoc と似ている.
ttp://jla.linux.or.jp/events/20000610-nagoya/nagoya4.html

ユーザーが触れられるのは名前を含めた仮身ハッシュのみにして、
実際の中身を持ってくるときはPDが管理するようにする。

偽造ファイル名・キーワードがあった場合、
その仮身ハッシュにはbadがつき、%が閾値を超えた時点で自動無視・削除されるシステムとかどうだ？
同じ中身でgood評価の仮身ハッシュがあった場合はそちらが優先して拡散されるとか。

これなら>>361の評価衝突問題もなくなる。消えるのは偽造仮身ハッシュだけだからね。