次期P2Pの仕様 part7

#次世代P2Pの仕様を話し合うスレです。

このスレのまとめサイト（Wikiへの直リンク禁止）
　http://s2net.s41.xrea.com/

過去ログ等を置いてある簡易まとめサイト
　http://2.csx.jp/~p2p/

前スレ　Part6
　http://tmp2.2ch.net/test/read.cgi/download/1070189802/

関連
次期P2Pのクリアすべき課題を法的な観点から考察（Part2）
　http://tmp2.2ch.net/test/read.cgi/download/1070500722/
次期P2Pに対する要望スレ
　http://tmp2.2ch.net/test/read.cgi/download/1070085137/
P2P総合
　http://pc2.2ch.net/test/read.cgi/tech/1048668198/
次世代P2Pの名前を考えるスレ
　http://tmp2.2ch.net/test/read.cgi/download/1069996070/

850レスを超えたら、次スレの準備をする為に、議論を一時中断して下さい。
あと、スレ住人はキシュツに敏感なので必ずテンプレ、過去ログ嫁
荒らし、煽り、過去ログ等読まない奴は放置。
またーり下げ進行でお願いします。

テンプレは
>>2-20
#---------------------------------------------------------#　

2?

2か3

　　　　　　　　　　　　　＿＿＿＿＿＿＿＿＿
　　　　　　　　　　 ／
　 　　　　　　　　　|　うっほほーい、みんなお帰りー
　　　　　　　　　　 ＼＿＿＿　＿＿＿＿＿
　 　　　　　　　　　　 ＿＿＿V
　 　　　　　　　　　／　´∀｀;＼　＿_曰
　　　　　　　　　　/　　　　 /::::::::::::::つ
　　　　　　　　　　|　/　 ／::::| ￣￣
　　　　　　　　　　|　| ／:::::::::| 　＿　　
　 　 　 　 ノ ＼￣ ￣￣￣￣＿＿＼　　
　　　　 .<＼※ ＼＿＿____|i＼＿＿＿
　 　 　 　 ヽ＼ ※　※　※|i　i|.====B|iヽ
　　　　　　　 ＼`ー──-.|＼.|___|__◎_|i‐>
　　　　　　　　　￣￣￣￣|　.|￣￣￣￣|

1, こ こ は "仕 様" を 決 め る ス レ ッ ド で す。
→ 実装 法律 に関しては、他のスレッドでお願いします。

2, 単発のアイデアは良く考えてから、カキコしてください。
十中八九、ｶﾞｲｼｭﾂとかスレ違いとかﾋﾟﾝﾄはずれと言われちゃいます。」

UDP/コネクションレス/IP偽装/コネクションハイジャック…は、既出。

3, Mac版は？　Unix / Linux / BSD 版は？
→ 次期Winnyでは一般的なプラットフォームをターゲットにしていますので
→ Unix板 Linux板 Mac板の方もアイディア・技術提供、宜しくお願い致します。

しかし、要望スレに自己主張してくれないと反映されないかも知れません。
※【神】UNIXにWinnyを移植【降臨】 　http://pc.2ch.net/test/read.cgi/unix/1065863581/
※Linny開発プロジェクト Part2 　http://pc.2ch.net/test/read.cgi/linux/1056278411/

4, 「現時点で組み始めたいんだけど」
→ まだ仕様が決まっていないので、余り先走らないで下さい。
→ しかし検証コード・テストコードを書くのは推奨しています。

5, 今回のﾀｲｰﾎは別件逮捕だと聞いたけど？
→ ガセ。Winnyが解析された可能性がある。

6, IPの偽装はできないのか？
→ 現実的ではない。

7, ソフト名を決めずに、検索エンジン等でかからなくするのが良い・ソフト名を放送禁止用語にすれ
→ モノができてから考えれ。

8, 特定のIP（ACCSとかJASRACとか）は、拒否する設定が良い
→ 一般のプロバイダが用いられた捜査に対して全く無意味。

9, 作者の身元を隠さなくていいのか？
→ 後で（公開の段階で）考えるべし。現状何もできてないので問題ない。
※今回の件から推測すると、実装し頒布した場合の作者さんは、
家 宅 捜 索 等 の 危 険 も 大 き い の で 決 し て 身 元 を 明 か さ ぬ 様 に、
書き込み・垢の取得に"充分"気を付けて下さい。

早い話、2chで「作るyo!」・「ﾃﾞｷﾀｰ!!」と言ったら、
「将来、逮捕・家宅捜索される危険がありますよ」って事。

10, K察・ACCSは使用禁止にしよう
.　 　・雑誌掲載を禁止しよう
.　 　・初心者には容易に使えないソフトが良い、
.　 　・初期設定を難しくしよう、等
→ 後で（公開の段階で）考えるべし。公開直前にでも何とかなる。
→ また現実問題、スレのＵＲＬの転載を止める手段はない。

11, 通信径路上でのデータの暗号化にはＸＸが良い
.　 　・「鍵は〜〜で流すのが良い」等 暗号関連
→ 暗号化はあくまでもプロバイダに特定されないためのもので、問題の本質ではない。
→ 例えば相手ノードが警察のＰＣだった場合などは、あらゆる暗号化は無意味。
→ どちらかというと、責任逃れの方法を考えなければならない

12, 「**機能付きにしる！」・「インターフェイスは**！」
→ それ専用のスレッドが御座いますので、そちらに書き込んで頂くか
→ プログラム組む時(実装時・設計時)に、再度お願いします。 項目14も参考に読む事。
※次期P2Pに対する要望スレ　http://tmp2.2ch.net/test/read.cgi/download/1070085137/

13, これ作っても違法なんじゃないの？
→ 法的な問題については専用のスレッドが御座いますので、そちらにお願いいたします。
→ そちらでは現在、法律に詳しい方を探しています。
※次期P2Pのクリアすべき課題を法的な観点から考察
　　http://tmp2.2ch.net/test/read.cgi/download/1070084504/

14, 基本部分をプラグイン・ライブラリの形で提供してはどうか

　良いアイデアだが、それは実装段階の話に近いので、要望スレで。

15, オープンソースにする利点、またはリスクは？

　リスク：オープンソースにすると言う事は、Ｋ察にもソースを公開するということ。
　Ｋ察のおとり捜査が容易になるので、
　かなり厳密な設計が必要になってくる。

　利点：ググったら腐るほど出てくるので、そちらで勉強して下さい。

.　　※暗号化・複合化部は、一番肝になる部分ですので
.　 　　ライブラリとして,バイナリでの提供を考えています。

白血病／企業宣伝／指名手配犯／尋ね人

この辺を組み込む案。

いままでの悪いイメージを変える働きと、
いままで、P2Pに敵意のある団体にこびをうる目的。

はじめてのスレたて
これでよかったかな？
修正・補完よろしくお願いします

ノードクラスタ生成の仕様＆アルゴリズムってどうすんだ？
一番の要だろ？暗号はどうせ既存のアルゴリズムつかうんだし

あ、テンプレの13のURL違ってた
※次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070500722/

ループしないためにも前提条件を決めたほうがいいんじゃない？

・キャッシュの一部をUPしても合法と仮定する。
・中継・転送も合法と仮定する。

これを前提に話を進めなきゃいつまでたっても進まない。

ttp://tmp2.2ch.net/test/read.cgi/download/1070189802/976

調査側が複数のPCを使用して接続IPを制限してやれば、強制的に転送経路をつくることができる可能性が高い。
この状態で末端からリクエストを発行し、もう片方の末端でログを取る。
何度も繰り返せば、通信内容を解読しなくてもトラフィックから統計的にIPを絞り込める。

これを回避するには、1転送ごとに経路を変えるなどの仕組みが必要かもしれないけれど
同じく工夫すれば、経路が変わるように調査側もネットワークを組むことができる。その方法は使えない。

さらに極論を言えば、すべてのネットワーク経路を監視する仕組みがあったとしたら
データの流れから、送信元のIPの特定することもっと簡単であろう。

これらの問題を回避するには・・・ どうしたらいいんだ。と作りながら思うのでした。
密かにスクリーンショット公開中。

どこに公開？

>>13
レス先、間違えてない？ 前擦れ>977と。

47 名前： まさと 投稿日： 2003/11/30(日) 18:20

>>40 切込隊長殿
Winnyに関してコメントや裏情報はありませんか？

50 名前： 切込隊長★ 投稿日： 2003/12/03(水) 17:42

>>47

　半年以上前からwinny制作者グループは特定できていたそうだが、
それ以上のことは知らない。

51 名前： Od 投稿日： 2003/12/04(木) 00:58

winnyは個人で製作したP2Pソフトということでは
無かったかということか。
何らかの意図が介在していたのかなあ。

http://jbbs.shitaraba.com/music/570/

公開方法とファイル命はとっくの昔に告知したぞ。
たぶんまともな開発画面は俺のが最初だろう。

http://s2net.s41.xrea.com/
の管理人です。テンプレですがHTML形式で公開しているのをやめてWikiにあるものにしようと思っています。
適宜修正をしていくつもりですし、皆さんからもよろしくお願いします。

>>17
名無しじゃ誰だかわからんよ。
前スレの何番の人？

>>19
640じゃないの？

クラスタはなに？
[P2P]で検索してるけど全然引っかからんよ。
P2Pをキーワードに登録したら合法クラスタに囲まれてしまった。。

クラスタとファイル名希望
漏れも合法クラスタに囲まれた

また釣りだったのか・・・。＿|￣|○

あまり、詳しいことは書きたくないんだけどね。
2ノードでの接続の自動構築はなんとかできた。
目標として、今月中にリリース。

ちょっとこの文章じゃあ釣れないだろうねぇ・・・

前スレの671が言っていたようなP2P掲示板を作りたくなったのだが、
需要ってあるか？
・BBSキャッシュは分散。中央は存在しない
・いつでも発言できる
・発言がそのスレを回覧している人すべてに届くとは限らない
　（いずれかは届く可能性が高いけど）
発言者の匿名性はかなり高いけど、インスタント性は低いかも・・・

> 　（いずれかは届く可能性が高いけど）
> 発言者の匿名性はかなり高いけど、インスタント性は低いかも・・・

それは、匿名性を下げても問題ないと思うけどな。


匿名掲示板、使いたい。

>>26
レスポンス良好
初期の2ch程度の匿名性
2MまでのUPろだ搭載

でよろ

>>26
frostみたいだな。

>>29
みたいというより、そのまんまのような･･･

ネットワークが狭い分レスポンスは良くなるかな

匿名性下げる＝中央に保持
しか思いつかなかったし、これじゃWinnyと同じだし、
前スレの671の言っていた案は昔から思っていたことなので、
これを機会に作ろうかなと思ったわけ。

>>27 >>28
匿名下げてインスタント性をあげたやつは、IMっぽく作ろうかなと考え中。
参加数が増えればWinnyよりは匿名性は高くなるシステムで、
クローズなグループも作れるようにする。

>>29
frostは家のマシンでは上手く動かなかった・・・

ちょっとＨＰ更新。メッセンジャー方式でログをローカルにためた方が効率的かな？
ttp://fosae2003.tripod.com/

Invisible IRC Project
http://www.invisiblenet.net/iip/

the zigumo project
http://www.zigumo.org/

Vojta
http://vojtaproject.kicks-ass.org/

Tiara
消えた．．．

http://s2net.s41.xrea.com/
P2P関連技術情報をすこし手直ししました。

匿名掲示板、
＞・BBSキャッシュは分散。中央は存在しない
＞・いつでも発言できる
この部分をちゃんと実現したら需要はあると思う。
つーかこれがなかったらnyと同じだな。

P2P匿名掲示板「新月」、完成してる模様
実験的にファイルアップロード機能をつけてます
オープンソースなんで検証してみるといいかも

http://fuktommy.hp.infoseek.co.jp/perl.html#shingetsu
wiki
http://fuktommy.hp.infoseek.co.jp/cgi-bin/wiki.cgi?%BF%B7%B7%EE

スレ立てるか？＞新月

関連スレとして立てて検証するのもいいかも

>>31
同期の問題はクラスタ化をうまく使えばなんとかなるかも
カテゴリ別でクラスタ化して、NNTPサーバとして動くノードを500位に抑えれば・・・
問題は鯖になった香具師の負担がでか過ぎる事かなぁ

参照量増えねえ。ヴァカしかいないのかここは?

■P2P匿名掲示板「新月」■
http://tmp2.2ch.net/test/read.cgi/download/1070720320/

ペテン師、新月の夜に死す！

クロスケーブルでP2Pこれ最強

>>39
クラスタは？ ハッシュは？
[P2P]で検索したけど、全然引っかかりませんよ。

結局新月も寝たか

( ﾟдﾟ)

Wikiの「無作為XOR方式」、大事な問題点が抜けてると思う。ぱっと思いついたのは次の2つ。
・同じファイルを複数の人がアップロードしても、ほぼ確実に互いに異なるxorデータになるため、
レジューム、あるいは多重ダウンロードできる確率が低くなる。
・不人気ファイルを無作為データとした場合、せっかくアップロードしたキャッシュが消滅する可能性が高い。

1番目は対策ないと思う。仕様だから。
2番目は、無作為データに被参照量の多いファイルを使うと改善されると思うが、
「被参照量が多い=古い」なので、問題点X1により、xorデータを推測されやすくなる。

無作為XOR方式は情報処理技術者試験の午前問題に出題されますか？

ハンドシェイクまで完成。
データは分散させるが、スレ主による管理って必要かな？
必要ならそれなりの考えが思い浮かんだんだが。

>26
個人的には管理はいらないかな。

>>48
有れば使うかもしれないが
無くても気にならない
荒しは2chブラウザのように
ブラウザ部分であぼんできれば十分

>>26
プラスαもホシイ・・・使う機会が増えそう。例えば↓
ttp://www.watch.impress.co.jp/internet/www/article/2002/0624/spamnet.htm
気が早かったかな

47氏ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!

辛い記憶の乗り越え方
http://news4.2ch.net/test/read.cgi/news/1070729855/

>>51
あまりP2Pのインフラに機能を盛り込むと効率低下、不安定要因になりかねないと思う。
高度なフィルタを入れるなら、ベイズ式フィルタにした方がいいだろうね。
どの書き込みが糞かは人によって基準が違うわけだし。

>>26
wikiのほう一通り読ませていただきました。
一つ気になるのがスレッドキーですが、
これはレス数が増えるとだんだん重くなるという構造と考えてよいのかな。
まあ、8Byteのハッシュとして100レスで800Byteですから許容範囲といえばそうですが。

で、前スレ671では自分自身以外のハッシュを持たないでファイルを流通させる方法を
考えたのですが意図は伝わったでしょうか？
レスポンシビティは更に低くなる可能性はありますが、トラフィックは軽くなるはずで。

その辺りの実証実験を一応自分でも予定してます。
とはいえネットワークアプリケーションの製作経験のないド素人なので、
どれくらいで完成するかは保証の限りではないのですが。

>これはレス数が増えるとだんだん重くなるという構造と考えてよいのかな。
スレッドキーは160bit固定です。SHA1というやつ。

>ネットワークアプリケーションの製作経験のないド素人なので、
私も、ソケット＆非同期は初めてｗ

>http://s2net.s41.xrea.com/の管理人さんへ
リンクは問題ないです。独自というか一応この板に準じてます。
ファイル共有機能は仕様が固まり次第実装する予定・・・

>>46
> ・同じファイルを複数の人がアップロードしても、ほぼ確実に互いに異なるxorデータになるため、
> レジューム、あるいは多重ダウンロードできる確率が低くなる。
> ・不人気ファイルを無作為データとした場合、せっかくアップロードしたキャッシュが消滅する可能性が高い。

それはたぶんどっちも解決できると思う。それより、Wiki の説明文にある


> 　もし将来、元ファイルの一部分をアップロードしただけで責任を問われるような
> 状況になったとしても、ある程度の安全性が維持できます。

ってのはどの程度信頼していい話なんだ？？　これは >>12 の仮定が成り立たなかった
としても大丈夫、という意味に読めるんだが・・・

>>56
無作為データはポエムの可能性もあるわけで（そんな長いポエムあるのかどうか知らんが）、
組み合わせる2つのキャッシュのうちの1つをアップロードしたからと言って、捕まえようが
ないって事だから、「ある程度の安全性は維持できる」ってのはまあいいんじゃない?

それより、>>46の解決法を教えていただきたい。

>>26
ホームページのトップにある
＞Part5の512から出てきて
は、514のことでは?　あと、リンクのtargetが…

いくら完全キャッシュを保有してなかろうが、やっていること自体は犯罪。
新P2Pソフトの利用してれば、Kがその気になればﾀｲｰﾎ可能だと思う。

その意味で重要なのは匿名性の向上のみだと思うが。
MXからnyへの変化みたいに交換から共有へのパラダイムシフトに関するアイデアは出ないようだし。

ということで、freenet最強ということになるが、あれは使いづらいんで、あの論文を読んで
windows nativeでfreenetとは別ネットワークな実装をすればいいだけじゃない？
freenetを使うと外人さんにも迷惑かかるし。

>>59
一応
ファイル交換→ｍｘ
ファイル共有→ｎｙ
ディスク共有→次世代P2P

となっているようです。

>>57
> 「ある程度の安全性は維持できる」ってのはまあいいんじゃない?

なんか問題点も多いみたいだけど、じゃあ検討の価値はあるのかな。


> それより、>>46の解決法を教えていただきたい。

> ・同じファイルを複数の人がアップロードしても、ほぼ確実に互いに異なるxorデータになるため、
> レジューム、あるいは多重ダウンロードできる確率が低くなる。

　ファイルキーにオリジナルファイルの全体ハッシュを入れればいいんでないかと。
　別々にアップされたものでも、全体ハッシュが一致すれば同一のファイルを
指していることがわかるから、ブロックごとに入手性のいい方をダウンすればいい。

　ただし、ブロック内では別ソースからの多重ダウンやレジュームはできないという
問題は残る。これは、原文にあるような 2^n サイズに規格化するんではなくて、
64kBくらいの小さなブロックサイズに固定してしまえば多重ダウンもほとんど制限が
なくなるはず。


> ・不人気ファイルを無作為データとした場合、せっかくアップロードしたキャッシュが消滅する可能性が高い。

　データの流通の方は変形RAID5方式とか別の方式を使うというようなことが書いてあった。
もし変形RAID5方式を使うとすれば、冗長化管理機構があるようなのでそれに任せれば
よいかと。

　書いてて別な問題に気づいた。
　ブロックごとに２つのデータをダウンロードすることになるけれど、キャッシュが
拡散していないうちは、データペアのうち一方は放流元からダウンロードすることに
なる。ブロックが複数あれば放流元が簡単にわかってしまう・・・。
　これを解決するには、変形RAID5のキャッシュ強制拡散のような仕組みが必要かも。

　やはり、この方式は主役にはなり得ないような気がする。

　まず他の方式で放流元がばれないようなデータ流通システムを作る。
　しかし中継者の責任問題は残るので、それを無作為XOR方式で軽減する、というのは
どうだろう。

　匿名性をもう一段上のレベルに持っていくために使うには有効かも。

>60

レス、ありがとう。

>ディスク共有→次世代P2P

はOFF交換どうのこうのっていうネタだと思ってたw

>>63
ディスクはディスクでもハードディスクねｗ

>>55
あ、なるほど。スレッド全体を１ファイルとしたハッシュ値を毎回取得する訳ですな。
そうゆう解法もあるか。φ（．．）ﾒﾓﾒﾓ

ところで、質問と言うか確認なんだけど、
キー寿命のルールは以下のような形で問題ないだろうか？

１．キー発行ピアが8bitの乱数Aを引き、キーに付けて送る。
２．キー受信ピアも8bitの乱数Bを引き、A・Bの上位6bitが一致した場合キーの転送を行わない。

上の例だと平均64ステップでキー消滅。ステップ数が多すぎるのであれば
4bit比較にすれば平均16ステップ。逆に8bit一致なら256ステップという具合で。

ポイントとしては、あくまで確率によるので、実は1000ステップかもしれないし、
1ステップかもしれないという。
ファイル共有の場合は1ステップだといろいろマズそうなので、工夫がいるやもしれんけど。

新しいP2Pソフトとして、
ここで議論されているように、匿名性を飛躍的に上昇させる。
具体的には
・DES暗号など強固ものを使う
・データ送信は常に三者以上の中継を必要とする
・特定のIPアドレスとの通信を許可しない設定にできる
そして、
・BBS機能の強化
・チャット機能を追加
など、完全にコミュニケーションを目的としたソフトにする。
そうすれば、作者に危険は及ばない。
また、外観もWinnyやWinMXの様に何か凶悪なイメージを持たせるものではなく、
ファイル共有を目的としないユーザーも手軽に参加できるようにする。
MSN Explorerなどのが適切かもしれない。
また、法人格を持つ者に対してはシェアウェアとし、
作者に1000万円とユニセフに対して2億円の寄付を条件とする。
これにより、権力から遠ざけて、より庶民的なものにする。

と勝手に妄想してみたが、どうだろうか？

http://pc2.2ch.net/test/read.cgi/hp/1070772977/
こっちでもP2P関連の話やってるので、一度きてくださいな

>>67
面白そうですね
そっちでやりますか

>>前スレ671
そのようなやり方なら、単純にキーの転送を行うか行わないか
ランダムで決めた方が良いと思う。99%の確率で転送するとか・・・
私は発行ピアが数値をランダムで設定し(大きい数)
中継ピアはその数値をランダムにひく（０を含む小さい数）
その数値が０以下になったら、キーの転送は終了。

>>66
＞また、法人格を持つ者に対してはシェアウェアとし、
＞作者に1000万円とユニセフに対して2億円の寄付を条件とする。
＞これにより、権力から遠ざけて、より庶民的なものにする。
('A`)

>>66
既出＆スレ違い

>また、外観もWinnyやWinMXの様に何か凶悪なイメージを持たせるものではなく、

凶悪、・・・なのか？

BBSもだけど、InstantMessageやChatは是非欲しいね。
そこについては、高度な暗号化や匿名性は要らないから。

MessengerもMSN・Yahoo…複数種あるからね。

MSNがchatを有料化した反応を見れば、Chatへの需要が多い事が解る。
また、Chat目的・掲示板目的・IM目的のユーザーを中継点として利用する事で、
匿名性の保持にもなりえるだろう。

>>73
妄想はいいから仕様だしてくれないかな？
今までの話し合いで掲示板・Chatをしようすると匿名性が下がるってのは散々既出。
匿名性の保持になるというなら仕様を明らかにしてからにしてくれ

共有するの画像だけにすればいいんでない？
画像だけなら捕まる危険性もすくなくなると思うんですよ。

Freenetに興味があるなら。↓

Freenet & Frost スタートアップ
http://yellow.ribbon.to/~xanacopy/fff01.html
初心者向け。導入の手引き。

freenet + frost
http://tmp2.2ch.net/test/read.cgi/download/1069942913/l50
2ちゃんねる本ｽﾚ？

>>66
シングルのDESはもうダメポ
3DESぐらいじゃないと

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>61,62
一人で考えていても行き詰まる事が多いから、まじめに答えてくれる人がいるとうれしい。

問題点1については>>62に書かれているとおりだと思うし、あと、あまり分割しすぎると落とすの大変。
問題点2の解決法も、RAID案まかせではRAID案と同じ問題点（トラフィック増、捏造に弱い）を抱えることになる。

＞やはり、この方式は主役にはなり得ないような気がする。
同意。ただ、アイデアとしては面白いと思う。法的な解釈も難しいところだろうし。
PC性能とネット速度が向上すれば、将来は使えるかも。

というわけで無作為XOR方式の提案者さん、このスレ見てたら、>>46の2つの問題点をWikiに追加して欲しい。
あるいは解決法を提案してくれても可。


答えてくれる人がいるので調子に乗ってもう1つ。「信用情報方式」はどうだろ?
1つ問題点を上げるとすれば、小さなファイルを落としまくると、「この送信元を信用しますか？」ダイアログで
画面が埋まる。…いや、冗談ですが。ほかにも思いついたけど、自分の中で解決できた。というわけで、
誰かWikiに書かれていない問題点を思いつく人いませんか?

やっとバグ取れた・・・。まともなバージョンリリースはまだまだ時間かかりそうだ。

>>80
何時から作り初めてどの程度出来たか、今何を書いているか言ってみろ。

まずスクショは信じられん。

ソースの一部、差し支えない場所の提出ｷﾎﾞﾝ

>>73
匿名チャットならIIPがある。

47ソース提出から数日で開始。
ノード追加ダイアログボックスからノードを追加して、接続できたならばクラスタ情報などを元に
接続優先度を計算し、接続を完了する。タイムアウトや最大接続時間なども使用。
ブロッキングソケットを使用しつつも少ないスレッドで動作。(でも後から接続ごとのスレッドにするかも)
テスト用のデータは送受信可能なところまでできている。
暗号化部分は抽象クラスで定義。後から簡単に置き換えが可能。
キャッシュ管理部もテストはできるくらいにはできている。もちろんファイルからハッシュ生成も。
基本はny+機能upで行きます。詳細は明らかにしませんが、nyにない新しい匿名性も追加します。
てか、全部説明するのマンドクサイ。

現在、接続切れなどのエラー処理周りのテストを行っている。

アイコン募集中。文字などが入ってなくて256色以上推奨。イメージ的には"共有"を象徴しているもの希望。

そのうち、動くexe公開するからマッタリ待て。

>>84
本物だ。
マタ〜リとお待ちしております。

このスレでそんな稚拙なこと書いても釣れないと思いますよ
他に適切なスレがありますのでそちらでどうぞ

ＭＸの次のときも、こんな感じだったから

マターリ応援sage

一つ方式を思いついたので、提案してみる。
1.nyのような重いソフトではなく、中継機能しか持たない軽いP2Pソフトを作る。
2.その軽いP2Pソフトを、たくさんの人のマシンに常駐させる（責任分散）。
3.2を実現する方法として、ｳｲﾙｽとしてばらまくのが最強だが不可能なので、
　親や友達のPCに入れてもらう（義理人情式）、学校やネカフェのPCに入れる（秘密式）
　フリーソフトの使用条件にする（強制式）等の方式を用いる（超責任分散）。

なんかうそくせーな
スクリーンショットうぷしろや

>>84
どうでもいいがファイル共有は違法だぞ

ここでの流れは>>60みたいだし
それを理解せずに書き込んでる>>84は嘘くさい
過去ログもまとめサイトも見てないだろ

釣りなら他の場所でやった方がいいよ。

適当なスレがないので適当に報告しているだけです。
ここで議論されている仕様は、知識として見ているだけかな。
それより、実装の仕様について語ってくれるほうがプログラマ的にはイイ!
上辺だけの仕様を語っても結局コーディングするとなると、それをコーディングするための
情報を探したりするのが激しく面倒。まあプログラマの仕事の１つだけど、これが面倒かどうかが
作るか作らないかの分かれ道かも知れません。

こんばんわ、警察です。
進んでますか？

>>94
( ﾟーﾟ)……

>>93
ほんとに作ってるなら47氏の過去ログ読むのが一番参考になると思うけど。

>>89
ガイシュツなんだよボケ。

#include <stdio.h>
#include <stdlib.h>

int main
{
void q1()　面倒と思うかどうかがプログラマとしてのスキルが低いか高いかの分かれ道かもしれません。

void q2()　面倒と思うかどうかがただの厨房かそうでないかの分かれ道かも知れません。
}

マターリ応援sage

100get sage

>>100
IDも100おめ

マジでやってるのかー。だとしたら応援sage

あの・・・sageってスレが下がる訳じゃないんですが sage

