MXの次は何なんだ Part 64

クラスタで捏造fileとかあったら無視リストにやりますよね？
そのときに、クラスターワードごとに分ける機能が欲しいです。
あと、簡易メモとか。。
ダウソ→削除→無視で毎回やってるけど、捏造ファイルどんどん回ってくるから。。。

クラスタで設定してDLしたのをフォルダーに分ける機能がﾎｽｲです

>>79
漏れも早くやりてー

>>82
Winnyを複数インストールして、目的のクラスタにあわせて起動すれば?
今日はツール用、今日はゲーム用、ってさ。
そうすれば、毎回クラスタ移動する手間も省けると思うんだけど。

もちろん、UPフォルダやキャッシュも、目的クラスタごとに切り替えてさ。

捏造対策は文章による評価以外難しくないか？
リネームによる冤罪（？）なマイナス評価もありえるし。

捏造ファイルは確認ヤシが登録して自分のキャッシュから消すとともにキー情報を流さないようにすることで少しずつ減っていく。
現状はこの仕組みがある程度うまくいっている。
キャッシュの検索を不可能にしたとしても捏造ファイルの登録はできるようにしておく必要がある。
そのときにキャッシュを消すために本物のファイルを捏造ファイルとして大量に登録するヤシが出ないように、仕組みを良く練っておかなくてはならない。

あと、本スレそろそろWinny内のBBSに移動したら？
もう2chつかう必然性もあまりないような‥
まあ、47氏しだいだけど。

WinnyBBS内に入っちゃったら、ISDN撲滅されるわな。(苦笑)

>>86
リネームされたのを確認するのは無理っぽいけど？
例えば昨日落としたガンダム15話がいつのまにか16話に改名されて
流されたりするわけだし
それをキー情報探されなくなるとまずい

リネーム対策は前スレで出てたキャッシュのファイル名部分のロックと評価システム
組み合わせてシステム側で対策して欲しい

WinnyはVNC使ってみてるからWinnyBBS閲覧が辛い罠。

>>88
みんなが正しい名前で共有すればそっちが優先される確率のほうが高い。
下手にリコメンドシステム入れるより、正しいファイルを共有し、
捏造をキャッシュから消す(or削除登録)という通常のプロセスで自動的
にリコメンドが成されるという今の仕組は良くできている。

複数名検索できるのは便利かなとも思うけれど、それだとキーを保持す
べき空間が増えて速度低下につながる。で、代案。

今ボランティアでやられている、捏造情報ハッシュ名.txt みたいな共有を
あるハッシュを検索した時に同時に表示する。現状だとキーワードでしか
マッチしないから。A というキーワードで検索→A の持つハッシュ %A に
マッチしたファイル名を持つものも表示、という感じでどう？

>>89
BBSポート開ければBBS見るのにVNC使わなくていいんだがな。

ターミナル型winnyきぼん
うにくすだとncurses使って簡単に作れそうだが、
WinのAPIにもそういうのあるの?

>>90
ボランティアの捏造情報.txtは、通常ファイル名に
捏造ファイル名と捏造ハッシュが書かれているから
Aというキーワードで検索したら普通表示されるのでは？

>>91
わざわざVNC越しでBBS観ることもなかったな…。