マジでやっててもここに書くとこのスレが荒れるんでやめてね sage

>>94
はい、申し分なく進んでおります。
捜査の方大変だと思いますが別件逮捕でライトユーザーを脅すことぐらいはできると思うのでよろしくお願いします。

>>93
ココ書き込んでも平気なの？
ここのログから47氏踏み込まれたってあったような･･･

＞ここのログから47氏踏み込まれたってあったような･･･
デマゴギー(・A ・)ｲｸﾅｲ!

>>107
別に信じないならそれでもいいんじゃない？
京都スレの名無しは47氏。

ソースも出さずに偉そうだね

ひろゆきは不当な理由でログわたさんだろ・・・
別に犯罪犯してるわけじゃないんだから。

>>109
　　ま、俺はいつでもマジレス本気１００％ダンディーだからな。
　　　　　￣￣￣∨￣￣￣￣
　　　　　　　　　∧∧
　　　 　　　 ⊂(゜∀゜)つ-、
　　　　　 ／／/　　 /_/:::::/　　　
　　　　　 |:::|/⊂ヽノ|:::| ／」
　　　 ／￣￣旦￣￣￣／|
　　／＿＿＿＿＿＿／ | |
　　| |-----------| |

ttp://winny.info/2ch/

京都府警が47氏を家捜索、ホームページも閉鎖18〜20

ID:hjdNKVnb

義理人情式は新規性があったと思うけど、依頼した人が特定されたら駄目だな。
やっぱりウイルスによる責任分散が最強かも。
ガンダムの世界のミノフスキー粒子みたいに、
インターネットから絶対除去不可能なウイルスのようなものを
作ってばらまくことができたらいいのに。

「だと思う」「なはず」「ソースは2ちゃん」は誰も信用してくれません
>>108がインチキ宗教やマルチに騙されないことを祈っています

そしてここは仕様スレ
スレ汚しスマソ

>>112
ウィルスにすると、Kが捜査しやすくなるよ。
被害届出す人が飛躍的に増える可能性があるし、ACCSやら花札屋がこれ見よがしに「ウィルス被害」で
被害届だすと思うよ。

んで、Kは合法的に製作者を捜査・ﾀｲｰﾎ。
またもやP2Pは潰されるのでした……。

完全に匿名で開発する。
開発者にとってはつらいだろうね…
自己顕示欲が出てくるのは仕方ない。
何かしらの策をとってるとは思うけど気をつけてね。

スレ汚し失礼。

>>113
まとめサイトに掲示板作ってそこで仕様以外を話し合うってどう？

>>114
レスありがと。
これは現実的に妄想でね、絶対除去不可能なウイルスに近いものが作れないと意味ないです。
ミノフスキー粒子はその参考として挙げたんだけどねｗ
もしこれが実現できたら、Kが幾らﾀｲｰﾎしても、ｳｲﾙｽ感染者なので無実ですー♪
って話に結論的にはなるでしょ。

53 [名無し]さん(bin+cue).rar sage New! 03/12/07 19:42 ID:jfr/NZBj
UPしたファイルを消去するようなソフトならどうだろう？
つまり著作権物のコピーではなく譲渡。
ファイル交換ではなくファイル譲渡ソフト（ｗ

おもしろそうなのでとってきた。つまり、キャッシュフォルダにあるものをうｐフォルダにこぴー
うｐ後消去。

>>118の内容と、

> 昔、他ノードに手持ちのファイルを無理矢理置く方法ってので、マシンを2台置いて
> 互いに直アクセスできない設定をした上で片方に置いたファイルをもう片方で落とす
> ってのがあったな。
> 要は意図的に転送を発生させて他ノードにキャッシュを持たせる作業。

この辺くっつけるとＵＰ初期の匿名性の低下防げそう。

キャッシュに関しては、こんな感じだと思うし
ttp://tmp2.2ch.net/test/read.cgi/download/1069951193/599
ttp://tmp2.2ch.net/test/read.cgi/download/1069951193/605

仕様だけ話して話が進む訳無いだろうに。
それにどうやら素人がかなり多い。
素人が決めたクソ仕様を誰が作るんだ？

実際一般的に話されている案よりランクが低い内容ばかりだ。
参考にもならん。そもそも断片的過ぎて書く意味すら不明だと思わんか？

>>120
じゃ、開発は藻前に任せた。

いつも通りの展開ですな

>>120
釣りですか？

またーり中は定期的に>>120みたいなの出現
技術的な話してたりすると不思議に>>120みたいなのは書き込まないんだよな
なかなか自分の程度をわかってて良い心構えだｗ

あほか。似たソフト作った奴が家宅捜索された上で作ろうなんて奴は
学生かその辺の年齢層だけだろうに。

>>79
> 問題点2の解決法も、RAID案まかせではRAID案と同じ問題点（トラフィック増、捏造に弱い）を抱えることになる。

確かに。RAID案を使えばいいというのは単なる責任転嫁ですなw

　無作為XORそのものは問題だらけだけど、

・オリジナルの復元には２箇所から２種類のデータのダウンが必要
・しかしそのうち１つはオリジナルのデータとは無関係
・ダウン側は、どちらがオリジナルから作られたデータなのか判別できない
・２箇所のＵＰ者のどちらも善意の第三者の可能性があるので、どちらも責任を問えない

という核心部分のアイデアは使えると思う。
　これの実現方法はたぶん無作為XOR以外にもあると思うし、うまく設計すれば今まで不可避だと思われていた >>12 の問題が（根本的とまでは行かないまでも）解決できる可能性があると思う。

　たとえば相方のデータを探すとき、無作為に選ぶのではなくて被参照量とか流通経路などの情報から安全な相方データを探すアルゴリズムというのも作れるかも知れないし、信頼できる第三者に毎回ランダムデータを作ってもらうのでもいい。


> 答えてくれる人がいるので調子に乗ってもう1つ。「信用情報方式」はどうだろ?

　ごめん、話の流れが読めないんだけど、これもXOR方式と関係ある話？
　Wiki にある「信用情報方式」は、漏れもいいアイデアだと思う。こちらのアイデアもいろいろ問題点はありそうだけど、信頼できるノードが判別できるというのは大きい。
　XOR方式と組み合わせるにしても、相方データを用意してもらう相手を選ぶのに使えると思う。

重要なファイル検索部分を考えてない奴が多すぎる。検索は匿名性無しか？
正直転送と検索の両方が出て来ないと言うだけで
発案者が経験不足の素人だと言うのが透けて見えるんだよ。
ファイルの転送部分なんて普通に暗号化＋多段遅延転送するだけで匿名性は最低限保たれる。

>>126のマゾみたいなクソシステムはお前が作るのか？がんばれよ。

罵るばかりで建設的な意見が出せない>>127が居るｽﾚはこちらですか？

多段転送と簡単に言うが、何も考えないでプロトコルに転送回数入れてたら
隣が出所と簡単にばれてしまうわけで

＞暗号化＋多段遅延転送するだけで匿名性は最低限保たれる

本気？

転送回数なんて入れるわけ無いでしょうが。ランダムだよ。
そう言った常識を話し合ってどうするんだといっとるんだ。どうでも良すぎる。
本気か聞いた奴はマジ素人。

そう言えば海外で多段転送時にTTLを入れている奴があったな。
減るのもランダムらしいので微妙だが、これを回数と言う表現で
言えなくは無いか。しかしランダムには違いない。

>>127
敢えて真面目にレスしてみるw

Winny を例に取ると、各ノードが流れてきたキーを一定期間蓄えていて、検索クエリが届いたらその中から合致するものを探して応答するという実装だった。
通常、検索クエリに応答するのはキャッシュを持っている本人ではないし、応答として返すのは、ファイル名とダウンロード先ノードへのポインタだけ。
つまり、これはＷｅｂの検索エンジンが検索結果としてページ名とＵＲＬを返すのと同じで、検索に応答することには何の違法性もない。

また、ダウンロード先として指定されているノードもキャッシュを実際に保持しているとは限らない（転送機構があるため）。

というわけで、Winny ですら検索システムに匿名性の問題があるという話は今までなかったと記憶している。

>>127 はぜひ、検索システムのどこに匿名性上の問題があったのか問題提起して欲しい。
実際に問題があることがわかったら、解決手段を考えてみよう。

ｎｙの問題はあれだろ。厨房には使えなくすること。
間違っても法流しますたなんて他の匿名でない場所で書かないこと。

>>133
あのな、Winnyを出すな。あれは匿名性殆ど無い。
あれがそんなに素晴らしいシステムに見えるのか？

>>135
システム云々は関係ない
ようは普及したかどうか

>>135
日本語読めますか？

>>135はなぜ「nyに匿名性がない」と言われているのか、
全く理解していないようだ。

逆に言えば匿名性がある広まったP2PシステムはFreenetとnyしかないので
他は全部参考にならないわけであるが

だめだなこれは。まぁがんばってマゾシステムを作ろうとするが
最後には矛盾が生じて挫折してくれ。、

>>138
それ以前に、日本語読めてないよ。
「検索システムのどこに匿名性上の問題があったのか問題提起して欲しい」
って言ってるのに、「Winnyを出すな。あれは匿名性殆ど無い」だもん。

その匿名性が無いと言う問題があるなら、どこが悪いか意見を聞きたいって言ってるのに、
話し聞いちゃいねぇ。

>>135
> あのな、Winnyを出すな。あれは匿名性殆ど無い。

君が問題にしてるのは、検索システムの方でしょ？　漏れが記憶している限り、検索システムに限って言えば Winny に匿名性の問題があるという話は聞いたことがない。
Winny の検索システムのどこに匿名性の問題があったのか指摘してくれ。

>I8wSscp9はシロトに決定でつね

正直、ｎｙを期待されると誰も作れないと思うよ。

正直、nyに問題があるというより使用者側の問題だろう。
自分からアップしてますと情報出してしまってはどうしようもない。

まあ>I8wSscp9はシロートだとは思わないが
何がしたいのかいまいち分からん。

>>126
＞被参照量とか流通経路などの情報から安全な相方データを探す
被参照量は>>46に書いた理由で不可だと思う。

＞信頼できる第三者に毎回ランダムデータを作ってもらうのでもいい。
この第3者が共犯に問われる可能性があるかも。

って文句ばかり言ってすまん。でも、あなたと話したおかげで「無作為XOR方式」の問題点が
自分の中でかなり整理できた。やはり、>>46の2個目の問題点をクリアしつつ、信頼できる
（寿命が長い＋どちらがオリジナルから作られたものか特定できない）相方のデータを探すのは
かなり難しいということかな。
核心部分のアイデアが使えそうだという点は同意。もうちょっと何か考えてみます。


＞話の流れが読めないんだけど、これもXOR方式と関係ある話？
ごめん。79を読み返してみると全く脈絡がなかった。ただ単に、Wikiとこのスレのあいだの
連携がとれてないから、むこうのアイデアにいろいろ問題提起してみようかなと思っただけです。
「信用情報方式」についてはこのスレで出たときもほとんど議論されてないし。

強いて問題点を上げれば、各種情報が転送ノードに対して暗号化されているかどうか
明記されていないことが気になる。今の「信用情報交換方法」だと、転送ノードが
＞２．暗号ＩＤを送信先に送信
を傍受して、転送ノードのIDとパスワードでペアコードを作って送り返し、信用を奪うことが可能な気がする。
まあ、もともとupしてるノードが信用しているノードだからこんなことしないとは思うけど。

あと、信用を集めてもメリットがないのが問題か?　DOMが増える?

126さん以外もよかったら意見をください。>>140とかw

分かってねえな。ファイル転送はどうやっても匿名性が限られている訳だ。
だからより匿名性の高い検索をどううまく使うかが問題なんだよ。

Winnyは検索に関するデータが送られてきた時に即そのデータの
ダウンロードを試行すると実際にそのファイルが同じPC（IP）から
送られて来る場合がある。どうだ？どうやってACCSが違反者探すかわかったか？
Winnyの検索って問題ないなんて聞いた事無いか。それ位中級者以上なら聞かなくても分かると思うがね。

何度も言うがそもそもWinnyなんて出す時点で素人だ。

あれ、IDかわってしまったか

ソースを奪った警察は今言った方法で違反者を探しているからな。
せいぜいWinnyは検索も転送も匿名性があると信じて使うんだな。

>>148
で、結局何がしたいんだ？

>>148
はいはい、あなたがスゴいのはよくわかりましたよ

Wikiの「隣接ノードに情報を漏らさない」方式はどうかな?
検索、転送ともに考慮されているが?

これがだめだというなら、自分でアイデア出すように。
否定するだけなら誰でもできる。

>>134
＞ｎｙの問題はあれだろ。厨房には使えなくすること。
この考え方は間違っている。
誰もが安心して簡単便利使える様にする事が大事。

匿名性が高ければいいんならFreenetでいいわけで、なんでFreenetでいけないかというと効率の悪さだ。
よって論点はFreenetをいかに効率よくさせるか、そして匿名性を落とさないですむかということになる。

>>148
で、なぜお前は警察やACCSの捜査方法を知っているんだ？

>>155
まぁ、それはこのスレの前提みたいなものですから…

結論まだぁ？

>>148
＞Winnyは検索に関するデータが送られてきた時に即そのデータの
＞ダウンロードを試行すると実際にそのファイルが同じPC（IP）から
＞送られて来る場合がある。

たまたまそのノードがキャッシュを持ってたか中継してるだけだろ。
何が問題なんだ？

仕様決定まだー？

>>147
> 核心部分のアイデアが使えそうだという点は同意。もうちょっと何か考えてみます。

　期待してます、こっちももう少し考えてみます。


> 今の「信用情報交換方法」だと、転送ノードが
> ＞２．暗号ＩＤを送信先に送信
> を傍受して、転送ノードのIDとパスワードでペアコードを作って送り返し、信用を奪うことが可能な気がする。

　これは、もう一段外側に暗号化をかまして、まず相手に情報交換用の公開暗号鍵を渡すとかする必要があるかも知れませんね。

> あと、信用を集めてもメリットがないのが問題か?　DOMが増える?

　確かに。今のままだと、信用集めると転送を押し付けられる確率が高くなるので、信用されるだけ損(w

　信用したノードに、優先的にファイルキーを送るようにするというのは？　こうすると、そのうち良ノードだけの巨大なクラスタができる。
　参加当初はクラスタの外側だけど、貢献しているうちにクラスタの内側に入れてキーがいっぱい集まるようになるとか。


　私的には信用した相手が持っている信頼情報も使いたいところですが、これをやってしまうと穴ができてしまうんですよね、きっと。

思い切って匿名性ゼロにして、違法ファイルは合法ファイルに埋め込むような擬装すればいい。
一見合法ファイルしか流れて無い、人畜無害のファイル交換ネットワークだと思わせといて
分かる奴には分かる玄人向けシステム。

>>161
信用情報でノードが特定される事はないか？
怖くて使えん

あ、訂正。

> 信用したノードに、優先的にファイルキーを送るようにするというのは？

普段は被参照量の多いキーだけ周りに転送するけれども、参照量の少ないものは信用した相手にしか送信しないとか。
すでに広まっているファイルほど追跡が難しいので、そういう情報が信用できないノードに渡ってもあまり問題ない。
レアファイルが欲しいとか、ファイルが早く欲しい場合は頑張って信用を集める必要がある。

披参照量のしきい値は、自律的に決めれそうな気がする。

>>162
そんなもん警察が本気で捜査すりゃそのわかる奴になるんだし
芋づるで逮捕だろうが。信頼できる奴にしか使えないパスワードも足すんなら
FTPやMXで十分事足りる

基本的な質問なのですが、

A---B---C

という形で3つのノード(PC)が繋がっているとき、
AからCに向けて、Bには理解できないような形で
データを送ることって可能？

（あらかじめ秘密の暗号鍵みたいのをAとCで共有しておけば可能なのはわかってる。）

BとCが必ずKになるように仕組まれてると怖いね。

>>163

　Wiki のを読んだ限り、その辺はちゃんと考えられてるような気がします。

　自分のＩＤを渡す相手は実際にデータ転送した相手だけなので、実際のところ何の問題もありません。相手にはすでに何かをアップロードしちゃってるわけで(w
　しかもそのＩＤも暗号化されますし、ＩＤの照合も暗号化された状態で行うので、このシステムにより危険性が増すことはないと思います。

　ただ、相手の持っている信用情報を交換できるようにしちゃうと、いろいろ穴が出てきそうで怖いです。芋づる検挙とか(w

>>166

1) A はまず公開鍵と秘密鍵を作る。
2) A は、公開鍵を B を介して C に送る。
3) C も、公開鍵と秘密鍵を作る。
4) C は、A からもらった公開鍵で自分の公開鍵を暗号化する
5) C は、それを B を介して A に送る。
6) A は、自分の秘密鍵でそれをデコードして、C の公開鍵を知る。
7) A は、送りたいデータを C の公開鍵で暗号化する。
8) 暗号化したデータを、B を介して C に送る。

　B は、C の公開鍵を知らないので、中継しているデータをデコードできない。

>>169
もしBがCにAの公開鍵を転送したと見せかけて
Bの公開鍵をAに渡せたらおしまい。
まぁ、クローズな環境で作れば問題ないか。

>>161
私の下手な説明で全部分かってくれてる…話の分かる人だ。

＞信用したノードに、優先的にファイルキーを送るようにするというのは？
なるほど…これはいいアイデアだと思います。
私が考えていたのは、Winny同様、「up量（転送含む）に応じてdown量を増やす」
というものだったんですが、これよりも効果が大きそうですね。

ほかの意見（公開鍵方式、他ノードの信用情報の利用）も両方同意です。
後者は、著作権者の同意を得て、Kが1回upして信用を得てしまうと、その
ノードが安全であるという情報が広まってしまうって事ですからね。

Wikiの管理人さん、最近このスレ見てるのかな?
ここで出たアイデア、登録していって欲しいんだが…。
あるいは、せめて [意見} 全部にコメント記入フォームをつけるとか。
よろしくお願いします。

>>166,169,170
Wikiの「隣接ノードに情報を漏らさない」方式がそれに近いと思う。


今日はもう寝ます。失礼。

ごめんなさい、私がバカでした ヽ(°ω°)ノ

1) C は、公開鍵と秘密鍵を作る。
2) C は、B を介して公開鍵を A に送る。
3) A は、送りたいデータを C の公開鍵で暗号化する。
4) 暗号化したデータを、B を介して C に送る。
5) C は、自分の秘密鍵でそれをデコードする

だけでＯｋでした

>>168
Wiki読んでみた。
いまいちメリットが少ない悪寒・・・
>164みたいな事すると真っ先に拡散すべきポエムが
広まらないなんて事態も考えられるし。
いっその事人気投票と割り切ったらどーだろ？ｗ
信用集めたらほんの気持ち程度、ファイル落としやすくなる（気がするだけｗ）

>>159
サル知恵を披露して恥かしくないか？

Winnyの検索はこのアドレスにこのファイルがあると言う事を示すキーを
流通させると言う匿名性は考えられていないものだ。
たまたま他の奴のキーを保持しているだけの場合は中継する事になるが
（と言ってもWinnyは出来る限り直通にする処理を行うらしいので殆ど無いと言える）
プロバイダへ簡単な通信履歴を確かめるだけで中継しているかどうかは
簡単に分かる。通信内容は別に知らなくても構わない。

しかし稀に知らずにファイルを中継した時に出来たキャッシュであると言う可能性がある。
その為にヘビーユーザーを狙うんだよ。
少なくともファイル10個以上を対象にすれば一つ位はキャッシュの内容を
知っている筈だからね。ファイルの対象を増やし期間も長くすればそれだけ
精度が上がる。一万人逮捕で誤認逮捕が一人いるかどうかの精度だよな。
キーの寿命を過ぎた後に何回か検索を行えば他人のキーかを調べる事も出来る。
お前の共有ファイル丸見えだな、おい。
匿名性の無い検索システムだからこそ成せる技だと思わんか？

まぁ他にも色々欠点があるが、長すぎるからこの辺でやめとこうか。

責難は成事にあらず、と。

責難は成事にあらず (せきなんはせいじにあらず)

　砥尚の退位の際の遺言。
「人を責め、非難することが、すなわちなにかを成すことではない」という意味で、他人を非難することがそのままなにかが前進することには繋がらないことを戒めている。
　慎思が砥尚に語った言葉は「責難するは容易いが、それはなにかを正すことではない」だった。

http://digitarius.easa.ne.jp/novelclo/12koku_body.html#SAGYOU_LABEL79

はおいといて･･･。
ｎｙにおける検索キーの非匿名性についてvs2c7cZIの言いたいことはなんとなく分かった。
つまり、対象ファイルのキーが流れてくるノードを広いまくって、統計的にそのファイルを持っている確率が一番高いノードをUP元と特定するということかな？

警察です。

接続優先度をご丁寧にも青色表示してくれるノードとか？

>176
しかしＫさんがそれで特定して踏み込むにしても、結局は別件でしかないと
思うんだがなー。
踏み込まれる奴は、別口でスカタンやらかしてるわけで。

検索に関しては、ある程度の非匿名性で折り合って構わんのじゃなかろうか。

検索の匿名性は、あまり関係ないと思うがどうか？

そもそも、検索っつーのはダウソ側がするものだろ？
ダウソは合法なのだから、誰が何をダウソしてるかもろバレでもかまわないだろう。

もちろん検索も匿名化されれば一番いいが、最優先事項は実際のアップロードの匿名性。

著作権ヘブンなあの国を上手いこと利用できないですか？

>>174
＞少なくともファイル10個以上を対象にすれば一つ位はキャッシュの内容を
＞知っている筈だからね。

常設ノードなら知らないうちに何をキャッシュしててもおかしくない。
そして内容を知らないキャッシュを保持する事自体は今のところ問題ではない。

確かに、放流直後にﾀﾞｳｿすれば高い確率で放流主から落ちてくる。
しかし予告がなければ拡散前のファイルを狙って落とすのは困難だし、ファイルが
落ちてきたノードが放流主であるか確認する事も出来ない。
（地引で引っかけただけかも知れない）
つまり逮捕するには放流予告した者のIPアドレスと実際にファイルを落としたノード
のIPを一致させる必要があるわけだ。

nyBBSのスレ主に匿名性があれば今回の逮捕はなかっただろう。
検索システムの問題ではないな。

>>170
そうでした、私がウルトラバカでした

B がこっそり自分の暗号キーと入れ替えて渡せば、A も C も傍受されて
いることにすら気づきませんね・・・。

　なんらかの形で A が C にデータを持っていることを知らせるプロセスは
あるはずなので、その時に公開鍵も渡すしかないかも。


>>173
>いまいちメリットが少ない悪寒・・・
うーん、、
「たくさん流通に貢献をしないと捜査すらできない」ようにできる、としても
メリットは少ないでしょうか。可能かどうかはもっと検討が必要ですけども。

人気投票はいいかも。評価された側はそれを知ることができるようにしてもいい。
ただし、自分の貢献度が数字１つでわかるだけ。何が評価されたのかは分かるとまずい。

信用度なり人気投票なりの案は良いね。
これがWinnyに実装されてれば、クラック版使うDOMの蔓延も防げるだろうに。。。

馬鹿すぎてお話にならない。
検索キーでup元を突き止めて逮捕？
あはははﾊｱﾊｱ
頼むよホント。
つたない知識で煽ってないで勉強し直してこい。
助けてやってもいいぞ。

>>184
てか、オープンソースを目指すんなら信用度のシステムは避けて通れないよね。
ny みたいに DL 数の制限ってつけられないから、地引きダウンみたいなことをしてる香具師ばかりが貴重な UP 帯域を占有することになる。

いくら暗号化しても、受信者がデコードできなければ意味が無いわけで、
他人がデコードできる以上、kは流れてるファイルを特定可能なわけで。

暗号化も必要だけどUL先を特定しにくいような転送方法がどうしても必要だと思う。

>>180
>ダウソは合法なのだから、誰が何をダウソしてるかもろバレでもかまわないだろう。


時代と共に法律の解釈は違ってくると思う。
FTP＆MXの時代は販売目的でなけらば合法って思っていた節があった。でも蓋を開けてみれば
逮捕だったし利用者が多ければそれだけ社会的に問題になるわけで、、、

八方塞がりなった警察やACCSが追いつめられて「D.Lでもタイ〜ホ♥」なんて事になっちゃう
から匿名に出来るんなら匿名にした方が良いと思う。

書き込んで気づいたがコッチ↓での話題だったね。ごめんね

次期P2Pのクリアすべき課題を法的な観点から考察（Part2）
http://tmp2.2ch.net/test/read.cgi/download/1070500722/

>>188
DLだけで逮捕だと捜査が難しくなると思われ。
Kが著作権者に無断で捜査できなくなる。
もし捜査の過程で許諾を受けていない著作物を間違って落とそうものなら…

DLだけで犯罪はありえないでしょ。
ロリペドものなどの、所持しているだけで犯罪になるようなもの以外は。

よって検索の匿名性はあとまわし。

>>191
そこらへんは発揮しいってサポート外じゃないかな？（このスレで）
それと、すみません。法律の話は>>189のサイトが良いかと・・・

久しぶりに覗いてみれば、面白い奴が出現してたのネ
ただ、良い事も言ってるので一部参考にされたし。

>>148あたりで書かれてるけど、
要求に対してレスポンスが異常に早いと、UP主やｷｬｯｼｭ持ちの可能性は高い。
>>127にあるように
転送やＵＰ送信に延滞を入れると解決策にはなるんだけれど、
中継をかませる程にＤＬがアホみたいに遅くなる。
この辺の矛盾を解決すべーし、と考え中。

>>193
中継の時はタイムラグをなくす手法もあるが、それだと匿名性が一部弱くなりそうだな。

多重ダウンロードを増やして対処すべきなのでは？
現在のNYは多重ダウンはあまり発生しないようだから、
最低でも二重ダウンが発生するようにして、
できれば四重五重にできればいい。
中継者やUP者に負担がかかりそうだが、そもそも中継を
重ねるごとに転送速度は遅くなっていくんだから、
一つのUPごとの限界帯域を、最大帯域の１０分の一とかに
決めておけば、解決するのではないかと思う。

>>180
多分何か勘違いをしていると思う。
ここでいってる検索の匿名性というのは、ファイルの位置を示すキーの匿名性だと思う。
nyでいう検索キーではなく、仮想ファイルキーのことをいってるのだと思われ。

つまり、｢このファイルを探してるやつ」の匿名性ではなく、
「このファイルを見つけさせようとしてるやつ」の匿名性とう感じだろうか。

例えば３日前の中継でできたキャッシュの出所を追えるわけないのに
何重にも多段中継する意味あるのか？

nyの匿名性の肝は、転送つーより、意図しないキャッシュを持つことによる、無自覚のアップが生じることだと思われ

今回の逮捕の問題点はnyのファイル共有とは別の経路で
自らの意思でアップしていることを示してしまったからだろうし

で、俺以外で作っているやつ、中年のほかに誰よ?

このスレで作ってるって発言したひとでスクリーンショットうぷしたやつ一人もいない
作ってるってレスするときは一緒にSSもうぷしろよ

本当に作ってる人はこのスレに書き込みません

わざわざモチベーション下げるような行為を自分でする理由もないわけで

こんばんわ、警察です。

そういえばもうすぐ正月だね。もち食いたくなってきた。
今年のクリスマスは世界情勢に鑑み中止が決定したし・・・ローマ法王ナイス判断。

ホントに作ってる人はFREE NETにかいてるかもよ

「FREE NET」ってなに？
Freenetなら知ってるけど

>>207
スマソ 半角にしなかった

お前らの出すクソ転送システムは参考にもならんが、おれの出す発言は
警察が参考にするかもしれんぞ。(まぁ警察内部で既に結論出ているだろうが)
それでも良いならもう少し説明してやろう。

まずWinnyでファイルをDLするとそのファイルのキャッシュが自動的(！)に出来る。
このファイルは他のクライアントへ転送が自動的に準備される仕組みだ。
これを47氏は転送と呼ぶが、よく考えてみろ。これは違法ファイルの再配布だ。
キャッシュを特定して消す機能さえあるが、あえて放置しても合法なのか？
特に常時付けている様な奴はこの性質を熟知している訳だ。
つまりWinnyでのダウンロードは即再配布に繋がる為他のソフトより違法性が高い。
これはWinnyでDLした奴に犯罪を勧める行為とこじつける事が出来る部分だよな。
これを根拠に家宅捜索を受けたのではないのか？

Googleやプロキシのキャッシュが良くてWinnyのキャッシュが良くないと言う根拠がここにある。
外部からの要請を受けて削除させる事も出来ないしね。

続く

>>209
んなこた、既に周知のこと。
おだまり。

特定のIPへ接続し、キーを要求できると言う構造なわけだから
光などのほぼ固定された環境では長期に破棄されないキーを調べる事が容易であり、
現在保持しているキャッシュや公開ファイルが丸見えに鳴ると言う事は説明したな？
匿名性の無いファイル検索システム万歳だな。
その中に一つでもダウンロードしたファイルがあればそれは犯罪行為。
当然初めから公開したファイルがあったも犯罪。

麻薬の売人が麻薬を持ってターゲット宅へ入り、出て来た時に麻薬が無かった場合、
売人自身が使ったと言う可能性をまったく無視して家宅捜査が出来るよな？
お前ら家宅捜索受けても大丈夫なPC等の記録媒体なのか？

Winnyを使うだけで違法かもしれないと言うのは半分脅しだろうが、
派手に使えばほぼ間違いなく違法。
今回の逮捕は手を付けやすい奴から捕まえただけ。

あと博士取得出来る位のスキルが無いと転送に匿名性を出すシステム創作は難しいが、
お前らは素人が作る穴だらけの転送システムに頼ろうとしてるようだな。
その上で検索はファイルを探せれば良く匿名性はいらんと言う素人の戯言を信じるか？
素直に既存の欧米にある匿名性が高いシステムをパクッとけ。

http://s2net.s41.xrea.com/x/p2p/
p2pに関していろいろなことが話し合えるように掲示板設置しました。
2chが怖くて書き込めない人、仕様意外話し合いたい人や
雑談実況なんでもどうぞ

ってだれか書き込んでくれるかなぁ・・・(´･ω･`)

>>212
乙ｶﾚｰﾏﾙｼｪ(ﾟдﾟ)ｳﾏｰ

174=209=211はプログラミングの経験ないだろ

４７氏は情報工学博士なわけだが

>>210
書き方は乱暴だけど、言ってることは正しいね。
検索時の匿名性が必要なのは事実。
どっかのページでそのことにふれていたような記憶があるけど・・・忘れた

Winnyの最大の発明は、
「匿名性」という看板をぶちあげることでキャッシュによる効率を得たこと。

Winnyの検索ネットワークの単純さそのものが、
匿名性に対する最大の脆弱性になってることに気づいてる人は少ない罠。

さんざんｶﾞｲｼｭﾂの話題を
さも自分が初出のように偉そうに騙るスレはここでつか？

>>214
どうせ信じないだろうが、おれはネットワーク系アプリ専門(微妙に専門とは言い辛いが)だよ。
もちろんPerlを触るだけの様なエセプログラマではないぞ。
通信系ソフトも配布しとる。少なくともお前よりは色々知っているぞ。
虚言癖がある廃人で全ての発言はデタラメだと思うかどうかはお前の自由だがな。

>>219 言ってることは正しいんだからもちつけ(w

寝言は何か作って見せてから言え

>>219
別にデタラメだとは思わないが、
コンプレックスの塊なんだ、と言うことはよくわかる。
「博士」「欧米」

＞あと博士取得出来る位のスキルが無いと転送に匿名性を出すシステム創作は難しいが、
＞お前らは素人が作る穴だらけの転送システムに頼ろうとしてるようだな。
＞その上で検索はファイルを探せれば良く匿名性はいらんと言う素人の戯言を信じるか？
＞素直に既存の欧米にある匿名性が高いシステムをパクッとけ。

>>219
いままでドロシーとかだましがいっぱいあったから皆ぴりぴりしてるんです。
もちつきましょうよ・・・（ ´∀｀ ）b

×　博士取得
○　博士号取得

匿名にするだけならFreenetでももってくりゃいいわけでここでのテーマは匿名性と効率の両立だ

既出と言うが、いつそう言う話が出たんだ？
お前みたいに2chへ入り浸っていれば発見できそうだがな。

ともかく、中級以上の奴であれば他人に聞かずとも同じ結論がでるはずだ。
Winnyは匿名性が無いので参考にならん言った時点で理解できないお前らは、
本当に過去同じ文章を見てそれを理解できたのか？

>>226
で、あんたは何がしたいの？

理屈馬鹿ID:BToT01Lpよ。さらば。

>>223
37歳という年齢の時点でおかしいと思ったんだが、
その点はだれも指摘しなかったの？

>>211
＞麻薬の売人が麻薬を持ってターゲット宅へ入り、出て来た時に麻薬が無かった場合、

麻薬の所持と違法ファイルの所持を同列に扱ってるｱﾌｫﾊｹｰﾝ

すぐに欧米に頼ろうとする奴がいるから日本のソフト面の技術が遅れるんだよ。
出来合いの技術をパクるだけならキムチにもできる。
斬新な物を生み出して日本の力を見せようとか思わないのか？
…でも漏れにはムリポ(´･ω･`)

★★★★★★★★★★★★★★★★★★★★★★★★
ここは次期P2Pの仕様に関するレスをするスレッドです。

法律論や要望はスレ違い。他スレでどうぞ。

スレ違いのレスが有った場合は荒らしとして完全放置、

スルーしましょう。
★★★★★★★★★★★★★★★★★★★★★★★★

>>226

なんつーか、その程度の問題はとっくに認識されてるようにしか思えんが・・・

どうでもいいけど、どうせなら、あんたが考える匿名な検索システムに必要な
要件を定義しておいてよ。解決法考えろとは言わないからさ。

今のままじゃスルーされるだけで何も残らんから、せっかくだから形にしときなよ。

(´-`).｡oO(ちゃんと認識してる人と、認識してない人が居るんですよ……。)
(´-`).｡oO(Winnyの問題点を正しく共有する事が需要と思われ。)

>>227 >>233
>>127の発言を長々と証明してきただけだよ。あの時点でWinny出す様なやつらが
一連の話を認識しとるかね？素人議論では話にならないから
取り合えず開発陣を集めてその中で仕様を考えたほうがいいんじゃないの？

>>226
とても参考になる話でした。
他にも突っ込みどころがあるようでしたら、どんどんカキコお願いします。

>>219
211の「システム創作」ていうのに違和感があった。
最近の人はそういうのかと思ってぐぐったけどほとんど見当たらない。
他にも何ヶ所かあるけど

ちなみにネットワーク系アプリ専門ということだけど
開発言語は何？

Winnyの場合、匿名性ではなく、アップの責任逃れにその意義があるんだろ

BToT01Lpって頭の悪そうな喋り方だね。ほんとにプログラマなのか？
問題点がわかってんならその対策を書けよな厨房

>BToT01Lpは昨日から必死ですね。

やっと自分の居場所ﾊｹｰﾝってとこですか？

IDが泣いてますよｗ

>>235

というか、>>209 >>211 のあんたの主張も Winny を例に取ってるし、その主張のような
問題は、RAID5方式とか「隣に情報を漏らさない」方式を見ればわかるように
開発の方向は言われるまでもなくそれを解決する方向に向かってる。
わざわざ Winny を持ち出してくる意味がわからない。


> 開発陣を集めてその中で仕様を考えたほうがいいんじゃないの?

「要件を定義して」の意味わかってる？　プログラマじゃなかったの？？
仕様を決めようにも、何が求められているんだかわからないから、
それを決めてくれとお願いしてるんだが。

おいおい、プログラマが頭いい奴ばっかりと思うなよ。
おれはC++とJavaがメインと言えるが、他の言語も古く無い奴は
多少出来る。（C系やっている奴なら大体は同じ感じのはずだ）

ただしWinnyのバイナリから構造を解析する様な技術はもって無いよ。
しかしソースがあれば説明した事を実現するツールを作る事は出来る。
しつこいがネット系は得意だからね。

おお、作ってくれるのか。有り難いね。

作る訳無いだろうが。家宅捜索、逮捕はごめんだ。絶対作らねえ。

つーか、本当に頭悪そうだな

頭悪い香具師しかこんな板こねぇ

頭は悪いが技術はあるよ。ともかく転送部分の自作だけは止めとけ。
既存のを多少改良すると言う程度が限度だ。

まぁ頑張ってくれ。おれは素人案をけなすことなくROMる事にするよ。

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>247
漏れは、あんたの主張がひょっとしたら有用なものかも知れないので
理解したいと思ってたんだが、結局電波で終わってしまうのか？

あんたが考える「安全なシステム」が備えるべき条件を残しておいて
欲しいだけなんだが。

>>247こういうのは今後>>232しましょう。

頭は悪いが技術はある？漆器職人か何かか？

>>249
まぁ多少馬鹿にし過ぎた為、おれの発言はマイナスになるぞ。
ここに居る奴らは反抗的なのが多いからな。
既出の嵐の後、その案と対極を目指したりするだろうから無駄だな。

それに判ると思うが、おれレベル以上なんて腐るほど居るだろう。
それらしい板から助言を貰って来れば良いんじゃないか？

>しかしソースがあれば説明した事を実現するツールを作る事は出来る。
(ﾟДﾟ)ﾊｧ?

どっと疲れが出た・・・寝る。

>>232 >>250
ごめんなさい、私が悪うございました・・・
反省します。

ID:BToT01Lpはny利用者がnyの特性を熟知していて、それを前提としてKが
動いたという"思いこみ"をnyの欠陥を主張する根拠にしてるだけだからな。

実際はどうだか。
網走で流入した連中にとって共有ソフトの内部動作などに興味はない。
欲しいファイルを手っ取り早く手に入れたいだけだ。
動かすのに最低限の説明だけ読んでぶん回してるわけだから、どんな時に
キャッシュが出来るかすら知らない人もいる。
匿名性低下などのデメリットを説いてもポト0が減らなかった事からも本当に
最低限の操作しか知らない/知ろうとしない連中が大量にいる事が伺い知れる。
つまり↓(>>209)の根拠にはなり得ない。

＞特に常時付けている様な奴はこの性質を熟知している訳だ。
＞Googleやプロキシのキャッシュが良くてWinnyのキャッシュが良くないと言う根拠がここにある。

昨日は放流元の匿名性を問題にしていたはずだが、今日は微妙に論点をずらしてるのな。

サイズの同じ2つのファイルAとBがあるとき、
A＋B⇔C＋D
っていう変換を、次の2つの条件を満たして行うアルゴリズムってある?

・A、B、C、Dは全て同じファイルサイズ
・CとDのどちらか1方だけ持っていても、AとBに関する情報は一切得られない。

お、ひょっとしてなんか面白いアルゴリズム作ろうとしてますか？(・∀・)

(A,B)->(C,D) の変換

Ａの偶数ビット→Ｃの偶数ビット
Ｂの偶数ビット→Ｃの奇数ビット
Ａの奇数ビット→Ｄの偶数ビット
Ｂの奇数ビット→Ｄの奇数ビット

とか？　ＡかＢの１つがあればＣやＤの半分は予想できますが、完全には
わかりません。この変換は (A,B) と (C,D) を入れ替えればそのまま
逆変換ができます。つまり、(A,B) のペアと (C,D) のペアは等価です。

シャッフルテーブルを使った変換も考えられますね。

こんばんわ、警察です。