>>94
47氏がなんのためにわざわざBBSポート開けるようにしたのかと・・・(ry

>>30
それは俺も考えたが偽の模造情報流されると痛い。
やはりWinnyそのものに何か仕込んだほうが良くないか？
例えば「本物登録」という感じで本物である情報を周囲に流し、
その数が多いほど信憑性が高い、という事でファイル名の色が変わる、とか。

偽物なんかいくらでも作れるから本物の情報を流す事を考えた方が良いと思う。

すまん、>>90だった。
ゆるしてくれ>>30よ。

30 名前：ナナシサソ[sage] 投稿日：03/01/11 20:53 ID:dsbktw82
うつかれ

最近のｎｙch贔屓野郎は何考えてんだ

『ファイルサイズで検索』が欲しい。
捏造されてても元ファイルがあった場合、一緒に表示されるから見抜きやすい。
1バイトでも削られたらそこで終わりだが・・・

>>100
元ファイルの内容が同じなら表示されない。

同ファイル、同サイズでも違うハッシュになっている物が存在するのは
どうにかならないの？
元は同じ物だったんでしょ？

同じファイルだったら同ハッシュになると思うが。破損してるんじゃない？

>96
うつかれ

さておき。
リネーム（？）対策にややこしくて、且つ効果が曖昧なシステムを組むくらいなら散々既出の

ハッシュ生成にデータ＋トリップ（※）を含める。

※ファイル名を含んでもいいけど、トリップでも同じ事（基本的に他人が付け直し不可）だからここではトリップとした。
トリップであれば付加の有無をユーザーが選択できる点で優れている→従来通りのリネーム許可、トリップ付きはリネーム不可をupするユーザーが選択できるから。

で対応しちまうほうがいいと思うよ。
簡単で確実。

んで、トリップを付加しなければ（トリップ情報がNULLだから）従来通りデータ部だけがハッシュ生成に用いられる。

トリップが付いていないファイルのリネームは自由。
トリップを付ければリネームによるファイルの同一性が失われる。

こんなんでいいんじゃないだろか。
実装するかしないかは47氏次第だけど複雑な仕組みは要らんと思う。

トリップつけたらハッシュ変るのかな？

>>105
貴殿はスーパー馬鹿ですね

>>106
釣りはほっとけ

異常終了しました。

そうか、確かにトリップや有無で違っていた…
同じ物なのに違う物と扱われるのがもったいないと思った。

（´-`）.｡oO(ＤＬが開始されてもすぐにプチプチ切断される香具師)
（´-`）.｡oO(いったんキャッシュを全部退避して再起動してからやってみれ)

リネーム＋トリップ消しと編集捏造、ウィルス入りなどは別々に考えた方がいいよね？
後者は対策が難しいから、とりあえずリネーム関係を考えてみるとして、
ttp://members.tripod.co.jp/roikix/winny/hqa12.html
のハイパーQ&Aの改善案を参考にすると、
まずその2を実現するには、WinnyにNTPクライアントの機能を持たせて、
キー生成時に時刻情報を取得させる必要がある。
NTPサーバーの負荷とか、LAN内でNTPを動かして誤魔化される可能性あり？
次にその1とその4はほとんど同じ気がする。
ハッシュをトリップハッシュ＋ファイルハッシュで構成して、
キーを捜すときはトリップ付きであげられたものを探し、
DLするときはファイルハッシュが同じものをDLするようにするということかな？
どちらにせよキー情報が増大するのは避けられない。
その3はページ上に書いてあるとおり、やや効果が薄いかも。

という風に理解してるんですが、間違ってたら指摘してください。

>>104
うｐってくれる神がおまえの言うトリップ使わん場合が多いだろうが・・
神＝職人ならそーゆーやり方をすすんでするかもれんが
MXだのなんだので貰ってきたファイルを流す事の方が多いだろう
しかも最初からキャッシュを生成するといくらでも誤魔化せるというおまけつきだ

>>96の方法だと情報流すだけなのでPCにかかる負担も少ない上に
項目の色を見るだけなのでわかりやすく、数の暴力を使うので偽証も難しい。
もちろん同一ハッシュの多重登録は不可、という前提つきだが

NTPサーバーなんか見に行かなくてもローカル同士でPCの時刻交換
すればいいと思いますが
普通は10秒くらいの誤差でだいたいあってると思うけど
20-30台分の近接ノードの時刻取得して大幅にずれてるのは切り捨ててから
中間値でも標準偏差でも計算すればいい
で、時々修正する

>113
PCが一台しかない漏れは？

>>113
前スレの407から読み直してみれば？
それでもなお同じ意見を繰り返すのなら貴様はｱﾌｫ決定。

>>114
ローカルってそういう意味じゃないんじゃない？

過去何回も話された話題だな。どーでもいいけど。

>>96,112
この方法いいね。
あとはNYにどのような形で実装するか検討したらいいと思う。

winnyで宇宙へ！！

今、Winny時間だと、何時？

>>104
さんざん既出だと思うが。
トリップをハッシュに含めてしまうと、そのハッシュは作成者である職人本人以外は作れなくなる。
UPフォルダから再アップしたものと、ＵＰフォルダから他人がトリップをつけて再アップしたもの、
オリジナルのキャッシュの三種類が、同一ファイルにもかかわらず異なるハッシュとして出回る。
とくに他人が別のトリップを付けて再アップした場合、その種類は無限に増える。
これはネットワークレベルの冗長度を著しく上げ、長期的に同一ファイルが別のハッシュとして膨大な数出回るという自体を引き起こす。
これは結局、無駄なキートラフィックの増加とキャッシュの分散を引き起こし、目的のファイルが落としにくくなるだけである。

>>112
「同一ハッシュの多重登録不可」はどうやって実現するのか。
登録済みのハッシュを記録して・・・と考えているのなら、それはどこに記録するのか。
ローカルに記録する限り、それを消すことは簡単にできる。
またクラックして登録数を操作するなんてことも簡単にできる。

ちょっと論理的に考えれば矛盾だらけなのは明らか。

>96
リネームについては、正当と捏造のファイル名がノード毎に点在するので、
そのハッシュを捏造として全否定されないようにしないとマズいよ。

winnyに跨って宇宙に行くのに必要な機能ってなんだろ？

>112
>うｐってくれる神がおまえの言うトリップ使わん場合が多いだろうが・・

どうせ対策するなら簡単で効果が確実な方が良いでしょ？
それを使う、使わないはユーザー次第。使わない場合が多くても別にいいんじゃねーかなと思う次第。
神とか職人心理とかよくわからんけどさ。

>しかも最初からキャッシュを生成するといくらでも誤魔化せるというおまけつきだ
これって何を言ってるのかわからんのだけど。
説明きぼん。

「検索の拡張」だけで済むから比較的容易かと思ってるのだけど >>90 での案
本体の機能拡張は最低限の方向で。気をつけないと偽造情報の本物情報の偽造
情報とかわけのわからん状況に陥るおそれが。あくまで本体は中立で。

>>93
ファイル名の偽装に対して無力。
>ファイル名込みでハッシュ化派
漏れは結構ファイル名変えて共有するので、せっかくファイルの同一性を保証
するハッシュの意味がなくなるのは嫌。
>>96
偽物の本物情報が流れることを考えると…。しかも本物情報はデータ量大。
偽物情報のほうが少い筈だし、少くとも dicny の代替にはなるかなと。
>>タイムスタンプ派
あんま検証してないけど、ちょっと知識があれば簡単に偽造できる気がする。
下手に ntp サーバに依存すると P2P の利点が失われるし。

>>122
最低、大気圏脱出機能と生命維持機能は必須ですね。
あとはNYにどのような形で実装するか検討したらいいと思う。

>>120
おまえなんかうさんくさくないか？
＞またクラックして登録数を操作するなんてことも簡単にできる
とか言ってる辺り特に。
そのうえ否定するだけで代案なしか？矛盾だらけはおまえの方だ。
なんだか模造対策されると困るような口ﾌﾞﾘだな？
違うってんなら>>96や104よりマシな代案いってみろよ

代案無しの否定は別に悪いことだとは思わん

トリップはあくまで1次配布者を特定するためのものだから、
同一性証明には向かんでしょ。
全員が(1次配布者から受けた)キャッシュのままで流通させれば問題
ないけれど、変換してから UP フォルダに上げると失われる。

あまりここを強化すると、匿名性に問題を生じそうなのは杞憂かな？

間違ってたら突っ込み希望。

役には立たんな。
＞代案無しの否定

トリップについてはハイ初提案の
http://members.tripod.co.jp/roikix/winny/hqa12.html
第四案が実装されれば解消するけど、実現は期待できなさそう･･･
トリップが機能すれば捏造は相当防げると思うが・・・？

>>123
元になるファイルから適当に偽装してトリップつけてハッシュを作ると簡単に・・
・・と思ったのだが俺が思い違いしてるのか？
それにトリップ検索なんて使ったことねぇしロクに見てないぞ、俺は。
俺と同じようにトリップ軽視してる香具師は多いんじゃなぇんのか？

>>124
>偽物の本物情報が流れることを考えると…。しかも本物情報はデータ量大。
なんでだよ？
周囲の香具師が気まぐれ程度に登録するだけだろう？
周りに居る連中が全員そろって偽の本物情報流すなんて考えられんが。
>>96のやり方は周囲に教えてもらうことを基本としてるんだろう？
なら、偽の本物情報を喜んで流す香具師は少ないと思うが。

で前スレでコピペされてた俺の主張なのだが、少し改良

1.クライアント各自が任意に設定する文字列から47bitのユニークなIDを生成する

32bitでは総当り式でトリップが突き止められる可能性がある、1bitは良い、悪いのフラグに使用。

2.すべてのIDは信頼度というパラメータを持つ、初期値はゼロである。
3.ファイルをダウンロードしたら、任意に良いか、悪いかの評価をキーに与え、自分のIDをキーにバインドする。
4.もし自分が良いと評価したキーに別の悪いと評価したIDが存在したら、そのIDの信頼度は二分の一にされる。
5.もし自分が良いと評価したキーに別の良いと評価したIDが存在したら、そのIDの信頼度はインクリメントされる。

6.キーにバインドされているIDの信頼度の統計を取る。
良いと評価しているＩＤの信頼度の合計、悪いと評価している信頼度の合計の比率が信頼性、IDの信頼度の合計をポイントとする。
例えば良いと評価しているIDの信頼度の合計が80、悪いと評価しているIDの信頼度の合計が20なら、信頼性80% 100Point。

7.一定数以上(4~8個ぐらい)のIDを持つキーは信頼度の低いIDから破棄されていく。
同一ファイル名で同一ハッシュのキーが衝突した時は、信頼度の高いIDが優先的にマージされ残される。
異なるファイル名で同一ハッシュのキーが衝突した時は、信頼性とポイントが高いキーが優先される。

8.キーには最初にアップロードした人のIDが先頭に付く。
トリップをONにしている場合は、そのIDはIDリストの先頭にロックされ、IDから文字列が作成され表示される。
トリップをOFFにしている場合は、IDは通常のIDと同一に扱われ場合によっては破棄される。