>>258
　　　　　　　　　 〈〈〈〈　ヽ 　　　　　　　　"':;:　　,ィ⊃　　, -- ､●
　　　　　　　　　　〈⊃　　}　　　　,r─-､ 　;;;::ノ 　 　,. ' ;;:／ 　　,/ 　 　:;;;:;ノ }
　　 ∩＿＿＿∩　 |　　 |　　　　{ _;:;::;:;）ヽ 　;:;／ ∠ ､＿__;::/　　++::::;:;:ノ　　|
　　 | ノ　　　　　 ヽ !　　 !　　　　ヽ,;:;:;ノ､　　'　　;;:;;ノ　 ;::;ヽ_/　ｒｭ､ ﾞ､　/
　　/　　●　　　● |　　/　　　　　＼　 l　,　_;:;::;:;）､　!,;:;:;ノ''}　YWW　　ww
　 |　　　　( _●_)　 ミ／　　　，,･_　　　ヽj 　,;:;:;ノ'　⊆;:丿｀　!
　彡､　　　|∪|　　／　　　 ’,∴ ･　¨　　l　　　;;::::）-‐ｹ　　;:;::ノ}
/　＿＿　 ヽノ　/　　　　､･∵ ’　　　　 ヽ. 　;:丿;:丿‐y　　/=======--- -●
(＿＿＿）　　　/　　　　　　　　　(ヽ､＿_,.ゝ､　　:;:;::ノ　;;: 　~_:;;::__,ノ ,-､

>>256
CかDのどちらかをKがダウソ開始
↓
そのときESTABLISHDなIPのみフィルタリングで許可
↓
そのIPからCをKがゲット完了
↓
そのうちDも同IPからKがゲット
（同一ノードへの複数転送禁止システムなら回線繋ぎ直せばOK）
↓
違法ファイルをそのIPからKがゲット
↓
タイフォ

というかキャッシュを暗号化するｎｙと大差無し。

とｵﾓﾀ。

おれも思った。

　|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
　|　以下何事もなかったようにどうぞ |
　|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|
　 　　∧ ∧ ||
　　　(.｀□´)||
　　　/.　づ.Φ

　んー、>>256 がそういう方式を考えてるんだったら A+B→C となるようなのを
聞くんじゃない？　なんかオモロイの考えてるかも知れないし、とりあえず
先走るのは止めようよ。

o-o、
(’A’) ﾒｶﾞﾈﾒｶﾞﾈ
ﾉ　ﾉ)_

BToT01Lp の言い分は、眉唾、言い過ぎや過剰気味に見えるのは認めるが、
大まかな内容で俺も同意。荒らし(擁護)ぽくみえてしまうかもしれないが、
落ち着いて要点をかいつまんで読むと有用な内容ではある。

検索を含む各種キー交換、クエリ処理の匿名性確保案はまだ公開して
いないが私も持っている。今の私の問題は、多段階転送（遅延を入れる
などの隠蔽、偽装処理を含む）での匿名性の確保の論理的証明。
今のところ、多段転送開始時の手続きに不安が残る。

私個人の現状の意見(というか私が設計・開発する場合の採用案)だが、
キー交換、検索クエリの匿名性の確保に関しては、またいずれ説明する。
キャッシュ保持方法に関しては、「変形RAID5」の三分割方式が妥当と考える。
この場合は、完全なデータを復元できない部分データを持つことが違法と
なりうるかという部分だが、これはスレ違いなのでここでは合法という前提で。
この方式では、ファイルの収束性(DLを完了させること)と耐久性(DL完了した
キャッシュが削除されてしまうことへの対策)に十分な対応力を持っている。

読み返してみるとちょっと訳わからん文章になってスマソ。またそのうち続き書きます
大学院を退学してPerlOnlyで製作したネットゲーム(非MMO)を運営中の開発者より

最初にうｐする時、登録したらキャッシュになって
キャッシュはバラバラに勝手に他の人にうｐされていく
手元のキャッシュは消える
他の人にダウンロードされたキャッシュの一部は
勝手に他の人にコピーされていく
自分では何のキャッシュを持っているのかわからない

勝手にダウンロードしたキャッシュのフォルダと
ダウンロード用のフォルダとわける
ダウンロードしたファイルはアップロードされることはない
ファイルの一部のキャッシュをみんなが持つ
ダウンロードする時は
いろんな人が持っているファイルを集めていく

参加してる人みんなで
おっきなデーターベースのようなものを作る
うpもダウンもデーターベースに働きかけるという形になる

データーベースはダウン登録等に関係なく
情報をやりとりしていき
勝手に広がっていく

うｐ→データーベース→ダウンロード
ファイルを持ってる人からじゃなく
いろんな人の間で作られてるデーターベースからダウンロード

匿名P2P掲示板だが、設置運営する人・発言する人・読む人の３タイプに分けられるが、
発言する人と読む人の匿名性は論理的に証明できるのだが、設置運営する人は現状で
匿名を維持する事は不可能と判断している。これに異論があれば是非聞きたい。
プロバイダ責任法などがあるが、設置した人に責任を取ってもらう(任意に削除などが
できる)仕組みとして匿名性が無い事は仕方が無い(仕様？)と考えているが、この点に
ついて(匿名掲示板を設置したい、発言したい、読みたい)利用者候補の意見を希望する。

>>268 wiki読んでこい

キャッシュに関する疑問だが、俺は２ｃｈのnyスレを流して読んだ事が無いので
知らない(誰か詳しい人の説明希望)のだが、自分が本来目的としないキャッシュ
(いわゆる転送で溜まるキャッシュ)は、どのように扱われているのか知りたい。
・自分には必要ないものだから消す
・ポト０など自分の必要なものしか溜まらないようにしている
・ｎｙはそういった仕組みで構成されているから大目に見る
・有効に活用したいから部分キャッシュなら完全キャッシュ化のためにＤＬ指定する
他にも直接目に見えて自分の為でないネットワーク資源の浪費とも取れる転送リンクや
ＵＰリンクに関する扱いも同様の利用者心理を知りたい。詳しい人説明よろしく。

第二世代のP2Pは、ゲートウェイ機能付きがいいんじゃないか？

つまり、nyに（あるいは次世代のnyに）海外でメジャーな匿名P2Pシステム
（freenetでもなんでもいいよ）とのゲートウェイ機能をもたせて、海外の
システムからダウソしたものは自動的にnyのキャッシュに入るようにする。

このしかけを悪用すれば、自分で海外のP2Pにウプしたものを自分でnyに
ゲートウェイしつつ著作権厨の追求を事実上不可能にできるが、それは
副作用で、本来の意図はP2Pのファイル流通範囲を広げることだ。

>>272
UPフォルダでも共有したらｗ

> 自分で海外のP2Pにウプしたものを
その時点でタイーホ。
全然追求から逃れられていない。

所詮が厨房の考えられることはこの程度か。

私個人の設計になるが、前提条件を整理すると次のようになる。

あらゆるデータはＵＰ者⇒転送者⇒ＤＬ者と流れると仮定する
あらゆるデータとは、キャッシュ本体、ファイルキーの拡散を指し、
検索クエリに関してはＤＬ者⇒転送者⇒ＵＰ者⇒転送者⇒ＤＬ者となる

まず妥協点(前提条件、仕様？)をあげると
・完全な状態でない部分ファイルをＵＰする事はＯＫ
・ＵＰ者が自分が部分ファイルを持っていると公開するのはＯＫ
　匿名性を維持するファイルキー(？)拡散、管理法があれば説明よろしく
　早い話がＤＬ者に対してＵＰ者の匿名を保証することができるかの部分
・転送者が「転送データの内容」を(事後にでも)知る事ができるのはＯＫ
　これが無ければ転送によるキャッシュ分散が不可能になる

私が考える問題点(ＮＧ)となる仕様(状態)
・共有するファイルが完全状態でＵＰされている状態はＮＧ
・ファイル検索クエリを出した本人(ＤＬ者？)を特定できるのはＮＧ
・ＵＰ者(キャッシュ保持者)がＤＬ者を特定できるのはＮＧ
・転送者が「転送元がＵＰ者である」と確定する事ができるのはＮＧ
・転送者が「転送先がＤＬ者である」と確定する事ができるのはＮＧ
　(調査によって確信が持てる程度に特定できるのは考慮せず)

上記で挙げた内容は、ＯＫという仮定が成立しなければＮＧとなり、
ＮＧに挙げた項目も問題なければ(解決法があれば)ＮＧで無くなる。
よって確定した条件でないことを最後に挙げておく。
反論や疑問点、その他不足点などがあれば、指摘よろしく

>>269
そもそも「設置」だの「運営」だの「管理」だのがないのがP2Pだろ。
何を設置、運営するわけ？板？
レスをP2Pでかき集めればそれが板になる。時系列で並べれば2chみたいになる。
Netnews みたいにしたいならIDを付ければいい。

>>274
実現方法ではなくて、要求仕様を検討する段階ということでいいんですよね？

転送者は必ず一人以上存在することを保証するつもりですか？　それとも、
たまたま近い位置にいた場合には直接転送もやむなしとお考えですか？

また、転送段数に関する仕様の予定も聞きたいです。

>>274
あ、あともう１つ。

ソフトはオープンソースで開発するつもりですか？　それともクローズでやるつもり
ですか？　オープンソースだと部分的に実現が難しくなるところが出ると思うので、
そこをまず知りたいです。

何か前提が分からないんだけど、どっち？

完全な匿名性は確保できるはずだ。->その証明をし、仕様にする。
完全な匿名性は確保できないはずだ。->出来る限り警察に追跡しにくい仕様にする。

>>276 質問＆指摘感謝。まずは実装ではなく、論理的判断(仕様決定)がこのスレの本文だと思っている。

転送者の数に関する判断から。用語説明：ＤＬ元(ファイル転送元)　ＵＰ先(ファイル転送先)
・転送を１段階と固定した場合、ＤＬ元がファイルＵＰ者でＵＰ先がファイルＤＬ者と特定される
・転送を２段階とした場合は、ＤＬ元、ＵＰ先がそれぞれＵＰ者、転送者、ＤＬ者のいずれか特定できなくなる
・転送を３段階以上とした場合は、完全に判断不可
・２段階の場合は、ＵＰ者、ＤＬ者いずれかのＩＰは特定可能
転送段階に関しては、少ない方がいいのは間違いないが、上記の条件から最終的に判断することになる
現状では、２段階と３段階が５０％で混在？を考えているが、問題なければ２段となる。
直接転送に関しては、上記のような特定される問題を無くせる(あいまいにできる)のであれば採用予定。

上記の判断は一般の中継者に関する判断材料であり、専門の追跡調査では匿名性は低くなるのは明白とする。

>>277
現状ではオープンソースで開発することを前提としてます。
オープンソースに置ける部分的に実現が困難な部分があれば指摘よろしく
そういった点に関しては、私なりの解釈を説明します。
オープンでは論理的に実現不可であれば、開発者を匿名としてのクローズドも考慮します

>>278
現在の設計方針ではご指摘の２点の併用。
匿名性の証明が可能であればそれは採用。
証明が不可能であれば、おそらく追跡調査されにくい仕様を検討。
ただ後者の場合は、実際に配布されない可能性もある。
４７氏のことは尊敬しておりますが、さすがに私は臆病者なので・・・

>>281
それこそオープンソースの利点なのでは？
スキルがあるなら試作して公開してくれ。ブツが無いと始まらなと思う。。

>>275
私的な解釈では、Ｐ２Ｐとはいえ最初の行為が無ければ何もおきない。
新規にスレを立てることが「設置」
発言を編集したりスレが消せる(ファイル削除？)ならそれが「運営」「管理」
と捕らえています。スレをネットワーク上で動的に存在させる場合は、
発言方法などの実現に問題があります。

特定のノードがスレ管理者にならずに動的に掲示板を運営する方法があれば
その方法の説明など(参考ＨＰでもＯＫ)を希望します

>>283
(完全な)P2Pの掲示板ならスレは消せないよ。nyのファイルも消せないでしょう。
不完全なP2Pの掲示板ならnyみたいなのが一例では。

>>282
同感。まずは私も作ってみないことには。
その前にまず仕様書を書きたい、固めたい。
(実装はじめると色々と文句いわれそうなので)
まとめサイトの WiKi にでも書かせてもらうかもしれない。

スキルは持っているつもり。私が作るかどうかはともかく、
仕様だけはまとめたいと思う。協力よろしく
その場合は WideStudio と SDLPerl をあわせて Perl で開発する予定。
その他 OpenSSL も併用する可能性があるので、Cygwin / UNIX が
必須になる可能性大。言語選択に関しては突っ込みやめてね。
他の言語やりたいなら、おなじプロトコルの別実装として開発してほしい。

最後にここで名言しておくが、これまで発言内容は研究開発目的の
仕様作成であり、不法、違法を助長させるものは、作りたくはない。
企業などのデータ管理（データ分散による障害対策や操作権限管理に
流用の可能性）を追求したい。ファイル共有に関して困ってるもので・・・
いまさらという気もしますが一応、そちらが本心なので、ご理解を。

>>284
私は、(完全な)P2Pの掲示板の実現は「実装上、現実的に」不可能と判断している。
おそらく４７氏も同様の理由で、「不完全なP2Pの掲示板」をｎｙに実装したと予想。

P2Pネットワーク上に流動的なスレ本体にどのように安定した投稿を行うかという点が
一番の問題点だと思っている。（こちらも実現方法など参考情報があれば詳細希望）
おそらく分散されているスレ管理ファイルの同期も同じく解決するべき問題点である。

>まとめサイト管理人様
色々と議論や提案をしてきましたが、とりあえず仕様をまとめて
書きたいのですが WiKi を使わせて頂いてよろしいでしょうか？
後この手の議論に参加していただける方の協力が必要です。
ぜひご助力をお願いします。
提案、疑問、質問、突っ込み、誤字指摘いずれも歓迎

>>286
漏れはそんなに難しいことじゃないと思うよ。
やろうと思えば今のnyでもできる。時間とレスを書いたテキストにスレの名前
を付けて流して、それを落して時系列でマージすれば2chみたいなスレになる。
この機能を実装すればいい。

>>288
完全なP2P掲示板に関しては、参照用のレス番号の整合性とか
分散されている複数のスレファイルに「積極的に」同期をとるかの
部分に不安点を持っているだけ。
完全なP2P掲示板の不完全(同期が無保証)な実装は可能となります。

少しぐらい整合性が崩れても、一部の人にある発言がまわらないと
してもそれは「仕様です」とするなら設計、実装は可能ですね。

>>289
同期はタイムラグさえ気にしなければ取れるでしょう。というかP2Pで実況み
たいなのは回線が超高速にでもならない限り無理。でもそんなのチャットでや
ればいいと思うし。というわけで実装よろしく(w

オープンソースの場合問題になるのは、ＤＬ数の制限と、中継者には自分が
転送しているものの中身がわからないことを保証する仕組みをどう実現するか、
が大きなポイントだと思います。


> 現状では、２段階と３段階が５０％で混在？を考えているが

中継者はどのように決定しますか？


あと、放流者は完全な状態のデータを持っていることになるわけですが、
それが誰にもわからないことを保証するための仕組みは？

>>291
> オープンソースの場合問題になるのは、
> ＤＬ数の制限

オープンソースでこれは無理でしょう。当然DOMり放題になる。

> 中継者には自分が転送しているものの中身がわからないことを保証する仕組み

暗号化とかnyみたいに表示されないようにするとかじゃないかな。

> 中継者はどのように決定しますか？
> あと、放流者は完全な状態のデータを持っていることになるわけですが、それ
> が誰にもわからないことを保証するための仕組みは？

さんざんｶﾞｲｼｭﾂだと思うよ。ログとかWikiとか見たら？

>>291
オープンソースにおける問題点の突っ込み感謝。

DL数制限に関して
これに関して、up0やＤＬ厨がネットワーク構築上の問題というのであれば、
強制 up をさせるという仕様を検討中です。いわゆる交換アルゴリズム。
もらうファイルの中身の捏造対策は別の議論としてここでは省略しますが、
１００ＭのファイルをＤＬしたい人は、交換最大比率４：１であれば、
最低２５Ｍ以上の何かをＵＰしなくてはいけない仕様。
転送においても同様の仕様とすることで、キャッシュの拡散を計る。
交換するファイル指定に関しても別に議論しますのでここでは省略。
最初の交換するデータが無い状態では、適当なノードとノードのキャッシュを
交換させるだけの転送（蓄積転送と命名）を行い、最小限のキャッシュを確保する

・ＵＰしない人には、ＤＬさせない

>>292
> > あと、放流者は完全な状態のデータを持っていることになるわけですが、それ
> > が誰にもわからないことを保証するための仕組みは？
>
> さんざんｶﾞｲｼｭﾂだと思うよ。ログとかWikiとか見たら？

　Wiki に上がってるやつは把握してますが、偶然にも放流主が特定されることが
ないような決定版ってもうあるんでしたっけ？
　それに、HgNt3XJQ 氏はご自分で現実的と思える手法を組み合わせて１つの
具体例を作ろうとしているようなので、どういった方式を採用するのかに興味が
あるわけです。

>>291 >>292

・中継者の決定に関して
中継者はく転送でキャッシュ拡散に協力してくれそうなノードにお願いする
という身も蓋もない（決定アルゴリズムは別途議論）仕組みになります。

・中継者に対する隠蔽
私が書いた >>271 の内容に関する回答や調査によって変わりますが、
先の >>293 にも書いた中継者もキャッシュが無いといけないため、
積極的にキャッシュを持たせ無ければならない仕組みで対処できるとしています。

後者は説明の日本語が変ですね。あとで整理して再度詳細説明します

よし、ガンバってるてめーらに俺さまの案をプレゼントだ
名付けて全国行脚システム

まずUPするヤツは包んでそこいらじゅうに配れ。
配送先を選ぶな。配れ。
紙貼り付けて「100000個複製して行脚して配らないとヤベーぞ」とでも書いておけ。
ついでに辞世の句も書いてつけとけ。それがIDだ
受け取ったやつはコピれ。そして行脚だ。全国くまなく行脚しろ
交通手段は足だ。車？電車？バカにしてんのかてめぇ歩け！ていうかメロスのように走れ！
考えるな。喋るな。アホみたいに行脚して適当に配れ。
無償で全国行脚してたらストレスもたまるだろう。
だが安心しろ。全国行脚システムはDOMをも利用するからな
DOM見つけたら狩れ。己の怒りをブチまけろ！老若男女区別するな狩れ！

どーよ完璧だろーが。これぐらい思いつけよてめーら

>>293
> ・ＵＰしない人には、ＤＬさせない

そうするとソースはオープンにできない？

あと強制的にUPさせるってのは本当に必要なのかと思う。nyでもキャッシュ
即消しできるし、洋物ソフトはDOMれるのが多いけど普通に落ちてくる。

>>291
ばらばらにレスわかりづらいならゴメンと先に謝っておく。

> あと、放流者は完全な状態のデータを持っていることになるわけですが、
> それが誰にもわからないことを保証するための仕組みは？

えっと、私が >>274 に書いたように完全データを持っていることを公開する
ことはＮＧ扱いにして、部分データをＯＫ(とりあえず合法と仮定)という前提
があります。

私が>>265 で述べているように、WiKi にある「変形RAID5」方式で完全体から
３つのファイルを作成して、これを拡散させる形を検討中。
拡散アルゴリズムと、最初の匿名性の確保については別途議論します

いつの間にか一人称が俺から私に・・・、どうも議論に白熱すると素がでます（ｗ

>>293 >>297

DLしたキャッシュの扱いがやはり問題の焦点になると思います。

>> ・ＵＰしない人には、ＤＬさせない
>そうするとソースはオープンにできない？

オープンソースにする為に思いついた仕組みが今回の「交換アルゴリズム」です

>あと強制的にUPさせるってのは本当に必要なのかと思う。nyでもキャッシュ
>即消しできるし、洋物ソフトはDOMれるのが多いけど普通に落ちてくる。

今回私が提案するのはUP者に対して「DL対象になりうるキャッシュ」が必要な
わけで、これが無ければUP者はコネクションを拒否、切断してしまう事を検討。

・キャッシュ拡散に貢献しないノードは、DLができないようなアルゴリズムを採用
・最初の交換するキャッシュが無いノードは >>293 で上げた蓄積転送でキャッシュを
　確保することで、本来欲しいファイルをDLできるようになります

Linny開発プロジェクト
http://pc.2ch.net/test/read.cgi/linux/1053087824/

882 名前：47 ◆KbtLZwerNc [sage] 投稿日：03/06/19 08:50 ID:AhStOI42
Winny作者ですが

あれがクローズドシステムになっているのは、好きでそうしているわけではなく、
こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。

その際には現在のWinnyとの互換性はなくなると思いますが。

今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで、
オープンシステム化かもしくは別の方法による大規模化は避けて通れないでしょう。

とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。
だめならソース非公開なままでUNIX版を作るという手もありですが、こちらの時間的余裕の問題で
オープンにできないのであればUNIX版ができることは無いと思います。

>>299

どんなアルゴリズムを作ろうが書き替えられたら終わりだって。「DL対象にな
りうるキャッシュ」が無いにもかからわらず有るように見せかければいいわけ
だし。

「ＵＰしない人には、ＤＬさせない」というのは必須なのかという疑問はある。
必須なら closed にするしかない。

# 誰かnyのクローンでもいいから実装してくれないものか。。

>>294
>　Wiki に上がってるやつは把握してますが、偶然にも放流主が特定されることが
> ないような決定版ってもうあるんでしたっけ？
>　それに、HgNt3XJQ 氏はご自分で現実的と思える手法を組み合わせて１つの
> 具体例を作ろうとしているようなので、どういった方式を採用するのかに興味が
> あるわけです。

興味もってくれてありがとう。

決定版に関しては、まだ私も模索中です。
今のところ放流主を特定されない方法に関しては、理論的に証明していませんが、
候補はあります。条件や追跡などの手法を含めて、結構ややこしい議論になるので
私の提案を一度どこかに発表して、そこから議論しましょう。

なんか別途議論するべき検討内容がいっぱいあります。
すでに解決済みの事項や参考情報があれば、まとめる必要がありますね。
まとめサイトさん、ご協力よろしく

>>300
その内容は以前読んだ覚えがあります。

今回の議論が、最終的に Winny に帰結する（その場合は４７氏の設計はベターであった）のか
あるいは、オープンソースで解決法が見つけられるのかが最大の挑戦になります。
私的には、先にあげた「交換アルゴリズム」（DOM対策）やその他のアイデアで「実現可能」と
証明し、ついでに実装まで行えたら最高ですけれど、どうなることやら・・・

>>301
この点は私の説明不足もあると思いますが、DOM対策は理論上可能と判断しています。
UPする方に偽造、捏造を見抜くアルゴリズムがあれば、コネクションの拒否、切断が可能になります。
この点は、DLしているファイルが無効なものでないことを保証する何かを組み込むことになります。
この保証は、ひとつのノードでは偽装する（捏造ファイルの作成のこと）ことが不可能であれば成立します

>>304
> >>301
> DOM対策は理論上可能と判断しています。UPする方に偽造、捏造を見抜くア
> ルゴリズムがあれば、コネクションの拒否、切断が可能になります。

見抜けないアルゴリズムを実装しちゃえばどうなる？

> この点は、DLしているファイルが無効なものでないことを保証する何かを組
> み込むことになります。この保証は、ひとつのノードでは偽装する（捏造ファ
> イルの作成のこと）ことが不可能であれば成立します

その保証を欺くアルゴリズムを実装しちゃえば？

不毛なクラック合戦にしからならないよ。

今回私の提案で、部分キャッシュ保持だけなら合法という前提を置いていますが、
これに関して法的にどうなのか、あるいはどうすれば合法であるのかの結論が
開発する上で必須となります。（判例がないというのは公開NG条件かも）

次期P2Pのクリアすべき課題を法的な観点から考察スレ住人、また法律に詳しい方は
この点に関する回答をまとめていただけると幸いです。

補足ですが、私の提案には以前４７氏が公式HPで提案されていたコンテンツ課金の
仕組みも同時に含まれています。先にあげた共有ファイルのアクセス権限に関する
事項と関連付けられるものですが、仕様だけが頭でっかちになってるかもしれません。
興味ある方は一緒に議論などお願いします。（当時のスレは一通り目は通してあります）

＞不毛なクラック合戦

これはソフトウェア作るなら避けて通れない問題だね。どんなソフトでもそうだ。
避けられないならクラックをするメリットを最小に抑える仕組みを作るしかない。
クラック版と正式版で性能に差異があまりでなければ、みんな正式版を使うだろうし。

>>305
この点に関してはイタチごっこという理論は私も同感ですが、
十分議論していく必要がありそうです。（元からそのつもりですが）

まあ、現実的な回答としては、WiKi にもある通り、信用情報方式
のようなノード評価が必要になるかもしれません。
このアルゴリズムに関しても検討中なので、併せて議論していきたい
ところです。

この点を含めて、「解決しなければならない問題点」が他にあれば
ピックアップよろしくお願いします。

>>305 >>307
突っ込みありがとう。

>>308 では抜けてしまいましたが、ご指摘の通り「クラックをするメリットを最小に抑える
仕組み」が現実的な回答になると思われます。
こちらは、その都度との時に応じた効果的な仕組みに対応するという状況になりますね。
というわけで、この点の議論は専用に行った方がいいようです。

アイデア持ってる人は提案などよろしく。（既出の項目もまとめておきましょう）

> ご指摘の通り「クラックをするメリットを最小に抑える
> 仕組み」が現実的な回答になると思われます。

そういう仕組みが作れないんだって。オープンでは。
だから「ＵＰしない人には、ＤＬさせない」というのが必要条件ならクローズドにするしかない。

>>309
一つ質問よろ
RAID5案使う様だけど、冗長化考えてる？

>>310
そんな突っ込みはHgNt3XJQの提案読んでからでいいじゃん

>>311
> そんな突っ込みはHgNt3XJQの提案読んでからでいいじゃん

提案読んでから突っ込んでいるわけだが。そのそもそれは「ＵＰしない人には、
ＤＬさせない」というのが必要条件ならクローズドしたら？という提案でもあ
る。

クラック版を使う理由っていったら
・ﾀｲｰﾎされたくない（DOMなら安全）
・効率よくファイルを落としたい
これくらいでしょ。
特に1番目の理由でクラック版を使うと思うので、理論的に
ユーザの匿名性を証明できたならクラック版は使われないでしょ。
（次の逮捕が出るまでは・・・）

>>313
何か意味不明。ユーザの匿名性を証明とクラック版とどういう関係があるんだ？
(そもそもオープンソースならクラックというのもおかしな話だな。別バージョ
ンとか言うのなら分かるが。)強制的にUPさせられるのとそうでないのとでは
どちらを使うかという単純なこと。

>>314
確かに「オープンソースであること」と「強制アップロード」の両立は言う通り無茶です。
ただ、それを何としても実現しないとうまくいかないのは目に見えているのです。

クローズの Winny でもクラック版がでている通りいずれは解析されるでしょうし、
必要に応じて専門家も解析に参加することも考えられます。

もしアップロード帯域を提供しない人が増えれば
一部の人 (特にファイルを放流するなど貢献している人) に負担が集中したり、
全体的にダウンロードができずに成り立たなくなります。
ISP に目をつけられる人は主にアップロード帯域を提供している人です。

とにかく、実現させなければならないと思います。

>>314
何割が公式版ではなく別バージョン版を使うと想定しているの？
５割とかはありえないよ。せいぜい１，２割がいいとこ。
大多数の一般ユーザは公式版を落とすんだから気にしなくていいんじゃない？
ｎｙのクラック版だって大して広まってないし。クラック版使うコアユーザなんて無視できる。

>>316
> 何割が公式版ではなく別バージョン版を使うと想定しているの？

オープンソースだったらどれが公式版でどれがそうでないかを誰が決めるわけ？
仮に初めに作られたものを公式だと主張しても使いにくかったら公式かそうで
ないかなんて意味はない。

> ５割とかはありえないよ。せいぜい１，２割がいいとこ。
> 大多数の一般ユーザは公式版を落とすんだから気にしなくていいんじゃない？
> ｎｙのクラック版だって大して広まってないし。クラック版使うコアユーザなんて無視できる。

クローズドソースならクラックしにくくて広まりにくいからそういうこともあ
るかも知れない。オープンソースならそういうことはない。DOMし放題なバー
ジョンが普通にwebに置いてあったらどっちを選ぶ？

>>315
> 確かに「オープンソースであること」と「強制アップロード」の両立は言う通り無茶です。
> ただ、それを何としても実現しないとうまくいかないのは目に見えているのです。

これは思い込みだと思うけど。個人的に。

WinnyTipsページみたいなのを作る。そこを公式ページとする。そこで導入法とか色々説明。
別バージョン版へのリンクは貼らない。大多数は公式ページから落とす。
DOM版は堂々とサイトを宣伝できない。どうせこっそり公開でしょ。
Tipsページみたいに１日１０万アクセスあるようになれば問題ないと思うけどね。

>>319

何か変に「公式」にこだわるね。使う方だってそんなに馬鹿じゃないぞ。君だっ
て自由に選べるならDOMし放題なバージョンを使うだろう？使わないか、
「公式」じゃないんだから。

# ていうかnyでもDOMなんて簡単だろう。。

>>319
> DOM版は堂々とサイトを宣伝できない。どうせこっそり公開でしょ。

それからここが分からない。より使いやすいバージョンがあるのになぜ「こっ
そり」なのか。なぜより使いやすいバージョンが非公式だと決めつける？
割れか何かと勘違いしてないか？

# 要するに「オープンソースであること」と「強制アップロード」の両立は無理っ
# てこと。

>>320
そこで、「アップロードしないノード」との接続を切る機能をつけます。

アップロードしないノードが増えるとダウンロードできなくなるわけだから、
その機能はあっても使う人は使うでしょう。

ずるをするノードは絶対にいるので、それを前提に考えます。
他のノードがずるをすれば自分のノードは不利益を被るので
他のノードのずるを検出する機能があるほうを選ぶでしょう。

>>318
「オープンソースでなきゃいけない」は言い過ぎた。
ただ、クローズであることを根拠にしたシステムでは
解析されたら弱点をつかれることになります。
クローズでもいいけど、解析されてもいいようにする必要があります。

（特に暗号関連はクローズであることを根拠にしたものは信用されません。）

>>t6XRf4Kk
クローズで決定しているみたいですから、それで考えていけばいいでしょう。

一方、オープンでやっていこうと考えている人達もいます。
スレッドを分けて見てはどうでしょう？

移転先候補

ttp://s2net.s41.xrea.com/x/p2p/

（匿名性は 2ch と同程度か以下。）

>>322
> そこで、「アップロードしないノード」との接続を切る機能をつけます。

そんなものはできない。IP変わったら終わりだし。そもそも「アップロードし
ないノード」を特定しようがない。知り合い同士でftpでもするしかないね。

つーか「ＵＰしない人には、ＤＬさせない」のが大前提なのはどうして？これ
はタブーな質問なのか？Gnutellaとか普通に落せるぞ。(nyでもDOMれるぞ)

>>321
DOM版を大々的に宣伝したらネットワークそのものが崩壊するから本末転倒なんだよ。
こっそり公開しなきゃうまみがでてこないだろ。

>>324
さっきから強制アップロードに拘ってるけど、あくまでひとつの案だよ。べつに前提じゃないよ。

>>323
> クローズで決定しているみたい

気のせいでしょう。ていうか誰が決定するんだろう。ていうか仕様なんか統一
できるんだろうか。ていうかそんな必要あるんだろうか？ていうか作る人がい
ないと話しにならないよね。ていうか(ry

>>324
ny で DOM れるのは比較的正規番を使っている人が多いからで、
日曜はクラック版ユーザーが多くてなかなか落ちてこないことが報告されているよ。

あとは、できないできない、って言うなら理由を説明してほしいです。
開発が進みません。

クローズしかないと言うならクローズの人同士で開発していて欲しいです。
あなたの中では「オープンは無理」だと結論が出ている以上、私たちに関る理由は無いはずです。

>>327

># 要するに「オープンソースであること」と「強制アップロード」の両立は無理っ
># てこと。

って思っているなら、「オープンで何とかする」って人と話が合わないのは
当たり前です。
あなたは 「オープンで何とかする」って人達を無視して自分の案を出せばいいではないですか。

>>328
あの、、何か猛烈に勘違いしてると思われ。

nyはキャッシュ即消ししたり、UPが始まったらぶちぶち接続を切ってDOMれる。

> あとは、できないできない、って言うなら理由を説明してほしいです。
> 開発が進みません。

>>305 以下関連レス参照

> クローズしかないと言うならクローズの人同士で開発していて欲しいです。
> あなたの中では「オープンは無理」だと結論が出ている以上、私たちに関る理由は無いはずです。

そんなこと一言も言ってないんだけど。「オープンソースであること」と「強
制アップロード」の両立は無理ってことを言ってるわけ。

>>327
「t6XRf4Kk 殿の考えではクローズで決定しているみたい」 と
言おうとしたものです。
言葉たらず、すまん。

>>329
> って思っているなら、「オープンで何とかする」って人と話が合わないのは
> 当たり前です。

??? なぜ？

「オープンソース」なら「強制アップロード」できない。
「強制アップロード」が大前提なら「クローズド」にするしかない。

ということ。別にどちらにしろ何て言ってないよ。

仕様を話し合うのにオープンも糞もねーだろ！ スレ違いは消えろ

>>332
オープンソースなら強制アップロードできないっていうのはなぜ？
ハッキングバージョンの作成はやりやすくなるだろうけど、周りの優先度評価システムなどによって、システム全体に対する貢献のないノードを排除することはできるのでは？

>>333
オープンかどうかも重要な仕様になるはず。
winnyの場合、47という個人に極端に頼ったために、家宅捜索で終わりということになる。
オープンならばそれは防げるけれど、ハッキングバージョンが広く出回る危険性もある。
どちらの開発手法を取るか、しっかり考えておかないと、まずいよ。

>>333
めちゃめちゃ関係あるよ
オープンでも大丈夫な仕様が次世代P2Pには必須だろ

>>334
> ハッキングバージョンの作成はやりやすくなるだろうけど、周りの優先度評価システムなどによって、システム全体に対する貢献のないノードを排除することはできるのでは？

IPが固定ならそういうシステムはできるだろう。でもIPが変わったらお仕舞い。

>>334
どんな情報を使って貢献度を評価するのかソースを見れば分かるし、
そうなったらその情報を偽装することも出来ちゃうからね。

本当にセキュアな仕組みは、ソースがオープンかクローズドか、に依らずセキュアなわけだが。
せっかくだから志は高く持とうって。

一部だけ非公開にすりゃいいじゃん

強制アップロードにすると単純に捏造やゴミが増えるだけだと思わない？

４時間ほどで議論いろいろされてみたいですけど、
やはり「オープンソース」と「非純正クライアント」、
「強制アップロード方式の実現可能性と否定」の
議論に収束してますね。

t6XRf4Kk は最初から否定的な立場からの突っ込みばかり
されてますが、それで結論としてしまうと、製作不可能と
なってしまうので、それを回避するべく議論したいと思います。

私はあくまで「オープンソース」で「実現可能」な「合法である」
「ファイル共有システム」の可能性を考えたいと思います。

>>339
私も同感です。
UNIXでのパスワード管理も「一方向性関数」のおかげで堅牢にできている
わけですし、OpenSSLもソースコード公開されているけれどセキュアな環境を
提供できているわけです。

私は議論屋且理論家なので、あくまで「オープンソース」でありたいと思います。

>>337 >>338 >>341
否定的な意見もあると思いますが、
あまりにも一笑に付されるとこちらも
やる気がなくなっちゃうので、あくまで
一緒に議論して考えていくという方向で
お願いします。

すくなくとも私のスタンスとしては次の通りです。

・ オープンソースの場合の非純正(プロトコル仕様に準拠しないクライアント)は存在する
・ クローズドにしたから安全とは限らない （どうせ解析されるならはじめから公開する）
・ 〜〜すれば、不正は可能 ⇒ 純正仕様の元では不正することのメリットを減らす方向で

>>341
漏れもそう思う。

>>299の主張は、「交換アルゴリズム」という命名からして
直接通信しているピア同士で必ず相互送受信を行わせる
という意味合いだと思うが、捏造パケットを送るのはそんな難しい事じゃないしね。

とまれ、着眼点は悪くないと思うよ。実装時にどんな挙動が起きるか
がんがって脳内シムレーションしてくれ。

朝鮮人のすくつですかここは

>>342
なぜ製作不可能となる？「オープンソース」なら「強制アップロード」なしで、
「強制アップロード」が必要なら「クローズド」にすればいいと死ぬほど繰り
返して言っている。全然不可能じゃない。「オープンソース」で「強制アップ
ロード」を実装するほうがよほど非現実的。それから「ＵＰしない人には、Ｄ
Ｌさせない」のを勝手に前提しないでくれ。

> 私はあくまで「オープンソース」で「実現可能」な「合法である」

他人の著作権を侵害して他人に損害を与えているなら、「合法である」なんて
今の著作権法がある限り端的に言ってしまえばありえない。それでも「合法で
ある」と言い張るなら、それは単に法の不整備を指摘したに過ぎない。中継は
今はグレーだがクロに今後十分なり得るし、Downも同様。「合法である」のと
法の網の目をかいくぐって「今のところは合法」とは訳が違う。

>>344
暫定でいいから仕様まとめてくれよ

>>345
なるほど、、、
外から見ればUP者もDL者に見えちゃうって事か。
キャッシュの自律ミラーリングと混ぜると面白いかも。

オープンソースである以上、不良ピア（意図しない挙動をするピア）の内在は
前提とすべきである、という点だけ同意＞t6XRf4Kk

不良ピアが不当な利益を得ることでネットワークが崩壊する危険があるというのは、
ファイル共有システム利用者が著作権侵害することによって著作権ビジネスが崩壊する危険がある
という状況に符合して何とも皮肉が効いてるね。

歯止めの利かない「悪意」をどう食い止めるか、というのはシステムの仕様以上に
根深い問題かもしれないねぇ。

http://pc2.2ch.net/test/read.cgi/tech/1069630990/791
> From: [791] デフォルトの名無しさん <>
> Date: 03/12/09 13:08
>
> 次期P2Pの仕様 part7
> http://tmp2.2ch.net/test/read.cgi/download/1070647427/
>
> まとめサイト（Wikiへの直リンク禁止）
> 　http://s2net.s41.xrea.com/
>
> ダウソの馬鹿どもがなんかやってるぞ、からかってやろうぜ！
ム板から来ますた。ま、それは置いておいて。

「次期 P2P の仕様」ってスレタイはどうかと思うよ。
「次期 P2P ファイル交換アプリケーションの仕様」だろ？
P2P = (違法な)ファイル交換ソフト
じゃないから、それはキチンと分かって欲しいやね。
まだ P2P 自体が使い道を模索してる段階なんだから、
変に誤解されたくない。

朝鮮人に何を言っても無駄。

人が作り出した著作権、それを破壊するP2Pファイル交換、それを破壊するクラック版、
それを破壊する・・！？

大体グレーゾーンなんてセコイことやってるから家宅捜索されるんだよ。
作ることが知れただけで逮捕されるような凶悪な仕様にしよーぜ！

例えば起動してるとACCSにF5攻撃するようなヤツ。

面白くない

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 ,,,,,,,,,　　　
　　　 ＿　　　iiiiii、　　　　　　　 ,,,,,iiiiiiiiiiiiiiiiii,,　　　　　.,,,,,,, 　 　 　 　 _,ll!ﾞﾞﾞ!lli,　　　
　　　lllllll　　 .llllll″　　　　　　　 ﾞ!!!!!!ﾞllllllll!!ﾞ°　　　　lllllll’ lllllllllllllllllllllll!liiiiill!′　
　　　'llllll,,,,iiiiillllllllllliiiiii,,,,　　　　　　 .,,,illll!lﾞ′　　　　　.llllll′.￣￣ .llllll　　　　　　　
　　　.llllllllll!!ﾞllllllﾞﾞ~ﾞﾞﾞ!lllllli,、　　　　,,illlllllliiiiiii,,,,,,、　　　.llllll: : :iiiiiiiiiiiiiillllllillllllllll　　　　
　　.,illlllllllli, ,lllll!′　　ﾞllllll　　　.,,iillllll!!!ﾞﾞﾞﾞﾞﾞﾞ!!lllllii,　　　llllll　 .ﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞllllllﾞ”￣｀　　　
　 .,llllll’ﾞlllllllllllﾞ: ,,,,,,,,,,,,,llllll　　,,illlll!lﾞ,,,,,,,,,,,、　 ﾞlllllli､　　lllll|　　 ,,,,,,,,,,,,lllll|　　　　　　
　 .llllll　.,,llllllllirillll!!!!!!llllllll,,　 .ﾞﾞ!ﾞ".illll!lﾞ!llllli,　 .,llllll　　 lllllli､　,illll!!!!!!lllllllllliii,,,、　　　
　 .'!llllliilllll!ﾞﾞﾞﾞ｀!lllliiiiiilllll!!lll!"　　　.ﾞllllii,,,,,llllll,,iilllll!°　 .llllll、 .lllllli,,,,,iillllllﾞﾞﾞ!!lll!″　　
　　 .ﾞﾞﾞﾞﾞ″　　 .ﾞﾞﾞﾞﾞﾞﾞﾞ″ ｀　　　　 .ﾞﾞﾞ!!!!!!!!!!!!lﾞﾞ゜　　　 ﾞﾞﾞﾞ° .ﾞﾞﾞ!!!!!!!ﾞﾞ’　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

こんにちわ、お巡りさんですよ。
カニ味噌ですね。

>>347
・クローズにしても、そのうち解析される。
・なんとかしてアップロードに貢献してもらわないと
　一部に負荷が集中したり、ダウンロードに支障をきたす。

ダウンロードの影にはアップロードあり。
アップロードが不足していて、Winny の場合現状、光層が ADSL 層をまかなっている。

Winny の問題点を克服したものを作ろうっていう流れの中で、
上記の二つを同時に満たしたものを考えようっていう話になっている訳です。

人を作り出した生命、それを育んだ地球、それを形成した宇宙、
それを支配する・・・物理法則。

p2pは物理法則に則った必然だったのだな。

DL側に転送する段階で、DL先から適当（無作為）にDLしようと試みる。
何か落とせたらファイルを転送、落とせなかったら不正ノードとみなして切断。

こうすればUp0版を排除できると思う。
もちろん無作為にDLするのは一時キャッシュの奴でもOk。

これならオープンにしても強制アップロードと同義にならないか？

>>359
ダミーファイルUPされて(以下略
もちっと考えてから書いてくれ。

winnyの転送量でさえネットワークトラフィックの危機だったのに、
それを更に増やそうというのか。



　馬　鹿　ば　っ　か　だ　な




　

HgNt3XJQ氏へ

とりあえず暫定でいいので仕様作って Wiki に専用のページ立ち上げて、
みんなでねちねち改良していきません？

「クラックされたら終わり」とか「オープンと強制ＵＰの両立不可」という主張に
対しては、考えられるクラックの内容を列挙して、１つ１つ対策を検討しましょう。

t6XRf4Kk は、「できるはずがない」と決め付けるんではなくて「どういうクラック版を
作られたら崩壊するのか」を具体的に指摘する役に回ってくれ。もしそのおかげで
皆が納得する形で論理的に「オープンでは成立しない」という結論に達したら、
t6XRf4Kk が望む通り、今後開発リソースはクローズド版を開発する方向に
注がれるでしょう。

いまはまだ、オープンで行けるという可能性を捨てていない開発者は多いと思います。
開発力をクローズの方向に向けさせたいなら、「だめに決まってる」と主張するだけ
ではダメです。すべての可能性を１つ１つ否定してやらないと彼等は納得しませんよ。

こんな自分が言うのもなんだが
>>359
なかなか良い案だと思う。

その他に、
Winny のようにころころ接続を変えるのではなく
当分接続が変わらないことを前提に、
後から接続したノードは、１５分ほど経ってからでないと
ダウンロードできないようにする案もある。
隣接ノードは、新米ノードにデータのアップロードをしないし、
新米ノードのリクエストを破棄する仕組みにする。

（ダウンロード要求はバケツリレー式に伝わる方式だとしたらの話ね。
　バケツリレー式でも該当ノードに効率良く届く方式を見つけた。）

後、ダウンロード側がごまかすことも考えられるから、
（ >>360 殿の示した例のように ）
第三者ノードの存在が必要だと思う。

オープンでクラックされない仕組みが作れないっていうのなら、
既存の SSL のような類いは全部アンセキュアじゃねーか。
頭悪い香具師は初級ネット板にでも行ってくれよ。

で、スレタイについては誰も触れてくれないけど既出なんか？
それとも興味無いから放置？

>>360
これはオープンでもクローズドでも問題だな。

ひとつ気になったのだが
『警察の追跡を・・・』などという発言はすでに次期P2Pファイル交換ソフトを
著作権侵害目的に使うような表現に聞こえる。
ここでいう匿名性はあくまでその人が他人に何のファイルを共有しているのか
分からないようにする、つまりプライバシーの厳重保護を目的とするべきだと思う。
ほとんどの人は分かっているようだが、一部の人は分かっていないようだ。

俺が言いたいのは後々にこういう発言を指摘されたら『著作権侵害目的じゃない』
と言えなくなるのではないか？ということ。
もっと発言に気を使うべきだと思う。

ごめん唐突だった。
＞366は今まで読んでて思ったことです。

第三者ノードについて、
グルになってごまかす手口も考えられるので、
その対策も必要があるのが課題。

>>350
実はスレタイについてはあまり気にしてなかったです。
言われて見れば確かに問題はあると思う。

一番悲惨なのは、悪意のある作者がクローズドで開発した場合

　　　　　　　　　　　　　,ィ⊃　　, -- ､
　 　 ,r─-､ 　 　 　,. ' ／ 　　,/ 　 　 }
　 　{ 　 　　ヽ 　／ ∠ ､＿__/　　　　|
　 　ヽ.　 　 　 V-─- 、 　, ',_ヽ / 　,'
　 　 　ヽ 　ヾ､　　',ﾆ､ ヽ_/ ｒｭ､ ﾞ､　/
　　　　　＼　 l　　ﾄこ,! 　　{`-'} 　Y
　 　　　　　ヽj 　　'ー'' ⊆) '⌒｀ 　! 　　　　　／￣￣￣￣￣￣￣￣
　 　 　 　　　l 　 　　ﾍ‐--‐ｹ　　　}　　　　.＜ 漏れが作ってやるyo!!
　 　 　 　　　ヽ. 　 　　ﾞ<‐y′ 　 / 　　　　　 ＼_________________________
　 　 　 (ヽ､＿_,.ゝ､＿ 　~ 　___,ノ ,-､
　 　 　　） 　 　 　 　 　　ﾉ/｀'ー-'　<
　　　　ｒ'／, 　　_..　　　//　　ｌ、、､ヽ_)
　 　 　 ゝ(_/_ﾉ´ /ヽ_ノ/　　__,ｌ ヽ)_)‐'
　　　　　　　　　{｀ ｰﾆ[二]‐ｸ′
　 　 　 　　　　　〉 　　/ 　/＿
　 　　　　　　　/ 　　´￣｀ヽ 　）
　 　 　 　 　　（＿＿＿＿ノ--'

ドロシーのアイコンってどこにあるの？

　　　／⌒ヽ
　　/　´_ゝ`） すいません、ちょっと通りますよ・・・
　　|　 　　/　
　　| /|　|
　 //　| |
　Ｕ　 .Ｕ

>360
ダミーファイルを無視リストみたいに登録できるようにするとかは？

>368
第三者ノードって意図した通りに出来るものなの？

>>373
> ダミーファイルを無視リストみたいに登録できるようにするとかは？

オープンソースなので、それこそ毎回乱数で生成したデータをＵＰするような
クラックも可能（クローズでも外部ツールで可能かも知れないが）

ともかく、根本的な解決にならない。


> 第三者ノードって意図した通りに出来るものなの？

368 は可能性について言ってるだけ。具体的な仕様が決まっていない
現段階ではまだ何ともいえない。

どちらにせよULに帯域を使うからクラックのメリットは半減じゃない？
もう少しひねったのを思いついたけど、もうちょい練ってから書き込みます。

ダミーファイルで思いついた。
ハッシュやファイルサイズといったファイル識別データはまったく同じに偽って、
中身はでたらめな偽ファイルをばら撒くと…
一部分でもそれをDLした所では破損ファイルになって…

これが蔓延したらどんなネットワークでも崩壊するね。

>>375
> ハッシュやファイルサイズといったファイル識別データはまったく同じに偽って、
> 中身はでたらめな偽ファイルをばら撒くと…
> 一部分でもそれをDLした所では破損ファイルになって…

それは大丈夫。Winny でもブロックごとにハッシュチェックしていた。

提案されてる方式の中にも、実際の内容のダウンロードの前にブロックハッシュ
リストをダウンロードする形式のものがある。これなら原理上、１ブロック程度の
無駄で抑えられる。

当然、リスト自体のハッシュもチェックされる。ハッシュ指定でダウンする限り
妨害される心配はない。

>376
よかった。一安心。

一度Winnyでも同ハッシュ・同サイズ捏造問題があったよね
各ブロックを並び替えてxorするやつ
もう対策されたけど。

キャッシュバージョンが v5 になったときですね。

そういえば、Winny は現在も全体ハッシュ不整合エラーを狙える穴は
あいたまま。ブロックハッシュはチェックしてるけど、ブロックハッシュが
正しいかどうかはチェックしてないから、全体ハッシュが食い違ったら
全部捨てて最初からダウンし直す仕様。

これから作るなら、ハッシュテーブルは必須っすね。


関係ないですけど、これから作る共有ソフトでは可能なら全体ハッシュの
計算方法は統一したいですね。どのソフト使っても同じハッシュで
同じファイルが指定できるように。

ハッシュテーブルを別に持ってもそっちが狂ってたらどれを信じるのだろう

ハッシュテーブルのハッシュをファイルの全体ハッシュとして使う

>>364
頭悪い香具師のはお前だ。オープンかクローズドかに関してセキリティーの話
など出ていない。「オープンソース」でなおかつ「強制アップロード」を実装
できるのかということだ。

ネットワークを世界規模にする計画はどうなった？

どうにもこうにもまとまらんな

オープンソースかつアップロード確保は難しいよな。

受信者の現在のステータスを、送信元（中継者）が認証するという方法しかないか。
問題は認証の方法。
巧妙でソースを改変するとモロバレになるような方法じゃないとだめだから。

なんでこうも否定的で非生産的な人間が紛れ込むんだろ。

>>350
> 「次期 P2P ファイル交換アプリケーションの仕様」だろ？
違う。

ファイル交換に限った事ではない。
ここに居る人間の多数が違法ファイルを交換したいらしいが…
何もファイル交換に限ったP2Pの話をしている訳じゃない、

>>342-344
ノイズに惑わされ無い様に、気を付けて。

方法１
ダウンタスクが発生するたびに送信者（あるいは中継者）に実行ファイルのCRCもしくはMD5のハッシュ値を送りつける。当然暗号化する。
欠点・・・負荷がかかる。また、どの程度まで改変に耐えられるかわからない。

方法２
受信者のステータスを常に監視し、長時間アップ数が変動しない場合は切断
欠点・・・クラックに弱そう。

方法３　方法１の改良版
P2Pとは別に補助ソフトとして、P2Pの実行ファイルのCRCもしくはMD5のハッシュ値を計算してP2Pソフトに送信するソフトを作る。このソフトのソースは非公開とする。
欠点・・・負荷がかかりそう。

>>387
これはオープンソースでアップを確保するための案。

>>387
方法１：実行ファイルのハッシュ値は簡単に偽造できる
方法２：アップ数の変動も簡単に偽造可。
方法３：オープンソースのP2Pソフトに受信部分のソースが含まれているから
送信部分が非公開でも意味がない。

>>384
まとめる必要などないのだよ。まとめたとしてもそれに従う義理も保障もない
のだし。そもそもソースのひとかけらもない状態で素人考えを寄せ集めたとこ
ろで何の役にも立たない、絵に描いたモチそのもの。このスレはそれが目的だ
ろうが(w。nyは47氏が初めに作った点に既に仕様は出来上がっていた。ここで
ごちゃごちゃ言っているようなことは枝葉末節の問題に過ぎない。議論と称す
る一人ごとをここでウダウダ言うよりかはnyのクローンでもまず実装したほう
が100万倍現実的。いろんな仕様に基づいた実装があってよさそうなものが残
ればいいし、大体使ってみなけりゃ仕様が固まるわけがない。水に入らなけりゃ
泳ぎを覚えられるはずはない。実装できるスキルのあるやつにしてみれば屁に
もならないほど当たり前のことだと思うけど。つーかそういう奴はこんなスレ
見てるわけないね。

>>387
やっぱりだめか。

とりあえず、トリップ必須にして、
トリップごとにダウンさせるか、させないかを手動で決めるしかなさげ。
WinMXでいう、ホットリストと無視リストみたいな。

利用者はユーザ名とパスワードを指定し、パスワードから公開鍵＝トリップを作ると。
認証はﾌﾂｰにできるでしょ。
新しいトリップのノードが接続してきたら、そこから優先的に検索、ダウンロードすると、
んで、そのノードが信頼できるかそうでないかを手動で設定。
ノードに向かって捏造ファイルである旨のメッセージが送れるとさらによいかもだが、
セキュリティ上の問題が出るかもわからんからむりぽかな。

んで、信頼性の高いノードの信頼できるノード情報を使ったりすると、
改造ノードとかを排除できると思うんだが。

まぁまぁ、みんな、ｱﾋｬｰﾘしようよ。

>>390
ttp://www.42ch.net/UploaderSmall/source/1070973345.zip

>>392
全員トリップは匿名性に穴があく可能性がある。
例えばある一人だけのトリップをダウン可能にしておけば、特定されてしまうかもしれない。

こんな方法はどうだろう。
まず、前提として中継者はキャッシュをすぐに破棄するか、HDDに残さずメモリ上にのみ持つとする。
初期ノードを取得してネットワークに加わると、検索キーだけは回ってくるが、実際にダウンは出来ない。
まずアップロードすることで、中継ノードにその安全性が伝えられ、ダウン可能になる。この場合、送信元に身元保証は公開鍵暗号方式での公開鍵を使うものとする。
最初にネットワークに参加するためには、何か有効なファイルを持っていなくてはならないというのが欠点かな、捏造が増えそうだ。
どうか？

おっと、あほだおれ。
最初の状態でダウンできる人間がいないから、この対策をなんとかしないと。

>>393
本物っぽいね。開発頑張ってくれ。

>>394
予想外の弱点を突いてくれてｻﾝｸｽ。
個人的には、初顔合わせノード同士のデッドロックをどう回避するかが問題になると思っていますた。

とりあえず、初めてネットワークに接続した場合でも、中継には使われ、
他のノードには中継かupかは分からないわけですから、
キチンと中継しておけば評価は高まるはずです。

あらゆる事態を想定する必要があるのか？
それが起こった場合にどれくらいの被害があるのか？
なんか常に最悪の事態を想定してるみたいだけど、実際
全体に影響を及ぼすのかね。やってみなければわからないじゃん。
作りながら改善していけばいいんじゃない？最初はシンプルで。

洋物ソフトはDOMれるのが多いけど普通に落ちてくる。
ネットワークが破綻しているようには見えないんだけど。

>>399
外国ではギブアンドテイクが浸透しているからな。
DOMの数は少ないんじゃないの？

>>398
あらゆる事態は想定する必要はあるだろう。

それ以外の部分は同意。既出の否定意見を繰り返すのは
既出アイデアを繰り返す以上に意味がなさ杉。

DOMはキャッシュ即消しできないようにすれば大部分は解決するんじゃないの？
up0パッチまでやる人は少数だろうし、そういう連中は対策しても無駄なような気がする。

t6XRf4Kk君は　自分の言っていることが世界で一番正しい　と思ってるﾀｲﾌﾟ

>>401
でもやっぱり不測の事態というのはおきてみない限りなんとも仕様も無いよ。
いきなり完璧なものなんて無理なんだし不完全なβ版なりなんなり作ってから
穴をふさいでいかなくては取り掛かりさえできんと思うぞ

信頼情報をネットワークまたは近接ノードが持つのはどう? ｶﾞｲｼｭﾂ?

ｷﾀ━━━(ﾟ∀ﾟ)━( ﾟ∀)━( 　ﾟ)━(　　)━(　　)━(ﾟ 　)━(∀ﾟ )━(ﾟ∀ﾟ)━━━!!!!!

390氏はどうでる？ってかなんか家！

CASL2しか使えない俺が言うのも何だが
仕様書無しで組むのは無理だと思う・・・
例え出来たとしても時間の無駄ではないかと

アセンブリ15行すらフローチャート無しで組めないヘタレより

>>404に同意
実際のところ複数ノードによる多数決しかないのでは？>クラック対策
でも、オープンソースである以上、それなりのスキルのある香具師が居れば
それこそKのﾀｲﾌｫ用の物からDOM厨専用、ウィルス入りまであらゆるクラック、
改造が可能だと思われ。
なのでDOM対策は今のところ考えるだけ無駄。
これからP2Pを始める人が安心して使える公式?バージョンを簡単に
手に入れられ、それが本物かどうかを確認できるような環境を作るく
らいしかない。（ｸﾞｸﾞるとトップにくるとか）
あとは実際にクラック版が出てから対処すればいいのでは？

DOMや仮性Port0、クラック版を当局に対する「肉の壁」にできるような案があれば
それが一番良いんだけどね･･････

現在はDOMとかの壁に正規ユーザーがなってるけどね(　´,_ゝ｀)ﾌﾟｹﾞﾗｵﾌﾟｽ

そのあたりは、nyと同等だったら問題ないと思われ。
nyよりも良ければいいかもねといったぐらいのもので。

こんばんわ、警察です。

　 ＿＿
／　　　＼
|￣￣￣￣￣￣￣|
|　 　 　 　 　 　 　 |
|　 　 　 　 　 　 　 |
|　 　 　 　 　 　 　 |
|　 　 　 　 　 　 　 |
.￣￣￣￣￣￣￣
　　　割れ関係

割れ関~1　　　　＜DIR>　　　03-12-10　　1:53
　　　　 1 ﾃﾞｨﾚｸﾄﾘ 1,009.19 MB の空きがあります.

C:\>_

winnyが絶対自分のとこから直接ファイルやキャッシュうｐしない絶対誰かを間にかます中継って仕様だったら
依拠性がないから著作権侵害じゃないのにって思ったんだが
違うかな

隣にいる中継者がKだったら同じだろ

我関係無し

まとめサイトの方に仕様を上げていきます。
ちょっとずつなので、プロトコルにするのは
今年いっぱいはかかるかもしれませんが、
ご協力よろしく。

>>418
まじ乙です

>>394
>アップロードすることで、中継ノードにその安全性が伝えられ、ダウン可能になる。
これはダウン可能なのは中継ノードだけかな？それとも近隣ノードにばらまく？
後者ならチョット色々まずいだよねｗ
前者でも中継がｲｲポエム持ってなかったらアレだし

なんつーか結局信用できるのは自分だけなんだよな・・・
他は全部不良ノードと仮定。他人を信用する方法は無いものか。

俺もオープンソースで強制UPは無理かなと思う。
他のノードが改造クライアントに証明データを要求したとしても、
そのデータが保証されたものと確認する術はないと思うのだが？

帯域が遊んでいる時、または公開ファイルが追加された時など、
自動的にランダム転送先を選び自キャッシュを転送しようかと考えている。
この機能が実装されれば、常にファイルは不特定多数が同じものを所持している
状態になり、誰が最初の発信者か特定されにくくなり匿名性が高くなると思う。

それとフレンド機能の実装もする。フレンド間で優先ノードを構築することにより
通常より高速なファイル転送を行う。またオプションとしてミラーリングのようなこともできるようにする。
さらに、属性としてパブリックとパスつきプライベートなど細かい制御ができるようにする。
この機能の利点は光回線など高速なピアにデータをキャッシュしてもらうことで
ファイルの拡散速度を上げることが期待できる。

匿名IMの実装。これは、多段転送で実現しようかと思っている。送信先のアドレスは
ドメイン名+IPまたは固定IPを使用。この方法の利点は送信先が決まっているので検索の必要がない。
というより、この方法じゃないと送信先が決め難い。自前でユーザー探しをするとなると
最悪全ピアを探すことになる。ny的ネットワークの場合は動的だしロストの確率が高まってしまう。
最後にこのIM用のアドレスの公開方法は・・・。まだ考えてない。

と、俺的計画を書いてみました。オープンなんぞ興味Nothing。

>>418
ﾓﾂｶﾚー
あと、IDがUDP

IDが変わってますが、T00k4UDp = ◆OCoDsLMMu2 = HgNt3XJQ です。
まとめサイトでも同じトリップついてるますので、私の個人認証が
必要なところはこのトリップつけるようにします。

>>423
今回通信には UDP も採用したいなと思っていたので暗示するかのようなIDだな

>>287
>提案、疑問、質問、突っ込み、誤字指摘いずれも歓迎

>>285
>最後にここで名言しておくが、

×名言
○明言

まとめサイトの wiki にちょくちょく書いているので、
今後はこちらを参照してください。

>>425
仕様とは関係ない部分ですがサンクス

信用情報方式の提案者の人ってまだこのスレにいます？

やはり、自分が直接取引した相手だけにしか信用を与えられないのでは
信用できるノードの数が限定され過ぎてしまう。信頼できるノードの
方法を広く集められればいろいろ有益なはず。

しかし、信用した相手が持っている信用情報をそのまま取り込むのは危険。
そこで、信用度減衰伝達方式を提案したい。

1) 相手の信頼度をポイント制にする。正しいものをもらえたらポイント
を付与する
2) 時間の経過に応じてポイントは下がる
3) 信用した相手から受け取った信用情報を自分の信用情報にマージする。
4) マージの際、ポイントは減衰させる（×0.5 とか）
5) マージのとき、それぞれの信用情報のポイントが相手のポイントを
超えないようにする。
6) すでにリストにあった場合は、ポイントは高い方を採用
7) 以上により、ポイントが 0 以下になった情報は捨てる


長すぎだと怒られたので、２つに分けます。

3) 4) 5) について例を挙げる。

ノードＡからもらったデータが正しいことが確認できたので、ノードＡに
10 ポイントを付与する。
ノードＡが持っている信用情報をもらう。その中には、ノードＢ８ポイント、
ノードＣ４０ポイントという情報が入っていた。
ルール 4) により、ノードＢ４ポイント、ノードＣ２０ポイント
さらにルール 5) により、ノードＢ４ポイント、ノードＣ１０ポイントとなる。
これを自分の信頼リストに加える。


これにより、誰かが間違って信頼できないノードに信頼を与えてしまっても
その情報はあまり広まらない。

広く信頼を得るためには、継続的に多種のデータの流通に関与しなければ
ならない。


もしリストが大きくなりすぎる問題があるときは、適当な量だけキャッシュして、
信頼情報が必要なときだけ自分が信頼しているノードにクエリを発行する
という実装も考えられる。

× 信頼できるノードの方法を広く集められれば
○ 信頼できるノードの情報を広く集められれば

要望

１、このスレの次スレを立てるときは、P2Pのファイル交換スレと掲示板すれを分けてほすぃ。
２、次期P2Pプログラムから、ノードリスト管理部分を分けて欲すぃ。

ノードリスト管理部分は、それだけで個別のプログラムにしておくことができると思います。

以下仕様：

・ユーザは、そのプログラムに対して（winnyでそうしたように）初期ノードリストを与えます。
・そのプログラムは、起動すると、指定されたポートを開けて他のノードからの接続を待ちます。
・また、最初に与えられた初期ノードリストを元に、そこへつなぎに行ったりします。
・接続しに行ったけど、繋がらないノードは、リストから削除します。
・接続できたら、そのノードに、「他に起動しているノードはあるか？」などの質問をして、
お互いに Live なノードのリストを交換します。

こうしておくことで、今後開発されるであろうP2Pプログラムから、ノード管理を分けておく
ことができると思います。また、常に最新のノードリストが保持されるので、一度起動
しておけば、ノードリストを取りにWebSiteを参照する必要もありません。

ローカルで立ち上がったプログラム(例えば Winny3 ）は、このシステムに要求を投げます。
「おれWinny３だけど、他に立ち上がってるWinny3のノードリストちょうだい。」

ユーザは、あらかじめ「Winny3とWinny4のノードリストは常に最新に保つけど、
Winny５は使わないから、そのデータは要らない」と指定しておくになります。

こんなのｲﾗﾈｰ?

>>427
その信用度と、ノードとを関連付ける情報をどういう風に処理するかを考えないと無駄。
素直にIPで管理するとしたら、送信元の匿名性が失われる。固定IPじゃない場合は、つなぎなおす度に信頼情報がリセットされることになる。
ID制にすると、IDを付け替えることで捏造者たちやDOMたちに回避されてしまう。

そもそも信頼度というからには、相手を特定できる必要があるわけで、そうなると送信元も突き止められるのは自明の理であろうね。

>>430
掲示板は他の板でzigumoなんかのスレッドがあるから、そっちを有効活用すべき

>>430
ノード情報管理と、そのノードを元に構成されたネットワーク上で行われるサービスを
分離する方法は、先ほど私も提案してみました（まとめサイト）

>>431
さらに、ノードの信頼性評価を行うアルゴリズムも提案してみました（まとめサイト）

>>431
> その信用度と、ノードとを関連付ける情報をどういう風に処理するかを考えないと無駄。

その問題は、オリジナルの「信用情報方式」ですでに解決されています。

すこしずつ概要をまとめサイトに書いています。今後はこちらを参照するように
して下さい。仕様の概要だけですが、雰囲気はつかめると思います。

もうIDがHgNt3XJQでもなくなってきたし、識別が面倒なので、今後私の呼び名は
今回のトリップの ◆OCoDsLMMu2 の最後の３文字(Mu2)を元に「むーむー」とします。
感謝＞命名まとめサイト掲示板 ID:w5RXKXb+氏

むーむー

（・∀・）ﾑｰﾑｰ

>>430
＞２、次期P2Pプログラムから、ノードリスト管理部分を分けて欲すぃ。

この部分だけが公開されたら、かなり有用だよな。
ていうか、使ってみたい。(´･ω･`)

>>438
「次期P2Pプログラムから、ノードリスト管理部分を分けて欲すぃ。」

何でこんなことを書いたかというと、P2Pなんかとはまったく別に、
Chatプログラムを書こうとしているからです。

普通にChatプログラムを書けば、どっかにサーバとなる部分を動かして
置かなければならず、そのサーバの場所（IPアドレス）をChat参加者に
伝えておかなければならないです。また、サーバが落ちていたりすると、
繋がらない、という事態が発生します。

こういうプログラムがあれば、そいつに、
「おれ○×Chatだけど、他に立ち上がってる○×Chatのノードリストちょうだい。」
と、 聞くことで、他にChatを立ち上げてるPCのIPアドレスが得られます。
あとは、各ノードに直接「いまサーバやってるの誰よ？」って聞けばよい。

以上は次期P2Pとは関係ない使用方法ですが、
関係ない利用者も巻き込めるのでうまく使えば便利になるかな、と。

初期ノードサイトが安全になるというのもある鴨

作るなら、ネットワーク負荷は可能な限り軽くしてクレ

他所参照、ばかりじゃ議論が進まんな

>>441
同意。
Wikiに書いて参照してｸﾚだと十分なフィードバックは得られないと思われる

細かいものならいいけど、何十行、場合によっては何百行にもなりそうな
仕様をいちいちこっちに貼って議論するのは無理。

Wiki の内容把握してない香具師が議論に入ってくると既出ループばかりで
進まないというのもあるし、まとめサイトは積極的に活用したい。

>>443
禿同

おまえら、いやあなた方・・・・・・・・・・・期待してます！っつーか期待するしかできない！

提案

winnyを使ってて感じたのだけど、でかいファイルの一番最後の部分が、
一番落ちてきにくい気がする。（私の回線が遅いせいもあるだろうけど）

なんでそうなるかと言うと、ファイルを落としきった時に、キャッシュを削除
しちゃう人がいるから。（あと、途中で止めちゃって、キャッシュ消すとか。）

ファイルをどこかで放流し始めてからある程度時間が経ったときには、
ファイルの先頭部分を持ってる人はいっぱいいるけど、
最後のほうを持ってる人は少ない、という状況になる。

なので、これを解決するには、DLする側がDLし始めるファイル中のoffset
をランダムに決定するようにすればいい。

●いままで
UPする人：０１２３４５６７８９
DLする人：０１２３
DLする人：０１２３４５６
DLする人：０１２３４

●次期
UPする人：０１２３４５６７８９
DLする人：４５６７
DLする人：８９０１２３４
DLする人：３４５６７

完全にDLが終わったら、内容をローテイトして元に戻す。

ﾄｰｼﾛの既出無視カキコだが、
LifeGameみたいにファイルを伝染させていくとかは？
LifeGameそのままだと絶滅しちゃうけど、ある程度広がってきたら大丈夫でしょ
複数回転送したら自分のキャッシュを削除（始めに流す人も）
で、自分の保持するテーブルに何を流したかを追加。
いずれもう一度転送されてきた時に テーブルを見て
あまり流れていないレアなファイルなら削除しないとか。

完璧なクローズなど出来ないとわかっているのに、何故

＞「オープンソース」なら「強制アップロード」できない。
＞「強制アップロード」が大前提なら「クローズド」にするしかない。

になるのかがわからん。

>>448
ソースを非公開にするなら少なくともnyと同じ程度には強制アップロードさせ
ることができるのでは？

＞次期P2Pプログラムから、ノードリスト管理部分を分けて欲すぃ

これいいね。先にこっちの仕様固めたほうがよさそう。
BBSとか他のP2Pソフトも活気付きそう。

P2P プログラムの機能分担についての一つの案を出して見ます。

1) データのやりとりについては、基本的にハッシュと署名で識別。
　（署名 = Winny で言うトリップの役割をするもの。）
2) ハッシュとファイル名を結びつける仕組みを設けて検索機能提供。

1) と 2) を分離して考えることはできないだろうか？
自分が作るとしたら付けたい機能として他にも、

3) 特定の署名を持つノードにメッセージを送る機能。（メールみたいなもの。）
　（ごめん、どうやって届けるかはまだ考えついていません。）
4) バケツリレー式ストリーミングで (少しの時間差はあるものの) 皆で同時に
　楽しめる。


>>448

＞「オープンソース」なら「強制アップロード」できない。
＞「強制アップロード」が大前提なら「クローズド」にするしかない。

この発言はあまり気にしなくてもいいと思う。
自分が同意できるなら同意して、同意できないなら非同意で。
（私は非同意）

昨日は非生産的な意見ばかり並べる方が居てスレ進行が中断していました。

『オープン・強制アップロード帯域提供の両立派』を批判ばかりをするのではなく、
『クローズ or DOM容認』の可能性を説くべきでした。

昨日の事態の収集に勤めた夜間組 (?) の方々お見事でした。

>>446
効率から言えば

UPする人：０１２３４５６７８９
DLする人：０１２３４
DLする人：５６７８９０１
DLする人：２３４５

の方がいいかも。ＵＰ側は、途中で送信相手が変わっても構わず順番に
送信する。これなら、ネット上にすべてのパーツが流されるまでの時間が
一番早い。
２人目が続きをＤＬしてる間に一人目が前半を拡散させると。

>>451
> （私は非同意）
何か良い提案はある？両立させるための提案がいろいろされているようだけど
説得力のあるのは見あたらないような。ソースの改変自由、相手を特定できな
い(IDを付けることはできない)、というのが条件になるからかなり難しい。

むーむーです。

ファイルをDLする時の offset 指定に関するものと
強制UP(交換アルゴリズム)の捏造、偽造対策に関して
良いアイデアを思いつきました。
前者は前からアイデアを持っていたのですが、関連して
後者を解決するアイデアとなりました。
「オープンソース」か「クローズド」かに関する議論も
とりあえず、もういちど仕切りなおす事に鳴ると思います。
今晩まとめサイトサイトで詳細を発表（できたらいいなぁ）

>>449
そうだね。nyと同じ程度でいいとおれも思うよ。

信頼ノード方式は、漏れ的にちょっと怖い気がします。
理由は、ぱっとした思いつきなんですが……以下の通り。

1.IPが変わると今までの努力が無駄になっちゃうの？
2.[1]を解決するには端末というかノード自身が身分証明として
　署名をもつ必要があるが、これだと個人特定される危険性が
　あるって指摘は既出ですね。これの解決法がまだな気が……
3.信頼されるのは嬉しいのだが、ポエムが拡散していない初期段階
　では信者ノード(もしくはストーカーノード)が付きまとうかも
　なんかポエムの作成者(ポエマー)が危ない気が……　
　※「どうやってつきまとうのさ」といわれると辛いですが、
　　世の中には変な事出来る人が居るもので……漏れはチキンなんです
4.神級ポエムをいっぱいキャッシュ(ポエマーは別の人)してても、
　信頼を勝ち取るまでには結構時間がかかりそうです。せちがらいね。

とまぁ他にもあるのですが、一応上記のがとっても不安なわけです。
信頼ノード方式だと、ポエマーが特定されちゃうんでねぇべか？
とびくびくしてるわけですね。

(続く

漏れの渾身のポエムを大勢の人に知ってもらいたいが、個人特定されると
Kとかご近所様に「おまえのポエム聞いたよなんだよあれ赤裸々杉(ﾌﾟ」
とか冷やかされる恐怖といったらもう……。

ポエムに(もしくはキャッシュDB)に自体に信頼情報をもてないですかね？
そうすれば、神級ポエムのキャッシュがあればポエマーと同格になれるわけですよ。
それはイコール、ポエマーとポエム信者(キャッシュ保持者)の区別をぼかせるのではないか？
と思ったわけです。
ポエマーだけでなく、ポエム信者も同等の信頼を勝ち取れる。
そうすれば、ポエムの布教がよりいっそう早まるわけで……。
漏れの渾身のポエムも「なんだよこれ(ﾌﾟｹﾞﾗ」といって即効削除される事も減る訳で……。

まぁ、ポエム自体に信頼度情報を持たせると、ポエムの信頼情報を改変・捏造されたら
どうすんべ？とか色々問題はあるのですけど……。
問題山積みですが、どうですかね？

むーむーです。

>>454

思いつきを忘れないうちに書き上げてまとめサイトに投稿しました。

・ストレージ上の共有ファイル
・ストレージ健全化とノード評価

というふたつのページです。

現在までに議論されていた複数の問題点を解決できる可能性があります。
ぜひ、熟読して下さい。

疑問、質問、要望、誤字指摘などの議論は、まとめページ掲示板まで

強制アップロードってのは放流主になれということ？
それともWinnyみたくキャッシュのうｐでいいの？

Winnyよりかなり不便になりそうで、いまいち参加する気がしないな。

まだなんにも出来てないのに気の早い厨がご登場です。

せっかく作って誰も使わなかったらかわいそうと思って。

>>461
まぁ、なんだ


とりあえず逝け

>>458

まず、WikiName の使い方を知れ。

まぁ、公開時はその辺の実装は隠蔽して、一般人にはnyより匿名性が高いソフト
と言う風に宣伝するだけでスムーズに移行できるんじゃない？

>>461
さよなら

>>464 騒ぐのに精一杯だから理解する余裕ないよ

サッカー見ない？実況は
http://s2net.s41.xrea.com/x/p2p/
でやらない？大丈夫っしょ

>>458

ノードの同一性はどうやって確保する？IPが変わるまでの一時的なもの？確保
できたとしても新規に参加したノードとの評価の差が広まる一方で、逆にファ
イルの流通が悪くなるような。

むーむーです。
まとめページのwikiに「さらなる効果(追加) 」を投稿しました。

>>459
強制ＵＰとは、私の提案における「ストレージの健全性の回復に貢献するデータ転送」となります。
詳しくは公開投稿した内容を参照。ＤＬするデータによっては強制ＵＰは不必要となりました。

>>463
修正していただけた方感謝。WikiName と[[BracketName]]の使い方覚えました。

>>469
基本的にノード識別はＩＰで判断します。共有しているパーツファイルから初期の基本評価を算出して、
申請内容のチェックと、wikiで説明している貢献度によって評価を上下させる事になります。
元々不正なノードの評価を低くする仕組みであり、流通に支障が出ないような実装になると思います。

>>470
> 基本的にノード識別はＩＰで判断します。

そうすると匿名性が失なわれ易いし、IPが変わると信用情報がリセットされる
ね。あとトラフィックの増大が半端じゃなくなる。

>>471
トラフィック増大に関しては別に議論するとして、ノードの識別に関しては
検討事項だとは私も認識しています。
ただこの場合何をもって識別するのかの代替案が必要になるのですが、
どの方法も結局すこしノード情報を調査すればＩＰを特定できてしまうのが
現実です。（これを覆せる方法があれば是非採用します）

現在私の方針が「Ｐ２Ｐによる共有ストレージとその健全性の維持」に向いて
いるので匿名性に関しての割合がはすこし下がっているのは確かです。
おそらく、オープンソースになれば、誰かが匿名性を確保する方法を提案して
実装してしまうような気がします。実装に入ってないのでまだ狸のなんとやらですが

捏造対策は前スレ>>843の仮想ハードディスクhttp://fosae2003.tripod.com/を利用し、自分からはどんなキャッシュを保持しているのか見えないようにする。そして、一定量の捏造警告キーを受信した時だけそのキャッシュをクリア。
キャッシュ消し厨対策は、その仮想HDを作成する時間を長くすればいいのでは・・・（1〜2時間ぐらい）これでキャッシュ消す気にもならない・・・はず・・・

ソースはオープンにしたほうがいいと思うけど、強制アップは
難しいと思うし、捏造ファイルの拡散になると思います。

p2pに貢献しているノードは得になる仕組みで考えていったほうがいいのは。

ちょっと考えてみました。
・まず、基本はupもなにも無くてもダウンは出来るようにします。
ただし、送信側で制約をつけます。（帯域、優先度など）
・AからBに送信要求があって、Bがその送信が完了するとAはBに
　「送信ありがとう券」をあげます。この券には発行元のAのIPと
　ユニークな番号と有効期限が描いてあります。
　Aは発券した番号と有効期限を管理します。
・BがCに(Aでもいいけど)転送要求するときには、その「送信ありがとう券」を
　つけます。Cは券を受け取ったらAにそれが本物か確認して本物であれば
　送信の帯域を増やしたり、「送信ありがとう券」無しでやっている他の送信を
　中断してでもできるだけBの要求に答えるようにします。
※Aはファイル送信元、Bはファイルの要求元と限定していません。
　お互いが転送途中の隣あったの上流は下流の関係でも同じように
　「送信ありがとう券」をやり取りします。ファイル単位ではなくブロック単位の
　送信が完了したら発行します。

　と、こんなところです。

ぱっと思いつく穴
・２つ以上のノードが協力して「送信ありがとう券」を乱造できる。
　送信要求のチェックの時、複数のIPの「送信ありがとう券」を確認するよう
　にすればある程度はマシになるかもしれません。
・IPがころころ変わるノードの券は無駄になる。
・自分が券を持っていても、受信間に券を持たない転送ノードが入ると効率が悪くなる。

でも、不正ノードを弾く仕組みよりはやりやすいかもしれせん。

なんか実際に理論通りうまくいくのか試したいね。テスターとしての血がうずく。

>>474
ちょっと訂正
>※Aはファイル送信元、Bはファイルの要求元と限定していません。
じゃなくて
※Aはファイル要求元、Bはファイルの送信元と限定していません。

>>474

乱造もできるだろうし、そういう券をもらったところで相手が遅かったら役に立たないと思われ。。

nyのクラスタ化がいいと思う。もっと洗練させられればいい。
要するにどうすれば目的のブツをいかに早くゲットできるかが基本だと思う。

性善説に則ってDOMはある程度許容する仕様にしたら？（ｎｙも問題なく動いてるし）
捏造ファイルをどうするかの方が重大な問題だと思う。
ゴミファイルがいつまでもネットワークに残らないような仕様じゃなきゃ。

>>478
>>473に書いた通りでいいのでは？

>>479

キャッシュの保持と強制アップロードは直接関係ないと思う。キャッシュを持っ
ててもアップしなければいいんだから。

>>478
性善説はｸｿ
個人的思想でｽﾏｿｗ

風呂に入って匿名掲示板を実現する方法を考えていたら、いい方法が浮かんだ。
ピアをプロクシのように扱う。つまり要求を出したピアが他のピアに、通常のHTTPをさせて
そのデータを受け取る。毎回ピアを変更したり、多段化すれば十分に匿名性を確保できると
思うのだがどうだろうか。(つまりWebサーバ側には本当の参照者を知る方法がないので記録が残らない)
掲示板の設置はもちろん通常のHPを使用です。
欠点はどうしても、末端のIPは記録される可能性があることかな。
この方法だと、データを一括管理でき分散する必要もないので整合性の面ではいいんだよなあ。

既にありそうだけど、どうです? この方式?

>>482
それが俗に言われる伝説のプロクシ

　　　　　　　　　　Six/Four

そして既出

>>482
> 掲示板の設置はもちろん通常のHPを使用です。

設置も串刺してするんだろーか。和ジオとか最高。

まあ取り合えず、搭載してみるかな

>>484
設置しなくても、存在するものを使えばいいのです。2chでもどこでも。

専用CGIと専用URLで実装すれば、どこのHPを見に行っているかわからないように匿名化も可能かも。

>>486

誰もそんなネットワークに参加しないと思われ。やばい書き込みを自分にせい
にされてもウザいし。そういう書き込みしたいやつは普通に串を探すだろ。

>>427
今頃遅いですが「信用情報方式」提案者です。いちおうROMってます。

捏造の話になってますが「信用情報方式」はおとり捜査対策で考案しました。
実際のところ盗聴に該当するため違法捜査になりwikiにあるようなことはできないというのであれば
この意見の主旨は無視してもいいかもしれません。

ポイント制は良いアイディアですが、誰かが提起してくれたように
いちいちダウンロードするたびに「信用するかダイアログ」で訊いてくるのはうっとうしいですし、
判断するためにはユーザが仕組みを理解していなければなりません。
ユーザビリティが悪く、賛同は得られにくいでしょう。

信用リストを他ノードと交換すると「多くの利用者により順位付けまでされたブラックリスト」(ﾟДﾟ;)を
ポエム交換を良しとしない者が入手できる可能性があるのも困ります。

もう少しリストを豊富にするのであれば転送によりダウンロードできた実績もポイントとして加える程度で、
　元ファイル（またはキャッシュ）提供者＞中継に入り自分にアップしてくれた人＞それ以外
の順でポイント獲得とし、ポイントの高い方からリクエストがあった場合、
低い方の送信を中止してでも貢献者を優遇する（「送信ありがとう券」で既出）ようにする感じになりますか。

ところで話変わりますが、中継ノードが送信先の信用がないことを理由に中継を拒否するのであれば
既出の「３すくみ」問題が起こります。念のため。

安易な「信用情報方式」より画期的な「ディスク共有」が有力そうですのでとりあえず行方を見守りたいと思います。

>>487

>>どこのHPを見に行っているかわからないように匿名化も可能
これが実現できれば

>>やばい書き込みを自分にせい にされてもウザいし。
この現象は起きません。

Wikiのほう、何度も読み返しているけど、ぜんぜんわからない。

＞ 「ストレージ健全化とノード評価」では、過剰に増えたパーツファイルは削除してよい
＞ とありますが、改良すれば「パーツファイルを作成する３つの断片を一つ残して削除」と
＞ いうアイデアが生まれます。

3つの断片が「作成」するのですか？

「パーツファイルを構成する３つの断片を・・・」のまちがい？

＞ これは「各ノードにおけるパーツ完全性志向」に反する性格ですが、十分に分散している
＞ パーツファイルは、完全体でなくてもストレージ全体と見れば健全であると判断します。

誰が判断するの？
ユーザ? システムが？

私の頭がわるいから、わからないのかなぁ。

>>489
なぜ？末端のIPは記録されるし。2chに書き込んだら自分にせいにされるだろ？
基本的にnyBBSと同じ、もしくは改悪に過ぎない。

オープンソースかつDOM防止可能な案

方針
DLするためにはULを必須とすることで、UP0にして帯域を節約することを目的としたクラックを不可にする。
（ダミーファイルをUPするとしてもULに帯域を使うため、クラックの効果は減る）

方法
ファイル（キャッシュ）の送受信は基本的に自分にファイルを送信している相手に対してファイルを送信する。
相手がこちらの希望するファイルを持っていないときは、転送をしてもらうことでこちらへの送信の代わりとする。

AとCが双方向にファイルを送受信しているとき、BがAにファイルをリクエストする場合、
AはBの保持するキャッシュから欲しいファイルを探し、見つかった場合は互いに転送しあう。
見つからなかった時、AはCのノード情報と送受信中のファイル情報をBに送り、CにはBのノード情報を送る。（転送依頼）
こうしてBを中継とするA→B→CとC→B→Aの転送経路を確立する。（A<->Cの送受信は保持したまま。）
Aは転送によってBからの受信が出来たので、Bにファイルを送信する。

ここで新たにDがBに対してファイルをリクエストし、DがBの欲しいファイルを保持していなかった時、
BはAB間あるいはBC間のファイル送受信（転送含む）をDに転送依頼し、D→Bの送信を確保して、Dにファイルを送信する。

A→Bへの送信中にCがノードから外れる等で切断した場合、C→Aの転送依頼によってB→Aの送信を確保しているためにB→Aがなくなってしまう。
この時、Bの保持の中に欲しいものがあればそれをDL、AがC以外のノードと送受信している場合はそれを転送依頼など、B→Aの送信を確保する必要がある。確保できない時は断腸の思いで切断。。。

匿名性
DがBからAB間の転送依頼された場合、DはAB間で送受信されていることは分かるが、Cの存在は見えない。
もしB→Aへ問題のあるファイルが送られていたとしても、それはC→B→Aの転送ファイルの可能性もあり、アップロードした者を特定したことにはならない。（でも違法なファイルのやり取りはやめましょう）

弱点
何も送受信を行っていない2つのノードは、お互いに欲しいファイルを持っていない限り送受信することが出来ない。
→どこか一箇所とでも送受信していればOkなので、ユーザーが増えれば解決。
ファイルの送信が常に双方向で行われ、転送依頼でどんどん増えるため、トラフィックがny以上。
→仕方ないさ。
捏造ファイルはどうするのさ
→他の対策と組み合わせないと無理。

むーむーです。
まとめサイト wiki に「12月10日のむーむー雑記」を投稿しました。
思いつきや、仕様の整理で書き留めた内容を投稿してします。
今日の内容は以下の通りです

・強制ＵＰ対象のＤＬ
・強制ＵＰ対象のＤＬ
・ファイル名の収束アルゴリズム
・匿名掲示板
・共有ファイルのＵＰ
・捏造ファイル
・ノード評価算出方法

>>491

>>専用CGIと専用URLで実装すれば

この時点で、暗号化されます。普通のブラウザなどからは見えません。そもそもURLがわからないので無理。
接続方式は>>482
接続は転送によって行われるので、リクエストを出したピアは実際にどこのHPをアクセスしにいくか知る方法はありません。
逆に実際にHPにアクセスしにピアは、リクエストとその結果は暗号化されているため、何なのか知る方法がありません。
どこに何があるのかわからなければ、指摘することさえできないはずです。
nyBBSとの違いはデータが置かれる場所がピアではなく一般のWebスペースであるということです。

とりあえず、オープンソースでも
DOMクラックは何とかなると思う。
長文ですまんが、突っ込みよろ

むーむーです。指摘感謝。積極的に読んで頂き、うれしい限りです

>>490
ご指摘の通り表記ミスです。修正します
「パーツファイルを構成する３つの断片を一つだけ残して」で正解！

健全性を判断するのは、ストレージ情報として集めたファイルキーから
総合的に判断して、なので「システム＝プログラム」です。
削除対象にする場合は、関連ノードに「報告」してから「削除」します。
「無断」で削除する場合は、マイナス評価にするつもりです。

あれ…
352はまちがい。>>493･>>496＝359

むーむーです。

>>496
今日まとめサイトの wiki に投稿した仕様で、「オープンソース」でも

・DOM対策
・捏造ファイル対策

に対する解決が存在する事が、提示できていると思います。
まぁ、私の考えに穴があったとしても、方向性は間違っていないはずです。
ぜひ、読んでいただき、感想をよろしく（突っ込みでもいいけど・・・）

＞むーむー
絶滅寸前ファイルとかどうやって判断するの？

むーむーです。

>>500
ファイルキー管理に関してまだ説明してないので、疑問はごもっとも。
ファイルキーを管理するテーブルでは、「どこのノード」が「どのファイルのパーツファイル」を
「持っている（あるいはありかを知っている）」という情報のリストからなります。

よって、このファイルキー情報を集計する事で、たくさんのノードが持っていそうなファイル、
全然見つからないファイルなどを分析する事になります。

ただファイルがある、ないを即時的に管理するのではなく、時間をかけて（数日単位）で、
ファイルの分散情報を蓄積、判断していくことになる予定です。

>>492

何かMXみたいだな。途中で切断するﾔｼもたくさん出てくると思うけどどうする
んだろう？あと転送するためのUPとDOWN、そしてようやく目的のファイルの
DOWNなんてのはトラフィックがすごいことになり過ぎて現実的じゃないと思う。

とりあえず「むーむです」は突っ込みの対象になるかと思うので止めること推奨

むーむーです。

>>492-493
私がはじめに考えていたアイデアに似てますが、
詳細な転送経路や中継ノード断に関する具体的な
説明もあり非常にわかりやすいです。

私がここで問題にしたのは、UPするファイルをどうしようか？
なんですが、私の wiki 投稿したアイデアでは、ユーザが
取得したいファイルをUPさせるのではなく、不完全データを
完全に補正したり、P2Pネットワーク上での共有ファイルを
データ消滅や、ノード消滅から積極的に守ろうという、
ファイル共有に有益な転送を行うというところに辿り着きました。
参考になると思うので、wiki を読んでいただければ幸いです。

>>503
祭りや荒らしのネタにされたり人格否定されるとかは確かに嫌ですが、
私の意見に対するツッコミは個人的に大歓迎なので・・・ （私の解釈まちがってる？）
まぁ、一応トリップで私を判断できるぐらいには知れ渡ったかもしれないので今後は
控えます。忠告サンクス＞07ok2LLo

>>477
遅い相手は、券無しではさらに遅いです。
券を持っている人に転送を優先されることもあります。

そいえば穴だけ書いてたけどメリットも書いときます。
・（たぶん）実装しやすい。
・貢献ノードリスト、または（kやaにとっての）ブラックリストが作成しにくい。
・参加ノードが少なくても成立する。

>>495
？？

漏れの言っていることは

やばい書き込みを誰ががする->漏れが中継して書き込み->2chにIPが記録される->(((；ﾟДﾟ))

ってこと。

一般のWebスペースに書き込んでも匿名性はないし、書き込む当事者が匿名で
も他の誰かが匿名じゃない。身に覚えのない責任を被せられるネットワークに
誰も参加しない。

そもそも一般のWebスペース、普通の鯖なら落ちたら終わりだろう。それだか
らp2pの掲示板があればいいと思われてるわけで。nyBBSも匿名性よりもこっち
を重視していたと思う。不完全だったが。

>>504
一万を超えるノードとか出来たときにまともに動くの？
全体を把握するなんてまず不可能だしな
なんか他に考えてる？

通信にもこだわってほしい
ネットワークトポロジを無視したnyのような構造はやはり無駄
トポロジも考えた上P2PであればやはりIPv6トランスポートは必須
IPv4で通信させないなどの現在での匿名、秘話性はある

特定シグネイチャをできる限り含めないようにし、ISPのP2Pトラフィック抑制にも対抗

>>507
中継書き込みや匿名書き込みに関する解釈ですが、
プロバイダ責任法などの法律においては、

・書き込んだ人のＩＰを記録して提供するのであれば設置者は免責される。
・プロクシでも、完全匿名にしたら免責されないが、ＩＰなどを提供できるならば免責される。
・一般の掲示板なのでは、書き込んだ人が特定できなければ設置者の責任となる。
　よって要求に応じて、あるいは自発的に発言を削除しなくてはならない。
・一般の掲示板などでは、書き込んだ人のＩＰが提供できるのであれば、免責される（？）が、
　設置者も管理責任を問われる。

みたいな解釈だったような気がします。いま設計しているシステムの説明としてこのあたりの
正しい解釈を知っておく必要がありそうなので、詳しい人詳細よろしく（ミスの指摘お願いします）

こういう内容は、法的な観点から考察スレに書くべきだったかな？スレ違いだったらスマソ？

>>508 ご指摘サンクス
現状のところキー管理の限界に関してはまだ考慮していないです。
ご指摘の通り、管理限界数が出てくるのは間違いないので、
nyでも、ノードキーは多くて数百程度（うろ覚え）だったし、
ファイルキーも３万（高速なコンピュータ）だったから
おそらく、その数でも実現可能なしくみになると思います。
ここらあたりも今後の仕様作成の際の検討事項に入れておきます。

>>509
禿同。旗立てて行進してる限り目を付けられるわけだし、
他の通信に紛れることも考えるべきだな。

>>509
IPv6を利用した匿名P2Pネットワークトポロジにはどんなのが思い浮かびますか？
有用な案が出ればIPv6を試してみたいので。

>502
１対１の交換ぽいところは初期のMXに似てるか。
ny同様、キャッシュを保持することでいろんな所から落とせたり、転送したりはするけど。
切断は大丈夫かと。全部切断したら自分もDLできなくなるし。
トラフィックは…やっぱだめかね…

>むーむー
wiki読んでます。
私の方式は転送方法に限った話なので、パーツ分散とか組み合わせることができると思います。
貴重パーツをULすることで送信を確保するとか。

>>514
> 切断は大丈夫かと。全部切断したら自分もDLできなくなるし。

切断が一番心配だと思うのだが。いわゆる持ち逃げをされたらおしまい。

3つのパーツに分けるやつって、ダウン後にベリファイできるの？
結局3つのパーツ全部ローカルに持ってこないと、完全性のチェックできないような・・・
nyのキャッシュファイル構造はエライ頑丈だったよね。

相手が特殊なクラック版じゃない限り、
切断者から転送依頼を受けて送信を確保できるけど。
切断者だって自分以外からもDLしてるだろうし。

現行の winny がどう動いているのかの質問です。

?---A---私---B---?

こんな状態の時に、私が「mpg」で検索をかけたら、私のノードはお隣さんの
AとBに対して「mpgってのが含まれてるファイル名のリストくれYo!」って
おながいしますよね？

んで、AやBは、自分のキャッシュやUPフォルダから該当するもののリストを返す。
そのとき、Aは、さらに隣に「mpg」について聞いてくれているのでしょうか。（質問１）

だとしたら、どういう時にリストから削除されるんだろう。
検索結果の表示を見ると、延々増え続けたりしてないようなので、
いつ、リストから項目を消しているのかわからないっす。（質問２）

>>517

まずオープンソースならそれが「特殊」だとか「クラック版」なんてことはな
い。改変は当たり前。

あと意味がよく分からない。
AとBが交換してるなら(Cが中継していようと)先に落したほうが切断する。
そういうことができないのか？

>>430
それだけの、プログラムなら簡単に出来るから作ろうか？
それで、ちょっと気になるのが交換するノードリスは、
・ノードリスト交換サービスのノードリスト（必須）
・Winny3サービスのノードリスト（オプション指定）
・Winny4サービスのノードリスト（オプション指定）
ということだよね？

一番簡単なのは、自分がアップしてるノードから必ず自分もダウンさせてもらうってことだな。

>>520
＞ ・ノードリスト交換サービスのノードリスト（必須）

はい。

＞ ・Winny3サービスのノードリスト（オプション指定）
＞ ・Winny4サービスのノードリスト（オプション指定）

このへんは、単に文字列で指定できたらいいんじゃないかと思います。
あとからどんなサービスが発生してもダイジョブなように。

>>519
当然落としきったら切断されます。
その時、Aとの交換とは別にBがDと交換を行っていた場合、
BはAにBD間の転送依頼を出してA→Bの送信を確保する。
Aの持つ希少パーツをBがDLすることでA→Bを確保してもいい。
あるいはBの近くの別のノードEがAにリクエストした場合、
EはAの欲しいファイルをBで発見、B→E→Aと中継することでAへの送信を確保。
（もちろんE→Bへの送信がなければEはBからDLできないが。）
こういったいくつかの方法でAは残りを集められればいいなぁ…

特殊なクラックといったのはこの仕様に従わないって意味です･

>>521
まさにこれ。

>>523
Aはもう落としたんだから何されようが依頼なんか受け付けないだろう。

>>522
それと、もう一つ。
> お互いに Live なノードのリストを交換します。
というのは、接続要求をかけてOKだったノードのみ？
それとも保持しているノードリスト？

議論中申し訳ないですがアナログな効率向上案。
P2Pソフトにファイル名の記述を統一するテンプレを同梱する。
目的のファイルを手動で検索する際の効率が上がり、キャッシュが増えることで全体の効率も上がる。
先頭に記述形式を入れることで、将来変更があってもソフトで自動的に変更できる。
例：
(記述形式)(アルバム)(トラック)(曲名)(アーティスト)(ビットレート) .拡張子なら、
(Rev001)(THE MUNEO HOUSE)(01)(ムネオリミックス-intro)(suzuki muneo)(160Kbps).MP3 とか

それが何故、効率アップになるか俺にはわからん。

>>525

Liveなノードリストっていっても、今、この瞬間本当に上がってるかどうかは
きっとわからないと思うので、２・３分おきに1こずつとか確認して、落ちてたら
リストから消す。リスト要求されたら、とりあえず今もっているものを全部
渡す、とかになるんでしょうか・・・。

ある程度の量のリストを持っていれば、1個くらいは生きてて、
1個生きてるのがわかれば、あとはそのサービス側で確認してもらうって
感じでいいんじゃないかなぁ。

（ひとつもコーディングしないで、なんか偉そうに言ってすみません。）

>>526
検索の効率のこと言ってるのかな。
あなた・・・ひょっとしてnyやってた時クラスタを知らなかったとか？
微妙にスレ違い・・・というか場違い。

>>528
了解しました。明日作りますので、明日中にはアップできるかと思います。

>>524
ごめん、AB間で交換しててBが落とし終えた時の話…
書き忘れてた。
Aが落とし終えても、今度はBが同じようにして送信を確保しようとする。

>>516
> 3つのパーツに分けるやつって、ダウン後にベリファイできるの？
> 結局3つのパーツ全部ローカルに持ってこないと、完全性のチェックできないような・・・
展開結果をハッシュチェックすればいいだけ。３つ全部ダウンする必要はない。

>>531
> Aが落とし終えても、今度はBが同じようにして送信を確保しようとする。

んでそれをどうやってするのよ？523にいろいろ書いてるが落とし終えた方が
UPしなかったら終わりだろ？

>>516 >>532
断片毎のベリファイですが、ファイル全体のmd5値を、ファイルキーに入れるのと
同様に各断片[1]とか[15]とかのmd5もファイルキーで管理するようにすれば、
各断片をチェックする事は可能です。
明日あたりにファイルキーに持たせる情報を整理したいと思います。

>>533
DLするためには必ずULしなければならないから、どこかにULはしているはず。
そこの中継させてもらったり、間接的に落とすこともできると思うが。
それとも、落とし終えた奴は二度とそのツールを使わないのか?

>>535

持ち逃げされたら当然尻切れのファイルになる。

>>536
それはMXでもnyでも同じ。
転送する順番は頭からよりランダムの方がいいかも。

>>537
ランダム転送は絶対に導入してほしいよな。
Nyだと尻切れファイルが多すぎて困った。

>>537

でその尻切れ部分をどうやって手に入れるんだ？相手が欲しいファイルを持っ
ていなかったらどうする？交換するためにどのファイルが必要欲しいのかも分
からず交換相手を探し回るのか？それでまた尻切れになる可能性だってある。

この場合は双方が欲しいファイルを持っているからまだましだ。例えばAがBの
ファイルを欲しいが、BはAのファイルを欲しくないとき非常に面倒なことにな
る。Aが欲しいファイルを持っているCのファイルをBが中継するにしても、Cが
欲しいファイルを再びBが持っていなかったら、そのためにまた中継しなくて
はならなくなる。これが無限ループして回線は簡単にパンクする。

もし双方が欲しいファイルを持っていたとしても交換条件が合わなかったらそ
れで終り。(ファイルサイズや回線速度とかから持ち逃げされると思ったり、
ファイルを疑わしいと思ったり、その他いろいろの理由で)

中継しようがキャッシュしようがVlerhJc1の言うことは根本的に交換と同じ。

何をダウンしてるか判らなくすればいいんだ！

>>537
> 転送する順番は頭からよりランダムの方がいいかも。

尻が切れるか頭が切れるか胴体が切れるかところどころ部分的に切れるかとか
はまったく関係ない。不完全ファイルであるということを言ってるわけ。

>539
だーかーらー
そのAがBのファイルを欲しいが、BはAのファイルを欲しくない時は
BがDと交換していたならAはBとDの間の転送をすることでA→Bを確保するの。

この時行われてる転送は、
ファイル1（Aが欲しがって、Bが持ってる）
B→A
ファイル2（BがDから落としてる）
D→B、D→A→B
ファイル3（DがBから落としてる）
B→D、B→A→D

要するに、自分が一つでもDLしている相手にしかULしないって原則。
もしBがどことも交換してなかったらその時は仕方ないが、
どこかと交換を始めたところで転送させてもらえばいいわけ。

根本は交換だけど、これは絶対DOMが出来ないようにする仕組みってだけ。

>>540
それもそうだけど、オープンソースにした時は何を落としてるか分かるような改変も出てくると思う。

>>541
頭のほうをAが、尻のほうをBが、真中をCがキャッシュしていれば
とりあえずネットワーク上には全体が残ってることになる。
頭から転送だけの場合、AもBもCも頭のほうしか持っていないため不完全。
確率の問題だよ。前者のほうが全体が残る可能性は大きい。

>>542
> そのAがBのファイルを欲しいが、BはAのファイルを欲しくない時は
> BがDと交換していたならAはBとDの間の転送をすることでA→Bを確保するの。

BはUPする上に遅くなるだけで何のメリットもないな。それにBとDとの交換が
成立しているならAが欲しいファイルをUPする必要もない。

それに不完全ファイルの補完も手間がかる。双方が欲しいファイルを持ってい
たとしても交換条件が合わなかったらそれで終わり。拡散効率も悪い。

>>532 >>534
なーるほど。
nyのデータ保存性・耐障害性の高さって、ダウン完了の度に毎回行う全体のハッシュチェックで、
「完全キャッシュ」を清潔に保つ事で成り立ってるような気がして・・・
各ノードが、ダウンする断片をランダムに（かつその断片6個？で全体を復元可能なように）
選択するとして、そのつど断片'sと全体ハッシュのチェックだけすれば十分ぽいね。

>>544
これが効率よくできればオープンソースにできるんだと思うんだけど。

最終的にUp=Downになっているわけだから、どこかでDownだけしている人がいれば
どこかでUpだけしている人がいる。
Winnyでは、本体で制限がかかっていて極端な偏りが出ないようにしている。
ここがオープンにできない最大の理由。
もし原則交換にすれば必ずUp=Downが守られるので、他に対策をしなくてもよくなる。

警察ですけど、読むの大変。

警察を騙るのは重罪

>>546

交換できるクライアントなんて山ほどある。それで効率が良くできないから共
有ということになるわけだろ？

>>546
分かってくれてありがと。

>>544
確かにBにとっての直接のメリットは薄いかもね。
この部分はネットワーク全体にとってのメリット優先になってる。

転送量はny以上になるし、拡散効率はけっして悪くないよ。
大きいのはやっぱり効率の問題か。

あ、ちょっと気が付いた。
大量のキャッシュを抱え込むことで交換条件の合う相手を見つけやすくなる。
キャッシュ即消しがデメリットになるわけだ。

>>550
> だーかーらー
> そのAがBのファイルを欲しいが、BはAのファイルを欲しくない時は
> BがDと交換していたならAはBとDの間の転送をすることでA→Bを確保するの。

ここでBがAにUPする義理もメリットも必要性もないだろう。交換が成り立って
いないのだから。それなのにどうして拡散効率が悪くないんだ？拡散どころか
1bitもUPがないじゃないか。

>>551
> 大量のキャッシュを抱え込むことで交換条件の合う相手を見つけやすくなる。
> キャッシュ即消しがデメリットになるわけだ。

ftpやMXで交換したほうが速いと思われ

>>549
交換という表現は適切ではなかったかも。
Winnyも共有といっているが、長期的全体的に見ると交換していると見ることができないかな。
自分が望んだものをDownする代わりに、どこぞの誰かさんにUpするということを自動的にしている。
そういう意味での交換です。
オープンにすると、長期的全体的に制御することが困難になるので、交換と共有の間辺りに
この案はどうかなと。

>>552
A→BのためにB→Aを要求するってことでしょ。ほしけりゃ中継でも何でもいいから、とりあえず何かもってこいと。
Bが欲しいファイルはDABの3者が持つことになるので、拡散でしょう。
効率が悪いのは否定しません。

>>553
(やったことないけど)MXのなにがたるいかといえば、Winnyなら自動ですることを人がしている点。
ftpやMXを自動でやってくれれば楽で効率がいい。
自動でやるための一手段かと。

>>554
> >>549
> 自分が望んだものをDownする代わりに、どこぞの誰かさんにUpするということを自動的にしている。
> そういう意味での交換です。

要するに強制的にアップロードさせるということ？それをオープンソースで実
現できるのかという話のようだが？

> A→BのためにB→Aを要求するってことでしょ。ほしけりゃ中継でも何でもいいから、とりあえず何かもってこいと。

「何でも」よくないし「とりあえず何かもってこ」られても困るだろう。Aが
いらないんならゴミだし。それに中継されても遅くなるだけで迷惑なだけ。

>>553,556
>要するに強制的にアップロードさせるということ？それをオープンソースで実
>現できるのかという話のようだが？
最初にそう書いていたと思うが…
DOM防止って書いたっけ？＝強制ULだろ。

nyがなんのために中継なんていうめんどくさいことやってるか考えろよ。
転送経路を複雑にして追跡を困難にする目的もあるんだよ。
一応補足：ずっとファイルって言葉使ってたけど、これはキャッシュのことね。

今までのP2Pより効率が悪いのは確か。
でもDOMがいなくなる事で分散効率は幾分上がる。（DOMがキャッシュ持ってても外に流れないから。）
それを加味すればそれほど引けを取らないと思うけど。

効率だけを求めるならMXでもftpでも使ってなさい。

>>556
>それに中継されても遅くなるだけで迷惑なだけ
ここで効率を考えるとnyになるんじゃねーのか

>>556
＞要するに強制的にアップロードさせるということ？それをオープンソースで実
＞現できるのかという話のようだが？

Winnyでは利用者が意識せずともまわりまわってどこかの人にUpしている。
しかし、オープンにすると原則を守らない(=絶対にUpしない)ノードが発生する。
Upに参加しているという証明ができた(=自分にUpしてくれている)ノードにのみ
ネットワークの参加権を与えるようにすれば、原則を無理矢理守らせることができる。

＞「何でも」よくないし「とりあえず何かもってこ」られても困るだろう。Aが
＞いらないんならゴミだし。それに中継されても遅くなるだけで迷惑なだけ。

ほしけりゃ、「中継でも」「自持ちファイルでも」手段は何でもいいから、とりあえず(納得できるもの)何かもってこいと。
偽っていらないのを持ってきたり、(こちらの主観で)速度を渋るようならこちらも相応の措置をとればいい。
つまり、こちらもUpしてやらない。

>>557
> >要するに強制的にアップロードさせるということ？それをオープンソースで実
> >現できるのかという話のようだが？
> 最初にそう書いていたと思うが…
> DOM防止って書いたっけ？＝強制ULだろ。

VlerhJc1へのレスじゃないんだが。

> nyがなんのために中継なんていうめんどくさいことやってるか考えろよ。
> 転送経路を複雑にして追跡を困難にする目的もあるんだよ。

十分承知してます。

> 今までのP2Pより効率が悪いのは確か。

効率が悪いんじゃなくて、それ以前の問題として1bitもUPがないのだが。どの
ようにしてUPする義理もメリットも必要性もないのに拡散するんでしょう？

> 効率だけを求めるならMXでもftpでも使ってなさい。

漏れは「効率だけを求める」なんて言ってないけど。

> 大量のキャッシュを抱え込むことで交換条件の合う相手を見つけやすくなる。
> キャッシュ即消しがデメリットになるわけだ。

ならわざわざ面倒臭そうな新ソフトより普通に交換したほうが早いんじゃない
の？ってこと。

>>557
>DOMがいなくなる事で分散効率は幾分上がる

でも部分キャッシュ大量生産の可能性もあるのも事実
・・・これを回避する手段がちょっと思いつかないな・・・

> Upに参加しているという証明ができた(=自分にUpしてくれている)ノードにのみ
> ネットワークの参加権を与えるようにすれば、原則を無理矢理守らせることができる。

その原則って交換のことだよね？

> ほしけりゃ、「中継でも」「自持ちファイルでも」手段は何でもいいから、
> とりあえず(納得できるもの)何かもってこいと。偽っていらないのを持って
> きたり、(こちらの主観で)速度を渋るようならこちらも相応の措置をとれば
> いい。つまり、こちらもUpしてやらない。

ftp, MXの世界そのものだね。

>>566
一応この話の発端の>>492-493は俺ね。
日付変更でID変わっちゃったけど。

>わざわざ面倒臭そうな新ソフトより普通に交換したほうが早いんじゃない
まぁこのスレの趣旨があれだから…

>>561
転送順序をランダムにして、あとは確率論で。
くらいしか思いつかないな…
wikiにある案とかと組み合わせられないこともないけど。

>>562
＞ftp, MXの世界そのものだね。

適正な相手かの判定を人がしている。それを自動でできたら十分だと思うが。
あと、ftpやMXはもろに相手が持っているとわかるが、中継の可能性を否定できないだけでも
かなりのメリットだと思う。

>>560

交換が目的じゃないからだと思うよ
>554は便宜上、「交換」という言葉をつかってるんだろ
↓これ
>交換という表現は適切ではなかったかも

>>562
このスレの捕らえ方を根本的に間違えてないか？
もし「これだったら新P2Pｲﾗﾈ」と考えてるのならftpでもmxでも好きに使えばいい
だが、「これだったらftpやmxと変わりない、より改善すべし」と、考えてるなら代案ｷﾎﾞﾝﾇ

>>564
いろんな部分を自動化したり、中継したりしても交換が原則なら本質的にftp
と同じになるね。手間がかからないだけで。そして交換するならそれなりのブツ
が必要になる。次期P2Pは退化するんだろうか？それともこれは進化なのか。

>>566
物を持っていないときは中継することで元手を作れるという仕組みなんだが。

>>566
「中継」というすばらしい制度のおかげでブツを持ってくるところまで自動化

となればOK。
ギチギチの交換でなく、多少ゆとりをもって対応すれば元手なしでもはじめれると思う。

>>565
> このスレの捕らえ方を根本的に間違えてないか？

次期p2pの仕様だろ。でオープンソースで強制Uploadができるのかという話に
なっている。その提案の穴を指摘しているわけだが。漏れは何にも反対してな
いよ。

> だが、「これだったらftpやmxと変わりない、より改善すべし」と、考えてるなら代案ｷﾎﾞﾝﾇ

「これだったらftpやmxと変わりない」と思ってる。「より改善すべし」だな。
代案はうんこしながら考えるよ。

>>567

AとBとで交換が成立した。そこにCとDとが中継しようとする。AとBに何の得が
ある？ウザいだけ。寄生虫じゃあるまいし。

完全に流れを無視した発言かもしれないが
そもそも違法性のあるファイルを流通させない方式も考えるべきではないのか？
今までの話題になっている仕様は、違法性のあるファイルを流通させても逮捕されないように
する仕様にしか思えん。

47氏は、インターネットのあり方からは、どうあがいてもP2Pによるファイルの流通は除去出来ないと
考えていたし、その現実から目を背けて昔さながらの著作権のあり方でコンテンツの代金を
得ようとする流通サイド（ＩＳＰ含む）と社会に対する警鐘としてWinnyを作ってたはず。
47氏の証券ライクなコンテンツ流通システムの案もその辺りから来ているものだと思う。

単純な案だが、Winnyではキャッシュに「捏造フラグ」を加えることが出来たが
同様に「違法値」を加えるのはどうか？
ある一定の「違法値」を超えたキャッシュを保持するノードは目を付けられ
「違法ファイルの流通の疑いがあるノード」としてどこからも検索出来る。
もちろん、非匿名の状態（ＩＰ丸出し等）で。
後ろめたい事をして無いのなら、目を付けられても問題ないはずだ。

違法ファイルを流通させたい奴はすればいい。
その代わり、近くにたまたまモラリストがいればタイーホされることになる。
100人のDQNがいても一人のモラリストがいれば十分だろう。

>>570
この仕様だとそうだな。AとBとで交換が成立する前に、成立を助けるかたちで
中継が割り込めればいいんだが。
その辺りを考えて再提出だな。

>>571
次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070500722/

>>571
> 今までの話題になっている仕様は、違法性のあるファイルを流通させても逮捕されないように
> する仕様にしか思えん。

その通りでしょう。認めたがらないようだが。

> 違法ファイルを流通させたい奴はすればいい。

これが世界的に増えれば何かが変わるかも(w

�@何かの事情でA<->Bが切断しても、A<->C<->Bが存在していれば送受信は続く。
�Aキャッシュが分散することで、他の人が同じファイルをDLする確率が増し、
この時は切断などでDL完了できなくても、次でDLできる可能性ができる。
�BAが一人あたりのUL帯域を絞っている場合、2人分の帯域を使えるので早くなる。
�C転送経路が複雑になって、追跡が困難になる。
�D>>564
余りメリットぽくないのもあるが…

>>571
人に見せたいけど恥ずかしくて見せられないようなポエムは匿名で公開したいでしょ？
という建前

>>572
一度出来上がってしまったところに入っていくのは簡単だけど、最初がね…
ファイル検索アルゴリズムと一緒にうまいことやらないとだめだね。
最初だけnyみたいな感じにすべきか…効率めちゃくちゃ悪いけど。

>>571
でもその仕様だと、匿名性とはかけ離れているし、
根本的な開発コンセプトから外れてしまうのでは。

>>575
�@また接続すればいい。どうせならftpで直に交換しよう、変な接続も来ない
し、ということになる。
�A変な接続も来ないからキャッシュそのものがない。
�BBも帯域を絞るでしょう。持ち逃げされないように。
�C追跡が困難になる。IMでアドレス教えあったほうがもっと困難。
�D略

# 交換したら共有したことになるのか？と思ったりする。

交換じゃないっての。

ネットワーク上に全てのキャッシュが乗る＝共有って考えているが。

>>575
＞人に見せたいけど恥ずかしくて見せられないようなポエムは匿名で公開したいでしょ？
＞という建前
ポエムならBBSだけに匿名性を持たせれば良いのではないの？


>>576
開発コンセプトの「匿名性」と「ファイル共有」が違法ファイル流通を示唆しているよね。
スタートから違うんじゃないのか？っていう話のつもり。

完全匿名性のBBSと、条件次第で匿名性が無くなるファイル共有、この二つが両立できれば…

>>578
VlerhJc1の提示した仕様は交換に基づいている。AとBとでUPしあう合意が必要
だから。交換そのものだろう。

元ねたは、DOMノードか見極めるのに何かをDLしてみるという奴で、
練ってるうちに交換ぽくなった。

自分がDLしている相手を信頼してULするって考えると、
どうしても交換みたいな双方向性が必要なわけで。

Aが欲しがってるファイルが本当にAが欲しがってるのか、
間接的にCが欲しがってるのかって点で交換とは少し違う。

>>581
> 元ねたは、DOMノードか見極めるのに何かをDLしてみるという奴で、
> 練ってるうちに交換ぽくなった。

漏れは一見して交換だと思ったがな。今でも元の仕様は何も修正してないだろ
う。仕様が変ったんじゃなくて見方が変わったと思われ。

AがBのファイルを欲しい、BはAのファイルをいらない。Aの中継？いらん。と
なったら接続は成立しないだろう。成立するのは互いに欲しいファイルを持っ
ていて、その他の条件も合わせて合意したときだけ。交換だろ。

# 交換をいくらやったところでネットワーク上に全てのキャッシュが乗らないような。

持ち逃げされない方法考えた。
ダウン要求してきたノードにUPするときは、UPする側の秘密キーでそのファイルを暗号化。
UPノードはDL側になんかよこせ、無ければ中継して以下略。
UPのーどはDL側からなんかもらえたらDLノードに公開キーを渡す。
これでどう？

>>579
違法ファイル流通がないと人(ノード）が集まらないYO！
ｎｙBBSが人をあつめれて（それなりに）盛り上がってるのもそのおかげ。

Winnyで逮捕をきっかけに次の仕様決めてるのが
いつのまにかＤＯＭ対策になってるのが笑える
ＤＯＭ禁止なら逮捕不可能とでも思い込んでるんだろうか？

おい素人ども、何暴走してるんだ？、お前らが出しているDOM防止案は
匿名性が無くなる様な本末転倒な奴ばっかりじゃねえか。
お前らは>>255 の意見と同様、知らなかったと言えば何でも許されると
思っているのだろうが、 世の中そんなに甘くねえぞ。
他のノードは一切信用できない。だから完璧な防止法は無い。

本当に素人しか居ないんだな。ほれ、ヒントを出しといてやるよ。
考えられる対策は自己評価位だ。自分はこれだけアップロードしたのだから、
一定量DLするか一定期間が過ぎるまでファイルのUPや転送を
控えるという形位しかない。少なくとも自分だけは守ろうという形だ。
まぁ完璧ではないが、実装は楽で穴も少ない。勿論バグも少ない(これ重要)。

素人の浅知恵で複雑な工程を経るのが知的で最高と考えとるんだろうが、
挫折するだけだぞ。

ほんとDOMなんてほっとっけって思うよ。
いちユーザとしては寝る前に登録して起きたらファイルが落ちてたって使い方をしたいから
次期P2Pで望む仕様はつけっぱなしにしても安全ってのとｎｙと同程度あるいは以下ファイルが落ちてくればいいよ。

強制うｐにすれば参加しただけで全員逮捕も可能
おそらくそれが狙い
貢献度も記録されてるし

オープンと強制ＵＰの両立不可とおっしゃる方もいらっしゃいますが
私はオープンソースで行けると確信しています。そのためにはUP大域を
提供しないノードの排除が必須。その方法を皆で考えよう！

おいらの考えた事。
※ソース改変DOM対策
周囲が無貢献nodeをキックする方法で対処。
信頼情報から機械的に判断するだけでなく、手動での
悪評価が出来れば模造拡散も防げるかも。
しかし好評価できては不味い。クラックへの穴に成りそう。

※「貢献しないノードは切ってもIP変えてつなぎ直せば意味ない」問題
長くP2Pネットワークに貢献した者がクラスタの中心（おいしい所）に来るシステムを取り入れる。
今繋いだばかりだったり、信頼性の低いノードには転送役しか回さない。


さて、
匿名性を維持したまま、信頼情報をどう管理するべｗ

47氏がなぜポート０を採用したか考えよう。
ポート０排除しようと思えば簡単にできるのに
あえて採用したの何故？

MXみたいに張り付いて使うソフトでもないしマターリが基本のソフトになるんでしょ？
DOMにカリカリしてる人って24時間ずっとノード情報でもみてんの？
朝起動して仕事に行くとかそういう使い方がｎｙでもメインだと思うので常駐させても安全なようにしてよ。
DOM対策なんて実際大きな被害が出てから対策したらよろしい。それより匿名性のほうが先だろ。

別にDOMで深刻な被害なんておこらないだろ。

妄想ネタだけど。
ダウンまではかなりの時間を要するけれど
一箇所にデータ保存は行わない方式にしたらダメなのかなと。

ユーザーは自分のパソコンに任意に指定した固定領域を持ち
UP：ファイルは最低でも３ファイルに分割され各ユーザー自動転送をする。
これをUP者の指定した回数繰り返す。同時に転送先のファイルを自分に移す。
条件として同じファイルの断片は所持できないとする。

DOWN：指定ファイルの断片を他のユーザーから受け取るかわりに
自分がもっている近いサイズのファイルと交換、すべてそろえば
結合。Nyと違うのは、DOWN域と共有域を切り離して考える。

つねに断片ファイルがおいてある場所（ユーザー）は流動的に変わっていく。
ネット上に存在するマスターの数は減りはするが増えはしないのが変わらないのが特徴。
ダウンしたファイルをUPしたものについては別物と考える。

こんな感じです。説明不足なとこあると思います。文章下手ですみません。

必死でそれっぽいこと書いてるから皆気づいてないかもしれないが・・・
KD+7nkMKは過去ログもwikiも見てないと思うのだがどうよ？
>>565の「このスレの捕らえ方を根本的に間違えてないか？」が全てだろ

まずは単純で拡張性を持てそうな形(クラスで分けるなりプラグイン形式なり)でP2Pのソースだしてみたらどぉでしょう？
転送効率やトラフィックなどを調べる事はここならテスターいっぱい居そうだし良い環境ではないかと思うんです。
拡張性があればそこから匿名性を持たせたりDOM防止やらの機能を加えたり捏造対策をとったりの案がある人は
組み込む事が出来のではないかなぁと思ったのですが。
色々と見てると動かさなければ不透明って部分が多いと思えるんですよね。
それに形になってこそ見えてくる問題点もあると思いますので試しながら話し合うのも良いかなぁ？と思ったのですが

って仕様を決めるスレであって作成するスレではないんでしたね
スレ違いｺﾞﾒｿ

>>591はナイアルクラックが原因で主流がNY1からNY2に移行したことをどう考えてるのか。
今回トラフィック減少が止まらないのも、MX逮捕のときと比較すれば、単純に逮捕だけが原因とは言えず
NY2開発停止によるクラック版横行のほうが大きな原因と言わざるをえない。
>>591が「気にするな！」と叫んだところでユーザーが気にしている以上しょうがない。

>>596
NY２に流れたのはNY２が機能的にもｎｙ１より使いやすくなったからだろ。
それに急激にｎｙ１からｎｙ２に移動したんじゃなくて徐々にｎｙ２に移動してっただろ。
新規の人だってｎｙ２から使い始めるだろうし。だいたいｎｙ２でもクラック版あるだろが。
トラフィック減少っても2ヶ月前に戻っただけじゃねーか。それに判断するには早すぎ。
1ヵ月後どうなってるかで判断すべき。

>>594
抽出してみて分かった。こいつ反証してる風だけど論点ずらしが目的か。

>>597
DL板をヲチした限りではクラック騒ぎでNY1とNY2の地位が逆転している。
NY2のクラック版については作者が非互換アップデートで対処してきた。
事件からかれこれ半月だが、トラフィックは先週平日値より一段と落ち
いまだ右肩下がり。
http://www.mfeed.ad.jp/jpnap/fr-traffic.html

>>599
>地位が逆転している
よくわかるね
>トラフィック
だからもっと長期的にみろよ・・・
まだ逮捕が記憶に新しいんだからさ

ｐ２ｐのなまえをおまんこにするといいよ!!!！
みるまらー♪(　　　ﾟ∀ﾟ　)

まだ、ｐ２ｐ違法交換対策強化週間です。

スピード違反と飲酒運転には気をつけましょう。

むーむーです。
近いうちにＰ２Ｐネットワーク構築層(ＯＳＩ７階層でのネットワーク層相当)の
テストしてみたいのですが、協力してくれる人はどれくらいいますか？

今回のテスト参加者になると・・・
・参加者のＩＰリストは、調査すれば結局別の参加者にばれます。（隠しようがないです）
・まだファイル共有などは一切できません。
　（非匿名ＩＭと投稿者匿名ＢＢＳと簡易ゲーム位は用意します）
・各種の値が出力されるので匿名で報告してもらうことになります。
・ｎｙが使えるレベルであれば参加するのに必要な環境は用意できます。
・Port0も一応可能とします。

参加方法は、近いうちに wiki の方に用意します。（告知はこちらでもします）

>>447
ﾜﾗﾀ。ファイルが絶滅したらどうする!?

>>603 テスト開始は早くても来週です。
Perlのみ (もちろんオープンソース）で構築します。
オープンソースなので使用前にソースコードの中身を議論できます。

実行環境は、UNIX か CYGWIN とします。 (OpenSSL等も使用)
WINな方は CYGWIN を今のうちから準備して置いてください。
テスト時にCYGWINダウンロード負荷かけるのもアレなので。

どうしても必要なのは初期ノードです。
初期ノードになっていただける方に IP と Port を私の公開鍵で
まとめサイト掲示板にでも募集して、ある程度溜まったところで、
私が初期ノードリストとしてどこかに投稿します。
問題は初期ノードになった方のIPはリストからばれてしまうところですが。
ネットワークが構築されたら、初期ノードに使用したIP、Portは無くても
自立動作することになりますので、あとでIP変更できる人なら、それなりに
匿名性は保たれると思います。ご協力よろしく

>>605
お疲れ様です。是非参加させてください。期待してます。

A(Up)⇒B(中継)⇒C(Down)

ファイル共有は、例外なしに『B(中継)』を通過するものとし、
B(中継)はキャッシュしない仕様で匿名性は確保されないものか？

>>607
AからみてBが中継かどうかは絶対にわからない。
串か串でないかの判断が確実でないのと同様。

Bを中継として定義した場合の話だろ? 論点ずれてないか?

いっそのことWeb割れに戻すつもりでURLとその情報のみを取引する共有ソフトって言うのはどうだろう？

>>607
ただのルーティングだからBについては安全性は確保されるはず
（前提条件として自分が転送している事をBは知らない）
匿名性は微妙かも。B目立ち杉。
とここまで書いてて思ったのだが、Bが裏切り者だとﾔﾊﾞｲかも・・・？
暗号化すればいけるか・・・？

B=Cで

今思ったけど落としてるほうからは>>607でいうAはわからないんだよね？
Bから落としてるようにしか見えないんだよね？だとしたら
Bを訴えることは可能では？

>>613
中継している＝うｐしてるって言うことになるから中継者を訴えることは可能

Bは訴えられてもかまわない

>>614 じゃあ普通の串のように中継してるPCにキャッシュなど
データを残さないようにしたら？やっぱBから落としてるように見えるから
もし中継してただけでも家宅捜索されて他のものうｐしてるのがばれるかも。
結局は中継して匿名性をあげるのはあまり意味がないと

俺がCならB通さないでAから直接落とすよ。
その方が速い。
Aに中継だと言い張れば任務完了。

>611
キー交換にB以外のノードを中継に使えばおｋかな。
全体的なﾄﾗﾌｨｯｸも下がるかも。
（nyは実質BのｷｬｯｼｭからCへ送信するのでAB間で大量の
　ﾄﾗﾌｨｯｸが発生する場合がある）
ただし、拡散は遅くなる。

匿名性についての話なのに、なんで訴える話に論点ずらそうとするのかな。
純粋に匿名性を考えてくれ。

>>619
Bの身元がばれる時点で匿名性が皆無なわけだが・・・

>>603
簡易ゲームが興味あったり。

どっかからperlコンパイラ拾ってくるか…

A(Up)⇒B(中継)⇒C(中継)⇒D(Down)

>>618
FreenetのNGRパクってトポロジ考えた設計すれば、
多少トラフィックも良くなると思われ。
nyみたいに手当たり次第じゃ駄目だろなぁ

>>603
お前のアイディアってwinnytipsで話し合われてるのと同じようなものだな

>>625
類似情報があるならぜひ参考にしたいので、
情報元(URL、スレ名、検索語)など教えて下さい。

>>626
ttp://www.nan.sakura.ne.jp/cgi-bin/winny/bbs4/wbbs.cgi

ﾀﾞｳｿ以上の厨房板なんだがなー
ちょとだけ感動した

>>627
出す前に出されてた・・・(´･ω･`)


盗用なんじゃねーの？お前の意見

>>628
別に盗用でもなんでも良いじゃん。
このアイディアに著作権があるわけでもなし。

なにをそんなにあせってるのさ。

×　あせってる
○　アイデア貧乏

僕の常駐してるスレの意見が盗まれてる！ってか？ｗ

このスレはどんな意見でも有用なものは参考にして取り入れる。
俺の意見だ！俺が開発するんだ！って奴は自由にやればいい。
作者が特定されるのをなんとか防ごうってのがこのスレの基本スタンスなはず。

>>631
オープンソースでも著作権、財産権は認められてるからねぇ。
一言ここを参照してるよって言えばいいのに・・・


まぁ、別にいいけど

>>632
ソースにも何にもなって無いじゃん。
いいからROMっててよ。

>>633
何打この馬鹿？

ノードリスト管理ソフトを１時間ほどで仕上げましたｗ
ttp://fosae2003.tripod.com/
ソース付きですので、ご自由にどうぞ。
バグはこの板に書いてもらえば直すかもしれません。

>>634
いきなり著作権を持ち出す馬鹿に言われたくないなぁ。

彼の脳内ではすでに盗用で決定した模様です。

>>636
紙に書いたアイディアでも著作権、財産権は発生するんだよばか

>>638
著作者がそれを主張しなければ意味無いじゃん。
というか妄想はよそでやってよ。馬鹿なんだからROMってた方が良いよ。

>>639
親告罪っていえよばーか
お前こそ馬鹿だからROMってろ

>>632
ソース自体はパクってないでしょ
アイデアだけで。この辺は特許権の管轄。
よって著作権は関係なし。

ちなみに特許取られてないアイデア＝パブリックドメイン
と解釈してるんだけど、何か問題ある？＞法律詳しい方々

馬鹿の相手は疲れるネェ。

馬鹿A：ID:+jydtFhZ　vs　馬鹿B：ID:RmO6B7lr
　　　　　　　　　　世紀の対決！

>>641
(　´,_ゝ｀)ﾌﾟｯ

+jydtFhZからKD+7nkMK臭がします

どんどんいくよぉ〜

というか、簡易ゲームってなんだろう。
それが気になって仕方が無い。

盗用ニダ！

perlという時点で結果は見えてるわけだが

>>648
そのソースを見て、C++に移植は可能かなぁ。
しかし、バージョンアップとかについていくのは辛いね。

とっかかりは何でもいい。

このｽﾚは法律や権利や自己弁護を語るｽﾚではないんだけどもね
そろそろやめない？

そのまえにNG入りさせた方が早いか

早速ＤＬして実行せずにソース眺めてます。
[ServiceList.cs] に次のようなコードを見つけた。
　public enum ServiceList
　{
　　Winny = 0,
　　MuMu = 1
　}
MuMu って私の作る予定サービス名なのかな（ｗ
いろいろと参考にさせてもらいます。

Winnyだけだと、さびしかったんで・・・
むーむーさんのP2Pソフトをサービス一覧に入れようかなと・・・
かまいませんよね？

>>648
ここがプラットホームをwinに限定してる訳じゃないからじゃ？
ま、それにしても他に選びようがありそうだけど最初はなんでもいいでしょ
とりあえずperlで作れる言ってるんだから作って貰えば
オープンソースなんだし、後でどうにでも出来る

流れ上名前はMuMuに収束していきそうｗ
あ、スレ違いスマソ

>>649
私が作るプロトコルのサンプル(リファレンス)実装なので、
いくらでも別言語や別環境へのポーティングは可能だと
思います。（オープンソースってそいういうものですし）
ソースの著作権は私に帰属するけど、アルゴリズムや
実装で「特許」とか「ライセンス」とかを言うつもりありません。

私のアイデアは、MXの次スレの話題や変形RAID5方式、
あと、サンプルソース公開された 9+SOuN0S 氏のページの
内容を元に自分なりに整理しているものなので、模倣や
パクリと言われても仕方ないかもしれません。ですが、
GPL等のライセンス条項には関しては気をつけるつもりです。

>>656
盗用ジャン
最初に一言言えよ

まとめると

僕が常駐してるド厨掲示板のアイデアが盗用されてるニダ！僕の許可をとるニダ！

mumuワームは、BAT スクリプト、Win32実行ファイル、コンフィグレーションファイル、イニシャライズファイルのセットです。

含まれるファイルは悪意のあるプログラム、ハッキングツールと合法的なクリーンなファイルです。

ワームはパスワードをクラッキングすることによって、リモートシステムのアクセス権を得て、ファイル共有によって広がります。

ワームは辞書攻撃を使用します。例えば言葉のリストを運んで、そして共有アクセスのパスワードとしてそれぞれを試みます。

これが成功した場合は、全てのコンポーネントをコピーしリモートシステムでメインスタートのスクリプトを実行します。

ノード構築だけならば、ローカルで余裕でできるんだけどね。
一般テストはもっと完成度が高まってから普通するものだろ。

ちょっと考えてみた。

キャッシュの自動的な拡散。

自動拡散キャッシュ(以下ASC(AutoSpredingCashe))の仕様
・ASCには『送信に成功すると減る』寿命と『送信に失敗すると減る』寿命がある。
　(この点で、寿命のない通常のキャッシュとは区別する)
・ASCは寿命が尽きると消滅する。
・ASC単体は極めて小さいものとする(大きいと邪魔だから)。
・ASCを作成するのはファイル放流時のみ(増え過ぎると邪魔だから)。
・ASCは通常のUp,Downの際に、Down側からUp側にUpされる。
　⇒この時、Down側がUpできなければDOM認定。Up側からASCを貰って接続を切る。
・Down時に当該ファイルのASCを持っていたら、寿命を破棄して通常のキャッシュにする。
・万一、あるファイルのASCが全て揃った場合、通常の完全キャッシュにする。

広く薄く無自覚にファイルを拡散させるのが主眼。DOM対策とかはあまり意味ないかな。
二種類の寿命をうまく調節してASCを遍在させられるかが課題。

>>661
なんかに似てるなーと思ったらネタ元はテメロア？ｗ
キャッシュの遺伝子みたいでｶｺｲｲ

>>660
> 一般テストはもっと完成度が高まってから普通するものだろ。

一般にその主張は正しい。しかしおそらく、むーむー氏やこのスレの
住人にとって、開発の過程を楽しむことも目的の１つ。

DL板でこんなこと言うのもなんだが、
あまりにも著作権物や違法物にこだわりすぎてる感じがする。
そもそもインターネットってもんは見て欲しい人がUPしてるわけだし、
もっとソフトの面でUPしやすい環境を作ってもいいんじゃないかな。
例えばファイル検索部分とBBSを統合してお絵かき掲示板みたいにすれば、
自分がUPしたファイルの意見とか感想が聞けるしフェイクも弾ける。
お気に入りのファイルをUPして語り合ったり、ポエマーや絵描き職人もUPしやすくなる。
ファイル名だけってのはなんかブラウザ出る前のインターネットみたいなもんだな、
つー事はP2Pは第二のインターネットへの入り口？
2ちゃんから世界初のP2Pブラウザが出来たり……ってなにいってんだ俺は。

早く誰か作れーーー

アイデアは保護されない物ってのは聞いたことある。
著作物≠アイデアだったか。

アイデアなんて形にしてナンボだろ

>>663
というより、開発及び開発の過程が楽しいって方が100％に近い気が。
だから、時折出てくるただP2Pソフト欲しいだけファイルが欲しいだけの
「早くつくれ」「どうせ出来ないんだろ」って奴との温度差が激しいんだろうな。

クラスタによる最適化を検索文字や回線幅だけじゃなくて、
ネットワークレベルでしたらISPも楽なんじゃないかな。
TTLや逆引きのドメインで判断。
ISP間やバックボーン間の負荷でISPがまいってる中だいぶ負荷が減ると思うけど。

あと
Winnyであった暗号化を単に通信の秘匿だけじゃくて流通/配布の制限のために利用したら
どうだろう･･･、
簡単に言うとZIPにパスかけて流すようなもの。
金を払った人だけしか変換できないとか、流通時間に制限があって放流してキャッシュや
暗号化状態のものは二日に消えるとか。

露骨にファイル交換目的じゃなくてビジネスにやさしいアプリならなんとなく建前はよくなると
思うのは気のせいか･･･。

>>662
宇宙背景放射をイメージしながら、寿命を考えたらこんな風になりました。
結果はテメロアかも。

匿名P2Pと有機的なものって親和性が高いのかな。

×テメロア
○テロメア
ですぜ、兄さん。

なんか平和になってきたね。いいことだｗ

>>621 >>646
サンプルの簡易ゲームは、誰もがルールを知っているオセロに(勝手に)決定しました。
通信方式はサーバ管理タイプ(対戦相手が匿名)とＰ２Ｐタイプ(非匿名)の２タイプで、
コマンドライン(CUI)とブラウザ(GUI)と専用UIの３タイプ用意してみたいと思います。

オセロはだめ！　あれはツクダオリジナルがパテント持ってます。
よく似たものにリバーシブルゲームがあるので調べてみてください。

呼称の問題だろ、そんなもん

たしかにオセロはいかんかも。一応色々気をつけよう。

>>672
さらに３人以上で対戦できるような、ルールが簡単で実装も簡単な（ｗ
ゲームがあれば提案していただければ、検討してみたいと思います。
さすがにＰ２Ｐ上でＭＭＯは無理だと思いますが。（時間的にも技術的にも）

いや、ルールが違う。オセロは最初の盤面が

○●
●○

だけだけど、リバーシブルは

●●
○○

も選べる。これがないとそれはオセロとみなされてしまうので注意。

正直な話テストするのにゲームをのっけるん？ まだその段階じゃないやん。 まずは動くかどうか、匿名性は？負荷は？予想されない事態は？ それをためすのがさきじゃん。 いちいちゲームってのはどうなん？ つーかここまで来るとネタ？って思ってしまう

>>673 >>674 >>675 ご指摘感謝
（ソースコードの）ライセンスは守ると言った手前、調査不足でした。
そこらあたりは気をつけたいと思います。今後も発言チェック？や
ライセンス、パテント問題などのご指摘よろしくお願いします。

>>678
どうでもいいが上げるなよ。
それになんのテストかわかってんの？ソフトが出来てる訳じゃないぞ。
勘違いして焦ってるのはお前だがぜ。

一見無駄にみえた上の議論も役に立ったんだな

>>670
兄さんは悪くないっすｗ
悪いのは漏れ

>>676
魚雷ゲームなんて良いのではないでしょうか。
相手がどこに魚雷を撃ってくるか裏の裏をかいて潜水艦や艦隊を配置するのは結構燃えると思います。

プログラムも簡単だし、やってみてはいかがかと。

というか、漏れが個人的にやりたいだけかも。

>>678
ゲーム参加者募集サーバ、匿名維持の為の中継者依頼、対戦相手の匿名性維持、
Ｐ２Ｐネットワーク構築から、各種サービスを受信するまでの手順、盤面データや、
置いた駒(っていうのか？)やチャットデータの送受信、ネットワーク負荷はゲームでは
まだ無いと思うが、いろいろな可能性の検証ができます。

ご要望の共有ストレージ構築のテスト初めてからの大きな不具合やバグなどから
（いろいろな意味での）問題が見つかるよりは、ゲームやりながら検証のほうが、
私的にも設計による大きな問題発生を回避できるし、なにより私が楽しいので。

あと、駒を置いたというメッセージと一緒にファイル交換されているかもしれませんけど・・・

ゲーム云々、BBS・IM・ML云々ていうか、ファイル共有システムに
read()、write()みたいにヨソのアプリからシステムにファイル投げ込める
APIが用意されていれば良いだけの話だよね。

即答性が欲しいならnyBBSのみたいにガッチリとクラスタリング、
即答性が不要ならtxtファイルをローカルに吐いて、ゆっくり回収させるだけ。

ディープスキャン!?

>>676
ヒットアンドブロー（マスターマインドだと×？）とか。
3人以上でもやれないこともないだろうし、なにより簡単そう（ｗ

>>682
ひとりひとりが、巡洋艦艦長、潜水艦艦長、駆逐艦艦長などになって
複数チームに分かれて、海戦（陣取り、旗取り）をするのも面白そう
ですね。今のアイデアのままでは、既存のＭＭＯっぽいものなって
しまうと思いますが、Ｐ２Ｐならではアイデアがあれば、大きな可能性が
でてくるかもしれません。提案感謝

ライフゲーム希望

>>687
チーム戦てのは面白そうですね。
さすがにそこまで考えてなかった(汗

>>686
最初はそれ考えてました。既に実装ありますから。
でも「つまらん」とか文句ばっか来そうな地味なゲームですし、
画面的にも派手じゃないですし、なによりＰ２Ｐらしさを出す
アイデアを思いつかなかったので・・・。
まぁ、時間があったらサンプルゲームのひとつとして採用します。

出来れば今後ゲーム云々とテスト（報告とか）についてはまとめサイトの
掲示板でやってもらいたいです
一つの可能性を探ってる段階だし、むーむー開発スレになると色々ヤバ気

> ◆OCoDsLMMu2

1〜1000で好きな番号は何番ですか？

>>689
クラスタワード(どのように実装、採用するか未定ですが)同士のチーム戦だと、
チーム団結力や、戦略、戦術にクラスタの個性が現れて面白いかもしれません。

もう開発に入ってるんなら◆OCoDsLMMu2専用スレがあった方がいいな

ラグナロクオンラインみたいの頼むよ

「仕様を考える」の管理人さんみたいに独立してこのスレ準拠しながら
やられたほうがいいかも？んで、wikiにフィードバックで。

>>695
チミは大人しくラグナロクやってなさい

>>697
ﾊｧ？
なんで朝鮮人に金払ってまでゲームしなきゃなんないの？
ﾌﾟﾌﾟｰｰｩ

>>691 >>694
スレタイ「次期Ｐ２Ｐ仕様」になりそうな話題(ゲーム含めて)を振ってきたつもりですが
雑談？含めて最近４００発言中に私の６０発言ほど・・・　　ちょっとしゃべりすぎかな
本日はこれで落ちますので、専用スレたてるかは明日状況見て考えます。

>>699
専用スレはまだやめておいた方がいい
テスト始めてから建てるべき

2ちゃん内に専用スレたてるとドロシースレみたいになるから止めたがいい。
ネタスレ化してしまってこっちにもどんどん流れてくるかと。
テスト始めて、馬鹿が入りにくくなってからじゃないと。

>>692　３つ上げると999とか、777とか、333とかのぞろ目 (パチンコはやりません)

俺は立てちゃった方がいいと思うけど
テスト前に理解者を増やしとくって意味で
それとこのスレ占有するのもどうかと思うんで
まあ作者さんの判断に任せます

>>701
まったくだ。
馬鹿が多すぎる。

一定以上キャッシュが拡散しないと復号化できないようにするってのはどうだろう？
うｐ職人が放出した直後の拡散初期の狙い撃ちを防止して、うｐ職人のリスク軽減のために。

オプーンソースだと楽々解除だろ＞複合化できない

オープンソースでは、何かをプログラムで動的に制限する、といった類の制御は全てムダ。
同時ULDL接続数といったパラメータは、全て手動で変更できるものとして考えないと。

むーむーさんへ質問。

「健全」と「完全」の意味がわかりません。

・それぞれどういう意味なのか。
・それぞれ、何に対して「健全である」とか「完全でない」とか言えるのか。

あと、Wiki はいつでも編集できるので、時系列に読まなければ意味がわからない
文章を増やすのではなく、変更点があれば書き込んだ文章そのものを更新して
ほしいです。

それから、このスレで言う「信頼できるかどうか」の「信頼」って、どういうこと？

・プログラム自体をハック（変更）してるノードかどうか。
・私の好みのファイルをいっぱい持ってるノード。

それとも、もっと他のこと？

>>708
MuMuに聞かずに辞書引けばいいレベルに見えるのは気のせいか。

Wikiの「ストレージ上の共有ファイル」には、次のように書いてます。

> 健全な状態では、３つのパーツが完全状態で存在していることになります。
> この場合、ある完全ファイルが必要なら３つのノードからそれぞれの
> 断片をＤＬする事になります。

なので、3つのパーツが全部手元にあれば、それを健全な状態と言うのかな、
と思ったわけです。しかし、

「ストレージ健全化とノード評価」では、

> 共有ストレージ全体として、完全ファイルを健全な状態に保つ為にどのような
> 動作が必要かを説明しています。

となっていて、なぜ完全ファイルを健全な状態に保つために動作が必要なのか
がわからないです。

完全ファイルを健全な状態に保つために動作が必要なのであれば、
「不健全な完全ファイル」というものが存在しそうに思えるのですが、
それがどういうものなのかわかりません。

>>706
公開した人のキャッシュの被参照数がある一定値以上になったら
複合化キーをダウンロードできるようにする方法で実現できる。
制御するのはアップ側だからダウン側ではクラックしても無意味。

あまり意味のない機能のような肝するけどね。

>>707
暗号化＆分割して放流→復号化に必要な鍵は最後に放流

で、どうかな？

>>711
被った
宇津田氏脳

とりあえず過去ログ嫁ってことだな

>>710
君は根本的な考え違いをしている。

> > 健全な状態では、３つのパーツが完全状態で存在していることになります。

> なので、3つのパーツが全部手元にあれば、それを健全な状態と言うのかな、
> と思ったわけです。

　ちゃう。この場合の「健全」はネットワーク全体の健全性を指している。
つまり、キャッシュを即消ししたりしないようなマナーのよいノードが多ければ、
自分以外のネットワーク上のどこかに３つのパーツデータが保持されている
はずだ、ということ。
　マナーのよいノードが多い状態を指して健全と言っている。


> なぜ完全ファイルを健全な状態に保つために動作が必要なのか

　もう後はわかるよね。

>>708 >>710
単語説明不足が多々あり、また読みにくい文章になっていて
それでも、努力して理解仕様として頂いてありがとうございます。
私自身の仕様を思いつきと一部時系列関係なしで書いているので、
私以外の閲覧者がどのように捕らえてるか、わかりませんでした。
近いうちに、全体をまとめて整理します。お手数おかけしました。

基本的に「ストレージ健全性」「健全な状態」とは、利用者全体をみて
共有しているファイルが、問題なく復元可能な状態にあり、または
DL要求が多いファイルほど複製が多く存在している状態を指します。
共有数が極端に少ないファイルは、復元可能性が下がっているので
「不健全な状態」と定義し「健全な状態」になるように、複製を増やします。
共有ストレージとしては、パーツファイル状態の分散が前提なので、
あるひとつのノードに、ある完全ファイルを構成する複数のパーツファイルが
ある必要はないので、「不健全」ではないにしろ「健全」にもなりません。

あと「完全」という単語は、それ単体の本来あるべき状態を指します。
早いな話が、ｎｙの部分キャッシュのように一部が不足している状態を
さしています。「完全ファイル」「完全なパーツファイル」と使用しています。

長文説明スマソ。近いうちにスレ変えるか、別掲示板かwiki立てます。

盤面を広くして色数を増やせば、４人対戦リバーシブルが可能だ。

>>711
>複合化キーをダウンロードできるようにする方法で実現できる。

誰からダウンードするの？
最初に公開した人？いや、これは匿名性的にヤバイか。
誰だろ〜？

>>715 わかりやすい簡潔な説明サンクス。まさにその通り！
どうも私は難しい文章で、詳細に書いてしまう癖があるのでとても助かります。

>>717 盤面狭くてもクイズ機能を入れたら、アタック２５になりますね。

>>718
前スレで散々既出

>>705
うｐ職人のリスク軽減は、拡散効率の向上と、うｐ職人がUPファイルをすぐ引っ込めれば良いだけ。
信頼できるトリップ機能と「引っ込める被参照数」があれば良い。

>>716 思いっきり誤表記。誤解させたらスマソ。

> あと「完全」という単語は、それ単体の本来あるべき状態を指します。
こちらは正しい。
> 早いな話が、ｎｙの部分キャッシュのように一部が不足している状態をさしています。
不足しているファイルは「完全状態」ではなく、「部分的なパーツファイル」「断片化ファイル」です。

>>708
おっと、もう１つ質問があったのか。むーむー氏ではないけど、手を煩わせたく
ないので代わりに回答する。

> それから、このスレで言う「信頼できるかどうか」の「信頼」って、どういうこと？
>
> ・プログラム自体をハック（変更）してるノードかどうか。
> ・私の好みのファイルをいっぱい持ってるノード

　いや、主に

1) 放流主が誰か追跡しようとしている怪しいノード
2) キャッシュを即消しするなど、ネットワークのバランスを崩壊させかねないノード

の２種類が「信頼できない」ノード。
　1) はファイルの流通に荷担するのを嫌うので、2) と同じく流通に貢献しない
傾向がある。

　よって、「信頼できないノード」＝「流通に貢献しない、又はキャッシュを保持
したがらないノード」という解釈でいいと思う。
　そういったノードは単にマナーの悪いノードとも取れるが、追跡者の可能性も
あるので、取引するのは危険。

　きゃー、レスを書いてる間に落ちたはずのむーむー氏ご本人が！！
　偉そうに語ってすんまそん (;´д`)

ここまでの技術的な実装をユーザが理解できるか難しいなぁ。
前回の失敗を行かして、ダミーで題目は何か違う目的をだしてはいかがでしょう？
「ただのPtoPファイル共有ソフト」ではなく、
PtoPで行う分散開発環境とか。CVSのコミットのようなもので、
３つの分割ファイルをそれぞれ作って結合できるような形で。

何か大義名分が必要な気がします。

大義名分は言い訳に過ぎん。
そんな言い訳が社会に通用する筈が無いだろう。
47氏も低俗な奴で色々言い訳を考えて実践していた様だが、
結局どうなった？

また出た

よしよし盛り上がってきたぜｸｸｸ

だんだんわかってきた。

結局むーむーさんの案や、変形RAID５形式の場合、ストレージに対して
元ファイルの1.5倍の容量を必要とするぽい。

冗長化する事によって、なにが得られるのかがわかんない。

XORすることで、「著作権のあるファイルじゃなくて、別なものを持っているんだ」
と言いたいのかしら。

だとしたら、むーむーさんの案は、ABCパーツの各前方2/3部分が、ファイルの
内容そのままだし・・・。

単に、ファイルの「前半」と、「前半と後半をXORしたもの」を持っていれば
元ファイルの復元は可能。ビット単位、バイト単位でその作業を行えば、
かなり、通信される内容は元ファイルとは違ったものにできる。

1.5倍のストレｰジへの負荷というデメリットを背負い込んで、得られるメリットは何？

はぅぅ・・・今度はそうきたか。
どうでもいいけど、解説してくれたむーむー氏にお礼くらい書こうね。

まず、ストレージへの負荷が高い、というのは誤解。
３つのパーツのうち２種類があれば元のファイルを復元できるから、
データ密度は変わらない。つまりストレージ容量の無駄は全くない。

なのになんでそんな面倒な方式を取るかと言うと、
その方が「データ消失への耐性が高い」から。

・・・これでわかる？

>>731
> どうでもいいけど、解説してくれたむーむー氏にお礼くらい書こうね。

これは大変失礼しました。むーむー様ありがとうございました。

> なのになんでそんな面倒な方式を取るかと言うと、
> その方が「データ消失への耐性が高い」から。

ってことは、>>446 や >>452 と同じことを実現するための仕組みってこと？

> これは大変失礼しました。むーむー様ありがとうございました。

　・・・・・・。

　いろんな意味で素直やね。いや、別にいいんだけど(w


> > その方が「データ消失への耐性が高い」から。
>
> ってことは、>>446 や >>452 と同じことを実現するための仕組みってこと？

　うぅう・・・少しはかすってるかも知れないけど、話が違う。
　>>446 とか >>452 の話は、データの拡散速度に関する話。冗長化とは無関係。

ネットワーク全体で健全性を保つ仕様だとさ消したいファイルがなかなか消えてくれないんじゃない？
捏造ファイルやゴミファイルでも消滅しそうになったら補完しようと働くんでしょ？

>>734
確かに、むーむー氏の仕様には需要のないファイルの削除について触れられてないね。
広まり過ぎてるキャッシュの一部を消すとか、絶滅確定のキャッシュを消すのとかは
記載があるけど。

たぶん、これから追加するんじゃない？

ｍ氏たぶん素人だろ
好きなようにやらせとけ