TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
Google App Engine for java
Go language part 2
【コボル】COBOL不要論【ただのDSLだよね?】
ネットワークプログラミング雑談
Perlは10年後の2023年には消えてなくなる
【Alloy】形式言語による仕様記述【VDM】
ふらっと C#,C♯,C＃（初心者用） Part145
WPF(.NET4.x, .NET Core) GUIプログラミング Part24
【PHP】下らねぇ質問はここに書き込みやがれ 10
次世代言語13 COBOL Java PHP VBA Ruby

２ちゃんねる互換P2P匿名掲示板の実装を考える １


1 ：2014/04/23 ～ 最終レス ：2020/06/02
このスレは「P2P型の完全匿名掲示板はまだ出来ないの？」スレからforkして生まれました
2ちゃんの代替となる2ちゃん型掲示板をP2Pで実装してみようぜ、なスレです
名前が長いので若干スレタイは変えましたファイル共有ソフト等の話題はスレ違いなのです
origin：P2P型の完全匿名掲示板はまだ出来ないの？その4
http://toro.2ch.sc/test/read.cgi/tech/1390486453/
wiki
http://www34.atwiki.jp/p2p-anon/
[参考]
Tor（The Onion Router）のHidden Service(onionドメイン)Onionちゃんねる
http://xiwayy2kn32bo3ko.onion/ (Tor経由でのみアクセス可能)
Syndie - distributed forums
http://syndie.i2p2.de/
Freenet - P2Pコミュニケーションフレームワーク
https://freenetproject.org/
[関連するP2P掲示板ソフトウェア等]
新月 - P2P匿名掲示板
http://shingetsu.info/index.ja
P2P2ch
http://p2p2ch.web.fc2.com/
ちらしの裏
http://chiraura0.web.fc2.com/
alias
https://code.google.com/p/alias/
o2on
https://github.com/o2on/o2on

2 ：
CO2

3 ：
とりあえずchord実装しようと思う

4 ：
ええな

5 ：
とりあえず服を着ようと思う

6 ：
こっちでレスしておく。
>>http://toro.2ch.sc/test/read.cgi/tech/1398178816/32
ならopenにでもotonaにでもいけばいいんでない？
こんなトコ見る必要ない。
>>http://toro.2ch.sc/test/read.cgi/tech/1398178816/34
それはバックエンドにP2Pを使わないほうが良い理由にはならないな。
使わなくても良い理由にはなるかも知れんが、それだけでしかない。
>>http://toro.2ch.sc/test/read.cgi/tech/1398178816/37
適当なノードがその場限りの鯖として振る舞えばいいというだけで、中央鯖は不要。
そもそも鯖役ノードってのが厳密に定まるバックエンドかどうかもわからんけど。
>>http://toro.2ch.sc/test/read.cgi/tech/1398178816/39
P2Pが匿名なんじゃなくて、検証可能なクライアントプログラムが匿名性を提供するんだよ。
Torなりなんなり、匿名化の為のシステムを蔵側に用意させるなら結局インストールが必要。
HTTPの鯖蔵モデルだと、蔵が使うコードは鯖提供で検証不能なので、鯖がロギングし放題。

7 ：
>>520
C/C++ でまじめに malloc()/free(), new/delete の研鑽を積めばＯＫ
学習教材としては、独習C++中盤の山場にある「文字列クラス」の車輪再発明がおすすめだね

8 ：
>>7
そんな道具の使い方みたいな初歩的な話はどうでもよい

9 ：
とにかくアイデアを出すことが先決だ。
実装はバグだらけでも富豪的でも良い。
後は実装のプロがなんとでもしてくれるだろう。

10 ：
じゃあ、アイデア
完璧な匿名性を持ったP2P掲示板
ほら、あとは実装しろ。

11 ：
>>10
バイバイ

12 ：
P2Pにして匿名性を強固にしなかったら２ちゃんより酷くなるだろ
技術があれば誰でもトラッキングできる掲示板になると思うけどね

13 ：
2chみたいに中央集権型掲示板ではひろゆきとかJIMとか
管理人の権利の主張やら、独裁削除人やらなんやら色々鬱陶しい。
荒らしやネットワーク攻撃対策に関しては中央集権独裁的に行うのではなく、
個人主義、自由主義に基づいた設計にすべきだ。
（リストを作るのも自由、自動的に適用するのも自由という具合に）

14 ：
リアルの愚民どもや法曹・政治家共がゴチャゴチャ言い出すのも鬱陶しい。
リアルをせせら笑いながら自由にコミュニケーションできるネットワークが欲しいものだね。

15 ：
tor板でいいじゃん。

16 ：
>>15
torで通常の方法で掲示板を設置した場合は匿名であっても中央集権的になるだろうが。

17 ：
管理人や削除人が好き勝手出来る掲示板はダメだ。

18 ：
新月見るに需要があるとは思えない

19 ：
新月は匿名でも純粋なP2Pでも無いし、ツールも使いにくいからな。

20 ：
新月が過疎ってるのは作者が閉鎖的に運用してるからだと思うが。
新月が純粋なP2Pではないと言うならば、純粋なP2Pとはどういうものか？

21 ：
>>20
>閉鎖的に運用
作者の意向がネットワークに及ぶなら、それは自由なネットワークとは言えないね

22 ：
新月の持っておきたくないものを選んで手放せるシステムは良いと思う

23 ：
純粋なP2Pとは権威から自由であるということだ。

24 ：
でもIDはほしい

25 ：
例えば、誰もが(作者も含めて)同じ方法で平等に利用可能なソフトウェアがインストールされたサーバがあり、インターネット経由でしかアクセスできず、誰も近づけない場所に設置されている場合、その形態はp2pと言える。

26 ：
>>21
それはクライアントに依存すること。作者の意向に依存するのはどんなp2pソフトでも同じ。
新月プロトコルのようなものを作れば個人に依存することはなくなる。

27 ：
新月の作者は簡単に利用出来るように公開ゲートウェイまで設置してるし
閉鎖的な運用してるようには見えない
ただP2P掲示板の需要がないだけだろ

28 ：
需要はあるよ現に自分も使ってたしかしいかんせん使いづらい
ログの即時取得、2ch専ブラ対応、荒らし対策、携帯対応ぐらいやらないと

29 ：
>>27
以前は誰でもクライアントなしで閲覧できたが、最近はクライアントをインストールしないと閲覧できなくなっている。
理由は、P2P掲示板は2ちゃん型と比べて非常に重いということ。大勢からクライアント無しでアクセスを受けると簡単に落ちる。
確かにP2P掲示板は需要がない。
クライアントをインストールしないといけないし、常時接続での運用が基本でハードルが高い。

30 ：
新月自体には需要はないだろう
ただp2pってだけで2ch以上なところが何もないからな
p2p掲示版への期待だけで持ってる感じ

31 ：
DNS分散の実装が必要だってことなんじゃないか？
新月の中の人は実況を知らなかったんだろうな。
皆の表現が一致したりしなかったりするダンスのような所が実況の味なのに、
それが十把一絡のスパム扱いではどうしようもない。

32 ：
みなさんP2Pに求めているものがたくさんありますね。（悪いことだ言うつもりは毛頭ありませんよ）
自由であることは大事なことですが、それは哲学領域に取り敢えず留めておいて、実装では負荷分散と即時性の両立を狙うのが賢い落とし所ではないでしょうか。
考え方によっては、サーバクライアントモデルの拡張としてサーバ側を我々がP2Pで実現し、ふつうに何かのドメインに紐をつけて使っても立派なP2P掲示板ということになります。匿名性はやや犠牲になるでしょうが。
でも当分の間はクライアントをローカルで走らせるモデルが続くと思います。
自宅サーバをやってる人たちが使ってくれたら安定性に一役買ってくれそうなものですが、そのためにはこちら側からの良質なドキュメントなどの提供が必要だと思います。
そこも含めて開発できたらいいなと思っています。

33 ：
そういう事実上の切り捨てこそが一番の哲学なんだよ。
意見が一致したものから実装すればいいだけなのに、
最初に切り捨てから入るとゴリ押しに見えるのさ。

34 ：
P2Pはシステムの構造でなく、人の利用形態なのだよ。

35 ：
開発方針
フェーズ１．匿名性が高く汎用的なP2Pデータベース開発（分散ハッシュテーブルみたいな物？）
フェーズ２．掲示板の仕様とデータベースにぶち込むデータモデルを設計
フェーズ３．普及を想定した使いやすい閲覧ブラウザの開発

36 ：
>>35
それって段階の意味が全然ないよ。
確認しないまま実装すると確実に作り直しになって
折角作った意味がない場合にそれは必要なんじゃないか？
最初から２ｃｈ互換で匿名なのはわかっている以上、
その部分の完成を待ったり段階化する必要なんてサボる口実でしかない。
いいのがでてきたらいつでも差し替えられるようにすれば済む話だし、
むしろ好みで選択できたほうがいいでしょう。
必要なフェーズと言えば、こんなこともあろうかと的な応用にも対応できる
汎用仕様を作ることだけど、これも別になきゃ作れないものではないし、
適当に作ったものがデフォルト化する方が多いよね。

37 ：
>>36
＞それって段階の意味が全然ないよ。
＞確認しないまま実装すると確実に作り直しになって
＞折角作った意味がない場合にそれは必要なんじゃないか？
＞最初から２ｃｈ互換で匿名なのはわかっている以上、
＞その部分の完成を待ったり段階化する必要なんてサボる口実でしかない。
ウォーターフォールモデルとアジャイル開発の対立みたいだw
あまり厳密に設計すると融通が利かなくなりそう。割りにゆるく、それでいて引き締まった設計にしたい。
ただ、2ちゃん互換ってのは大前提になると思う。
＞必要なフェーズと言えば、こんなこともあろうかと的な応用にも対応できる
＞汎用仕様を作ることだけど、これも別になきゃ作れないものではないし、
YAGNIって云うよね。今必要でない機能は今は実装しなくていい。必要になった時に実装する。
ゆっくり改良していけばいい。
ただ開発者が足りないような感じもするなあ。個人的には一人じゃ寂しいなあと思うw

38 ：
モジュラーを意識しよう
Golangでやろうぜ

39 ：
go言語？一人でやってろ。
みんなで作ろう系はC++かJavaだろJK

40 ：
>>39
お前が勝手にやってろよ化石

41 ：
P2Pって言葉がもう時代遅れで実体に合わない感じだな
有志による鯖のクラウド化をしたいと言う方が正しい感じがする

42 ：
>>40
go言語とC++のユーザー数の違いは分かりますか？オタク君

43 ：
>>41
その方向性でいいと思うよ

44 ：
>>41
AmazonEC2借りて従前の2ch鯖立てるだけでもクラウド化なわけだがｗ

45 ：
もちろん、そんな物作ったって、既にopen2chやひろゆきの新2chなどがあるわけで
何の新規性もない。

46 ：
個人的な想いですが、大きな震災が発生してもアクセスに耐え、ノードの急減に耐えられるようなシステムにしたいです。
TCP/IP自体がある程度の耐障害性をもって設計されていますし、アプリケーションがこれに応えることも悪くないと思うのですがどうでしょう？

47 ：
>>44
おーぷんやｓｃはAmazonEC2じゃないだろｗ
だがある意味それで十分な利用者もいるんだよね。特に2ch.scの方は非常に鯖が脆弱だから。
1. 鯖の堅牢性
2. 匿名性
3. 荒らし対策
2.と3.を両立させるのが難しい。P2Pにしたところで、第三者による追跡が可能になる訳で2.が保証される訳ではない。
ぶっちゃけtor板が大規模クラウドのvpsで提供されていたら匿名性と堅牢性の両方で申し分無いんだよね。
おもしろくないけどｗ

48 ：
>>47
仮にvpsにしてもtorにしても匿名性に関する危険性は現2chと同じ。
torに関しては鯖の所在を秘匿する手段としては使えるが、
情報漏洩の危険性は依然として残っているから、
現状より匿名性が高いとは言えない。

49 ：
さらに、管理者の裁量が大きすぎることも問題。
管理者が閉鎖したいと思えばいつでもできるし、
気に入らないレスを管理者が如何様にも操作できるという点も問題だ。
特別に大きな裁量を持った人間を置くべきではない。

50 ：
結局、有志によるクラウド化に意味が出てくるわけだな。
torの匿名性が2chと同じってのは意味がわからんがｗ

51 ：
>>41
申し訳ないけれども，「クラウド」はサーバーの存在を前提にしている時点で（現時点で最先端だとは思いますが）未来的ではないと考えています．

52 ：
p2pと言ってもデータを持っているノードは常時接続でないとそのデータが利用できないので、実質的に鯖が存在するのと同じことだと思うが
鯖の存在を意識せずに利用するためには大規模なノードの参加によるデータの冗長化が前提になる

53 ：
>>41
まだ存在しない実体を適当に語られても困るんだな。
そういうクラウド実装を出してくるなら話は別だけど、
ただ、スレタイと実装が合わないなら結局2ch的には
スレ違いか乗っ取り扱いだろうなあ。

54 ：
>>52
DHTを実装するならノードの起動や終了に伴ってデータは自動的に移管されます。
少なくとも今書いている実装ではそうなっています。異常終了でない限りは。
完全にノードが0になればデータ消失のおそれがありますが、それは他のいかなるP2P掲示板でも生じうる事態ですし、誰かが予備を立てることで対処するとしましょう。
あと、素敵なIDですね。

55 ：
匿名で利用できるDHTができればファイル共有にも使える。
ファイル共有なら常時稼働するインセンティブになるからね。
そのネットワークに掲示板を間借りすれば良いというわけ。

56 ：
https://github.com/nictuku/dht
Go使おうぜ
https://github.com/laher/goxc
Write once, runs everywhere in native executableだぜ

57 ：
今の乏しい理解の時点では DHT には否定的だな‥
参加ノードが時々刻々と変化するなかで、ハッシュ値に対してどのノードにキャッシュを置くのか？どのノードからキャッシュを取るのか、疑問は尽きない‥
第一、単純な DHT だったら、ある投稿単位を得るために、その投稿単位を所持しているノードに集中的にアクセスが集中するのでは？
それとも理解が足りないのか？

58 ：
うわ、、、ここにもqzいんのかよ
邪魔だから消えろ

59 ：
>>58
やだ！

60 ：
面白い感じに開発者が集まってきたな
俺もコテ使おうかしら、しかしほんま最近仕事忙しくて何もできてない

61 ：
sourceforgeでやれ

62 ：
最近はGitHubでやるのが普通な模様

63 ：
オープンソース？

64 ：
>>57
私の実装の範囲で説明します。
＞参加ノードが時々刻々と変化するなかで、ハッシュ値に対してどのノードにキャッシュを置くのか？どのノードからキャッシュを取るのか、疑問は尽きない‥
≪キャッシュ≫の意味がよく分かりかねます。
仮に≪DHTに保存されたデータ≫だとしてお答えします。DHTのアルゴリズムとしてChordを採用した場合、データに対して保存ノードは自動的に決定されます。詳しくはChordについてご参照ください。
＞第一、単純な DHT だったら、ある投稿単位を得るために、その投稿単位を所持しているノードに集中的にアクセスが集中するのでは？
現時点の私の実装ではその通りです。
回避策として、多重にハッシュ関数を適用することによるラウンドロビンが考えられます。（Chordを用いているとします）
通常ではDHTに保存されるデータ:Vのアドレス:Kは、ハッシュ関数:Hを用いてK=H(V)として決定します。
ここでK[n]={H(V), H(H(V)), ... }で表せるように複数のアドレスを生成し、それぞれのアドレスに対応する複数のノードにデータを保存します。
データを読み出す際は、Kに上原付でランダムな回数だけHを適用し、得られたアドレスにデータを請求します。
これによりネットワーク負荷は分散されますがストレージの負荷は全体として増加します。
掲示板の機構とDHTの機構とは分離されるので、掲示板側からはこれを意識する必要はありません。
今考えたアルゴリズムなので瑕疵があるかもしれません。ご了承ください。

65 ：
>>57
キャッシュって言葉からしてny系P2Pに毒されすぎだよ。
DNSの浸透(≒DNS設定ミスによる不具合の別名)みたいな状態はムダでしか無い。
DHTの場合(例えばKなんとか)、データを保持するノードに到達するまでの距離が自動的に定まるし、
アクセス数の多いデータは複製数を上げれば集中が緩和されると同時にアクセス時間も減少する、筈。

66 ：
>>55
使えてどうするのさ？
この板で作るなら開発者の為のソース共有辺りはあっていいけれど。
掲示リスクが増えたら掲示したい奴が余計減るよ。
別に常時じゃなくたっていまどきの雇用と同じでどうにでもなるだろ。

67 ：
思い思いに勝手な理想を語るだけで動く奴は一人もいない。

68 ：
ライセンスの不備とIDが致命的なんじゃない？
実はレスのまとめを作るのさえ自己責任の同人扱いで要はfreeがないんだ。
人が集まっているのが２ｃｈのメリットなのに、IDのせいで住人層の薄さがハッキリでてしまい
ギブアンドテイクの期待ができない。
一般的にID識別というのは信用の為なのに、24時間という中途半端な期限では何の信用も積めないし、
積んだところでそんな釈迦に説法するのは敬遠されてしまって本人のトクにはならないね。
効果としてはレス待ちゲストによる気まぐれ支援を自粛させて瓢箪から駒の望みも奪ってしまうだけで、
互恵関係構築には全く役立たない欠陥品なんかを有難がるストーカー御用達って感じ。
自分にメリットがあると思えなきゃ誰も（書き込み）しない
という誰でもわかる基本を何故か皆忘れちゃってるんだよな。

69 ：
違法な書き込みのリレーノードになってて警察が家にくる可能性のある掲示版を誰が利用するんだ

70 ：
>>69
キャッシュしない仕様であれば家宅捜索する意味が無いので、
裁判所は礼状を出さないよ。

71 ：
テキスト情報共有ソフトなのだから
サイズが小さく、多くの複製を置くことができるから
あまり読まれないスレも素早く読めそうな気がするが

72 ：
>>68
＞ID識別というのは信用の為
違うね、そのためにはすでにトリップがある。
君の説だと全員に強制的にトリップをつけることになるが、そうなると本当に誰もこなくなるだろう。
ID反対意見としては、今ひとつ説得力がない、もう少し脳細胞を使ってくれ

73 ：
>>72
一般的なID識別の話をしてるのに２ｃｈ限定の用語と混同されても困る。
トリップは後付けの機能で昔は無かったよ。

74 ：
>>68
＞実はレスのまとめを作るのさえ自己責任の同人扱いで要はfreeがないんだ。
Creative Commonsにしてみたいですね。
＞ギブアンドテイクの期待ができない。
＞
＞一般的にID識別というのは信用の為なのに、24時間という中途半端な期限では何の信用も積めない
＞自分にメリットがあると思えなきゃ誰も（書き込み）しない
＞という誰でもわかる基本を何故か皆忘れちゃってる
個人的には登録制にすれば内容の質は上がると考えています。署名付き専用板などを作って棲み分けるようにしてもいいと思います。

75 ：
連投ごめん
匿名な掲示板は次のステージに進むべきではないのかと感じることがある。
匿名でも一定の品質が得られた時代は終焉し、ネット利用者の増加に伴う2ちゃんねるの利用者の質の低下が起こりつつある。
匿名は人間を無責任にする。
一度匿名での書き込みができれば、利用者はそれをさも当たり前だったかのように錯覚してしまう。
限られた人のみが使える匿名掲示板なら高い品質を確保することができたが、あらゆる人間が集まる場所で匿名での書き込みに品質を求めるのには無理がある。
初回起動時に自動で電子署名を作成し、電子署名がついた投稿を最初からするように設計すれば、それが当たり前にできるんじゃないかな。
明示的に署名を作る手間があるからそれを意識してしまうんだ。

76 ：
品質とかそういうのは広告屋の発想だよ。
そんなものは利用者は求めていない。
千に三つ役に立つものがあれば、それは良スレだ。

77 ：
2chの全盛期を知らない人かな。
2chは昔、もっと人口が多かった時代のほうが高品質なレスが多かったよ。
その後、運営がデタラメな規制を繰り返した影響で大きく人が減って、質が落ちたんだよ。

78 ：
単に人が減っただけなら消化速度が落ちるだけで質は変わらない。
よくある過疎スレだよ。
見捨てられるから質が落ちるのであって、その判断をさせてしまうのがIDだという事。
そもそも削除判断用だからね。

79 ：
ネット利用者は増加してるけど2chの雑談系板以外の書き込み数は全盛期の半分以下まで低下してる

80 ：
で、こんな内容がプログラム技術板でやることか？
VIPでやったほうがまだましなんじゃないの。

81 ：
>>79
利用者減ってるのか。
運営のせいか、時代の流れなのか。

82 ：
江崎浩のP2P教科書を斜め読みしてると、P2Pの既存実装、ツールキット、テスト環境があることがわかった
（既存実装は自明だけど・・・）つまり誰かが車輪を作りまくって置いてることになる
【BambooDHT】
http://bamboo-dht.org/
分散ハッシュテーブルの研究で作られたソフトウェア、安心と信頼のMIT製
【OverlayWeaver】
http://overlayweaver.sourceforge.net/index-j.html
オーバーレイネットワークアプリを３層に分けて、それぞれ差し替え可能にしている開発ツールキット
階層０：ルーティング（Chord, Pastry, Kademlia...)
階層１：高レベルサービス（DHTとか）
階層２：アプリ
これはどの程度使えるのだろうか・・・
【PIAX】
どちらかというと車載機器や携帯機器への実装を目指してるプロジェクト？
低レイヤな部分でlibjingleとか使ってるっぽい
阪大製

83 ：
OverlayWeaverはP2Pで通信するアプリケーションを”オーバレイ”ってひとくくりにしてるぐらいだから
なかなかすごいプロジェクトかもしれんね、ゲーム開発ツールキットで言えばUnityみたいなもんかな

84 ：
知ってるからいちいち紹介しなくていいよ

85 ：
使ったことないけど新月はなにがいけないの？
自分的にはp2pにこだわりすぎてるからじゃないかと思うけど
これをサーバーからでも閲覧や書き込みしやすいようにすりゃいいんじゃ？

86 ：
>>84
別にお前個人に教えてやろうと思って書いてるわけじゃないだろ。

87 ：
>>65
DNSの浸透、のほうがいいかもしれないよ
DHT の場合データが取得できない場合がある、所持しているノードが起動していなくてね
ファイル共有の場合は、そのノードが参加するのを待てばよいが、掲示板の場合はどうかな？
>>64
chord 調査中です。

88 ：
>>85
P2Pというのはサーバ兼クライアントなんだから、こだわりすぎというのは意味不明。
過去ログ読まない貴方には向かないかもしれないけれど、
大事な事でも一度書かれれば充分な>>84なんかには新月も悪くないだろう。

89 ：
>>87
DNSの浸透は設定ミスでTTLが延長される等のクソ環境の言い訳だし(故に浸透言う業者は無能な可能性が高い)、
そんな「データの伝達経路がぶっ壊れてるけど運がよけりゃデータ読める」状態を意図的に作ってどうすんだって。
DHTでは最悪のケースとしてデータ所有ノードが全て断線しても「ファイル共有の場合」の状態を再現できるし、
通常の場合は断線するノードが出たり明示的に切断する場合に複製数増やして最低データ保持ノード数を確保するだけ。

90 ：
大抵のDHTアルゴリズムには、特定のノードが退出してもそのノードの担当範囲のデータが消えないようにする仕組みがあるよ

91 ：
>>90
＞特定のノードが退出してもそのノードの担当範囲のデータが消えない
詳しく
投稿単位AのハッシュH の結果H(A)でノードBを特定し，そのノードBが実際に投稿単位を持っているノードCを保持しているんだね (Chord)
じゃ，特定のノードBが前触れも無くいきなり退出（P2Pではよくあること）した場合は， C のことを知っているノードはいなくなるのでは？

92 ：
まず、DHTでは基本的にデータを複製していく点に留意。
>>91の例の場合、ノードCからノードBへ投稿Aそのものがコピーされる。
どのノードが持っているか、という情報を転送していくのはWinny方式だから勘違いせぬよう。

93 ：
DHT上に保存したいデータをA、そのデータのハッシュ値をH(A)、Aを担当するノードをNとする。
取り敢えず、自分の知ってるChordとKademliaってアルゴリズムを例にする。
Chordの場合、Nはその前(ノードID的に)のノードN'、N''、…へAを複製する。
円状のネットワークを構成するアルゴリズムだから、Nが抜けると(例えば)N'が次のNになるので、Aは消えない。
Kademliaの場合、Nに近い幾つかのノード(N自体が入っているとは限らない)へAをばら撒く。
各ノードは、定期的に自分の持つデータをNに近い幾つかのノードへばら撒く。
Aを取得する時も、Nに近い幾つかのノードにリクエストを送る。
データはひたすら複製されていくから、いずれかのノードが抜けても問題ないワケ。
円状のきれいなネットワークを構築するChordに比べると力技っぽいけど、実装が簡単らしいね。

94 ：
>>91 >>92
どちらの実装もあり得る。
大きいデータとかファイル共有だったらDHTの担当ノードに直接データを持たせるということはしないだろう。
掲示板のデータはそれほど大きくないし、新しいレスが素早く反映される必要があるから
担当ノードが直接保持するべきだろう。

95 ：
まじかよ
コンテンツをDHTに直接入れてる実装って現時点で存在するのか？
おれは知らん

96 ：
>>93
なるほど、ハッシュ＝ノードID のサイズが 160ビットならば、ノードIDをローテートして生成されるノードID群で持ち合うんだね
あとはノードIDの決め方だけれども

97 ：
DHTに直接データを置くのではなく、一旦メタデータを置く事が主流であるようですが、間接配置（他に正確な呼び名があるならそう読み替えてください）のメリットは何でしょうか。
私には大きなファイルの分割による負荷分散ぐらいしか思いつきませんが、他に何か応用があるのかな？

98 ：
というか直接配置の実例があるなら提示していただきたい
参考にするから

99 ：
あ、いま思い浮かびました。連投をお許しください。
荒らしがいるとします。彼は大量の無意味な投稿をするのですが、これを直接DHTに配置すると多大なネットワーク負荷が発生します。
間接的にアドレスだけを配置し実体を投稿したノードに持たせれば、無駄な負荷を発生させずに済みます。
ただ投稿ノードが抜ける時に結局データの移動が起きてしまいますが。

100 ：
だめだこりゃ。ちゃんちゃん。

101 ：
>>97
P2Pはノードの出入りが激しいから
DHTで大きいデータを直接配置すると
出入りの度に大量のデータ転送が必要になるからとても非効率
ファイル共有だとファイルをダウンロードするノードとDHTの担当ノードは
異なるのが普通だから、間接配置にならざるを得ない。
>>98
CREAの掲示板はDHTの担当ノードが管理する方式だったから
担当ノードが直接保持していた。
ちなみに、動画ファイルはもちろん間接配置だった。

102 ：
ここは帯域の無駄でしか無い中継をやらない
まともなP2Pスレってことでいいの？

103 ：
>>101
実装できるんだ
パフォーマンスはどんな感じなんだろう

104 ：
>>103
それが作った自分も分かってないんだよｗｗｗ
そもそも自分がP2Pを作ったのってP2Pシステムのテストをしたかったっていう
個人的な理由があったからなんだけど（その他にも色々理由はあったけど）、
P2P掲示板を作っても誰も使ってくれないから全くデータが取れなかったｗ
で、動画共有機能を追加したら多少はノードが増えると思っていたんだが
それでも全然増えなくて、これはいったん止めにするしかないわ、となった。
そんな訳で、直接配置でどれくらいパフォーマンスが出るのかはよく分からない。
ただ、10ノード程度で動いていたときはDHT絡みで特に問題はなかったと思う
（繋がらないノードの扱いには結構苦労した記憶があるけど）。

105 ：
インフラが整ってきたせいで
P2Pの必要性が減ってきてしまったからね。
動画配信はP2Pの出番のように
考えられていた時期もあったけど、
今や個人が無料で配信できてしまう時代。
P2Pよりも優れていて、すぐに再生できる
アップ者はアップが終わったらネットに繋がなくていいといった
メリットもある。この点でP2Pを超えてしまっている。

106 ：
作るやつがいないものをいくら議論したって無駄だろ。

107 ：
>>104
なるほど
でも使える可能性があるわけだね
これは光明か
多分人が集まらなかったのはプラットフォームの限定と広報不足では
個人的にBitTorrent Liveの実装が早く見たい

108 ：
CREAのひとだったのか
匿名にするなら実データをバケツリレーでポストしないと誰が書いたかバレバレになるよ

109 ：
匿名にする必要ないだろ。

110 ：
>>38
golangみたいな今日明日にでも消えそうな言語で開発とかｗｗ

111 ：
goはいい言語だと思うけど「俺がgoで作ってやったったｗｗｗ」ぐらいじゃないと使うことにはならないだろうな

112 ：
>>95
でかいコンテンツを直接格納するとそのキーを割り当てられた奴が悲惨なことになるから、
格納するデータをメタデータや十分に分割した物する実装じゃないと実用にならないんじゃないの？
>>96
前スレでChordかなんかでの一例は出てたね。クライアントが制御しきれない情報(例:IPアドレス)のハッシュ＋α
>>98
ビットトレントのDHT(Kademliaだっけ？)はトレントファイルを共有してた筈だけど、
トレントファイルをコンテンツとみなせば直接格納には該当しないかな？実装知らんので詳しく分からん。
>>102
匿名化って目的のために帯域を消費して中継してんだから、無駄ではないだろ。
あんまりスマートではないけど、だからって「まともでない」って判断はどーかと。
匿名性が必要か否かは別の議論。

113 ：
>>112
1キーあたりのデータは例えば1MBみたいな制限を加えるべき。
１キー１掲示板みたいな極端な事をせず、１キー１レスぐらいで設計すべきだね。

114 ：
>>113
だね。2chのスレッドは1スレッド512kBいかない程度な事も多いから、スレッド単位かレス単位かは悩ましそうだけど…

115 ：
google app engineの仕様では1キー1MBだから、それに合わせてもいいね。

116 ：
DHTで掲示板を作る事自体は簡単なんだけど、
問題は、P2Pではピアが信用出来ないので、
改ざん耐性を高める必要があって、どういう設計をすればよいか、なんだよねぇ。

117 ：
つまり、自分が所有するピアのデータを自分自身で書き換えられないか、
書き換えた事が検出可能な設計にするにはどうすればよいか。

118 ：
複数のソースをゲットすればいい
別ルートからのデータを比較して同一じゃなければ改ざん認定
正しいのがどれか判別する方法は知らん

119 ：
データと書いたがハッシュね

120 ：
確率論的には3つのうち1つだけ違っていたらそれが改ざんとしてしまってもいい

121 ：
あと、掲示板のレスの順番は正確でなければならないが、
ACID（atomicity, consistency, isolation, durability）をどうやって保証するか。
P2PのDHTでのACID保証について議論したい

122 ：
>>121
実際の処理はユニークIDで処理して、UIに番号で表示すればよい

123 ：
P2PでACIDという発想がどこから出てくるのか

124 ：
>>123
P2Pというか、分散DBの類だからこそACID意識するんじゃないの？

125 ：
>>122
ユニークなキーを振るのは当然として、
どうやってレス番1の書き込みとレス番2の書き込みの順番がわかるんですか？
書き込み時間にしたって、ピアの時計が正確とは限らないわけだし。

126 ：
レス1の次に書き込まれたレスは、必ずレス2にならなくてはならない。
これを保証するにはどういう設計にすればよいのだろう。

127 ：
>>125
別ピアのUIの表示番号が違っていて良い
内部で整合性がとれていれば
めんどくせえ

128 ：
レスが改竄されないことを前提とすると
レス2にレス1のハッシュ値を添付しなければならないようにすれば
少なくともレス2がレス1より前に存在しなかったことは保証できるな
レスが改竄されない方法は知らんｗ
掲示板のためにproof of workを使うのはコスト高すぎだろうしなー
まあ、多少順番が狂っても別にいいと思うけど

129 ：
必ず分岐が起こるがその場合どうするのか？
単純にタイムスタンプで同期させると改竄が容易になる。
改竄に対しては多数決で改竄防止という話が出ているが、
そうすれば新規書きこみは全て捨てられることになる

130 ：
レスの順番なんてどうでもいいだろ
本当に必要な場面になったら、後から安価して順序を説明すりゃいい

131 ：
順序の制御は無理だろう
>>127 のいうとおりだ、UI に渡すときに整合性が取れていればなんら問題ない、そのためにアンカー先を別途探しにいく実装があってもよい
アンカー先探しをあきらめる条件をどうするか、だね

132 ：
レス順が変わるのはスレッドが分岐したときの副作用で、この分岐には適切に対処しないと改竄スレッドを流されてしまう穴になる
書きこみを複数のノードに投げて、最新スレッドの取得同期は多数決にすると最新投稿が捨てられる可能性が高くなる

133 ：
改竄は防げない前提で考えたほうがいいんじゃないの？
された場合にどうするかを考えたほうが現実的な気がする
例えば、他の人とログを比べて改竄されてそうな場所をピックアップする機能とか
改竄してまくってそうなやつをブロックする機能とかあればいいんでない？

134 ：
内容に不一致があればそれ以降はフォークとみなすしかないんじゃね

135 ：
ワーキングディレクトリに他のノードからの更新を受けておいて、
そこから手動で自分のログに指定したレスをプルする。
こうすれば常に綺麗な状態は保てるんじゃない？
プル地獄になりそうだけど

136 ：
私の実装ではレスごとに固有のIDを与えて内部で自動変換していますね。
見た目が変わらなければどうということはないです。

137 ：
レス番は投稿情報のハッシュ(仮にレスIDとする)とかにしとくと楽だわな
>>128
レスを識別する情報(レスID)をそのレスの全情報のハッシュにしとけば、
強衝突性を突破しない限り同一レスIDのレスを捏造することは阻止できる。
全コピーの削除はネットワークの規模と複製回数で頑張ればいいし、
不正な投稿(といっても問題なのは未来や過去のタイムスタンプ位か？)さえ防げればいい。
>>129>>132
直線構造に拘る必要はなくね？ツリーでも一方向メッシュでもそれなりの順序は持つし。
基本は直線で、分岐見つけたら全ての先端のIDを添付して合流させてけばいい。
表示順は原則タイムスタンプ順で、あまりに古いレスID使って伸びた枝は閲覧時に警告を付ける。
本格的にチェックしたいなら信用できるタイムスタンプサーバを借りて部分的にP2Pをやめる。
>>133
プロトコル的な攻撃の話って、攻撃→防御じゃなくてバグ→攻撃の順で考えたほうがいいと思う
というか既存投稿の上書きな改竄は、異なる内容のレスを別のレスとして扱う実装だと無意味になる
元の投稿消したデータ群渡されても、元の投稿を含むデータ群読んで差分を挿入して終わり
元の投稿を持つやつ全員が結託して抹消しない限り、そいつと接触できれば直ぐ復元できる

138 ：
特定のレスをNGにして、自分ノードではやりとりしないっていう機能も必要だね
薬売買とか個人情報のやりとりあるレスは持ちたくない人いるでしょ
手動でNGに入れるのも面倒だから
つまり共有NGみたいなものが必要になるのか？

139 ：
>>138
いちいち本文チェックなんてしたらクソ遅くなるわ
キャッシュと同じ扱いでいいだろ

140 ：
なんつーかツリー型サーバーでしか出てこない様な概念を持ち出してくる奴なんなの？

141 ：
レス順が変わることの本質はスレッドの分岐で、それをマージするときにノーチェックでやるのか？ってところがポイント
ノーチェックだとレスを自由に増やせると思うけどね

142 ：
そもそもどうして投稿をマージして、しかもそらを再送出する必要があるんですか。
その都度自分が表示できるレスを集めて表示すればいいじゃないですか。

143 ：
>>140
データの最小単位が伝達する経路自体はツリーになるけどそういう話ではなく？
>>141
極端な話ネットワークが二分割されてから結合した場合はマージせざるを得ない。
分岐してマージされたレスは異常状態(ログ破損に近い状態)としてマークしといて、どう処理するかは各自自由とかでよくね？
表示順としてローカルでの取得順かタイムスタンプ順かも選択したい人は居るだろうし。
>>142
この場合のマージはレスにつけるメタ情報から構成されるツリー(チェイン)のマージだから関係ないかと。
スレを意味するブロックにレス番情報がある場合はそれが該当するし、
レス毎に投稿時点での最新レスIDを参照させる場合はそれが該当する。
順序を付ける利点は、不正な投稿時刻を前後のレスの投稿時刻で検証・排除出来る事と、
ネットワークの分断の発生をツリー情報から観測・表示しやすくなることなんかが有ると思う。

144 ：
総論の話中だが、
要素技術にWebRTCのプラットフォームを使うのはどうだろう？
skyway
http://nttcom.github.io/skyway/
javascriptで開発できるから、web系の人も開発に参加できる。

145 ：
>>144
SkyWayその物はNTTのクラウドサービスだから、
https://github.com/peers/peerjs-server
辺りを使ってサーバを(あとTURNサポートしてるのでTURNサーバも)提供しなきゃ駄目だけど…
違うサーバにぶら下がるとネットワークが隔絶しちゃうのをどーにかせんと。

146 ：
課題はあるけど、WEB系の技術を使うことができれば、
通常のWEB通信に紛れてプロバイダの方でブロックしにくい。
（暗号化すれば内容によるブロックもできない）

147 ：
ほう、それでWEB系の技術だけで
暗号化するにはどうしたらいいのかね？

148 ：
>>147
jsライブラリならいっぱいあるだろ。

149 ：
>>147
コンテンツボディとして暗号化データ流せば済む話だが、
SSL/TLSを使ったHTTPSっていうプロトコルがあってだね…
ま、コンテンツボディを暗号化する場合だとヘッダ周りで検出されるが。

150 ：
つまりはWEB系の技術というのは
要するに既存技術をJavaScriptで実装したものって
だけの話だな

151 ：
WEB系の技術って既存技術の内WEB系の物って意味じゃねーの？
あと「JavaScriptで実装したもの」って制限はどっから出てきたん？

152 ：
WebRTC使うならOpenPeerがあるってだいぶ前に書いたよな
http://openpeer.org

153 ：
>>143
普通は新規の書きこみが発生するたびに分岐するんじゃないのかな？
書きこみを受けとったノードが処理をして隣接ノードへの伝達(同期)は分岐処理になるのでは？
それとも新規書きこみは新規書きこみとしてDHTの隣接ノードに伝達されるのか？
この場合は各ノードが独自に新規書きこみの処理を行なうことになるが、分岐が起こらない場合は
その書きこみを所持しているべき全ノードがこの処理を行なうことが前提になると思うが
とても行儀の良い人だけが参加する理想的なネットワークが形成されることが前提になっているのでは？

154 ：
>>153
投稿を示すデータの塊をデータのハッシュをキーとして伝達すれば何処から何処へ移動しても変質しない
後はデータの塊の中に投稿時点で存在していた既存投稿のキーを含めれば参照関係ツリーは縦に伸びていく
書き込み処理といっても、投稿を示すキーに対する投稿を示すデータの塊がネットワーク上に追加されて、
スレッドを示す情報に順不同でそのスレッドに投稿された投稿のキーが追加されるだけで、この辺りに特殊な処理は必要ない
スレッドを示す情報側は順不同なのでネットワークが接触したら重複除いてマージするだけで良いし、
スレッドの分岐の痕跡や後始末は各投稿データに含まれる既存投稿キーを参照して表示時に解決すればよい
スレッドを示す情報にキーを追加する際は、キーが示すデータを検証してから追加する、とかは必要かな…
行儀に関しては連投DDoSあたりはproof of workとか仮想通貨を導入しないと対策できないんでほどほどでいいかと

155 ：
え？DDoS？

156 ：
確定投稿と未確定投稿に分けて考えればいいんだよ。
特にフラグ設けなくてもレス番の有無で判断がつくし。
未確定投稿を２ｃｈ互換で掲示するのは無理なので、外部に掲示されるのは確定投稿になってからで、
拡散された状態で一足先に見ることができるのは参加者の特典でいいんじゃないかと？

157 ：
>>155
行儀の良くない人がどの程度まで想定するのか分からんかったから
防ぐのが困難なレベルの行儀の悪さを想定したらそうなった
>>156
なんでそんな時間差付ける必要が？…って思ったけど、確定未確定ってレス番の確定か
確定条件によるけど、分断状態でそれぞれが違う内容で確定させたら駄目なような…
あと、ここで言う分断は引き継ぎに失敗しつつ稼働するノード群が入れ違いに休眠した場合とかでも起きる筈

158 ：
>>48
hidden service の情報が FBI にごっそり抜かれたそうだ、pure でない限り必ず弱点が発生するね
http://www.gizmodo.jp/2013/08/post_12892.html
tor 規制も遠くない

159 ：
記事の内容読んだか？
>Firefoxの脆弱性を突いてTorユーザーの身元を特定できるカスタムのマルウェアが広まっていたんですね。
FBIがスパイウェア撒いたって話だから、通信形態は関係ない

160 ：
アノニマスが開発した「AirChat」が凄い！インターネットなしでデータ通信
http://blog.livedoor.jp/itsoku/archives/38902170.html

161 ：
>>160
読んでないけど、手旗信号と見た

162 ：
最終的にはインターネットに繋がるらしいが、
「ローカルネットを沢山繋いでインターネット」
って意味で言うと結局インターネットの一部なんだよな。
-- 我々はボーグだ。お前達は同化される。抵抗は無意味だ。

163 ：
だから、DSの擦れ違い通信だって

164 ：
いつのまにか Vidalia　単体のダウンロードができなくなった‥
ブラウザででしか使用できない‥

165 ：
素人には危険だからかな

166 ：
https://github.com/gitchain/gitchain
これまんま掲示板に転用できないか？

167 ：
開発者向けの話題を提供しましょう。
ノード間のメッセージングにはTCPかUDPを使われるかと思いますが、皆さんならプロトコルをどう設計しますか？
バイナリで組む人もおられるでしょうし、HTTP風にテキストベースで書く人もおられると思うのですが、皆さんの知恵を聞かせてください。

168 ：
そんなのどっちでもよい

169 ：
>>167
こっちでは今PDですら遮断される状況だから偽装してほしいな

170 ：
今迄のは開発者の話題ではないと思ってたのか。なんかこいつにイラっとくるのってオレだけかな

171 ：
>>170
アスペかよ

172 ：
>>167
扱いやすいしバイナリ一択だな

173 ：
そんなのどうでもいいって言った理由は、
バイナリかテキストかによってアプリの機能や
開発しやすさになんら影響をあたえることがないから。
プロトコルをオープンにしてだれでもあつえるようにするなら
テキストのほうがやりやすいだろうし、逆に解析をしづらくしたいのなら
バイナリのほうがいいだろう。程度の意味しかない。
アプリからすれば、そんなプロトコルの違いは、下層のレイヤーが
吸収してオブジェクトの形にするから、どっちでも同じだし、
あとから変えることだって簡単。プロトコルの命令の種類の話しならともかく。
テキストかバイナリかという表現形式なんか、どうでもいい。

174 ：
機能面ではそうだが、テキストはパースにも構築にも、バイナリに比べて数十倍数百倍の時間が掛かるからなぁ
比較とかもバイナリの方が簡単だし

175 ：
それは全体の1%にも満たない部分だから
時間がかかっても問題ない。

176 ：
どうでもいいことに拘ってないで、まずは要件定義をしろｗ

177 ：
>>167
UDPで経路毎の最大パケットサイズ調べたりメッセージ分割したり結合したり、絶対ダルいからUDPは嫌だな
バイナリで組むかテキストで組むかは趣味の領域な気もするけど…
単一接続で長いメッセージを含む複数のメッセージを送る場合はテキストだと無駄が多い気がする
ていうかそれ以前に遮断の防止などでSSLなどに偽装したコネクション張る事から考える

178 ：
要素技術なんぞ詳細設計の段階の話だろうがｗ
まずは要件定義しろｗ

179 ：
Unicodeをデフォルトにしようず。
UTF-8が無難だが日本的にはUTF-32にも惹かれる

180 ：
書込時の匿名性はP2Pによって実現するといっても、
閲覧時にP2Pは不要（cf.新月ネットワークの場合は閲覧用にもP2Pを利用する）。
サーバーは有志の運営に委ねる（中央集権的管理の完全否定）。
運営者は現在の2ちゃんねるの過去ログ転載サイトのように、広告収益などを目当てにネットワーク資源を提供すればよい。
サーバーのログ上の特定の書き込みを、何らかの問題発生時に、削除するかしないかは各サーバー管理者の判断による。
サーバー間の信頼関係システムも設け、専門外の板については、他サーバーのログをそのまま信用してクローンする。
理想的にはスレ毎に、スレ立て人自身が管理者となって、サーバーを立てているような状態。
ちゃんと管理されているスレは繁栄することが期待できる。
一般ユーザーの書き込みの匿名性は、P2Pによって、ユーザー同士の端末を一定HOP経由してから、サーバーへの書き込みがされるようにする。
サーバー同士の書き込みの伝播にまでP2Pを適用するかどうかは、確保したい匿名性のレベルの議論による。

181 ：
>180
つまり、一番最初に見た人が、
一番最初に書き込んだ人である確率が極めて高い
ってことでいいですか？ｗ

182 ：
意味不明。
サーバーに反映されないと誰も見れないのに、なぜそうなるの？

183 ：
>>180
匿名化対象は、投稿者→匿名、配信者→公開、閲覧者→公開、だと仮定して、
その構造でサーバ間を暗号化する目的がよく分からんのだが…
サーバの持ってる前データはオープンで、サーバにデータを投稿した人間は不明でしょ？
サーバ間での同期は複製元も複製先もオープンで、匿名化すべき部分が見当たらないのだけど。
それとも匿名化対象が、投稿者→匿名、配信者→公開、閲覧者→匿名、であり、
複製先サーバがオープンな配信者として動作しない、読み専の閲覧者である場合も含むってこと？
>>182
閲覧に関して普通の専ブラと同じ方式をとった場合は、
投稿者は書き込み直後にそのスレの更新動作をする。
この動作は他の閲覧者の自動更新や手動更新よりも先行する可能性が非常に高い。
プッシュ配信でもしてしまって投稿者閲覧者問わずに更新させるか、
閲覧に関してもオニオンルーティングするかしないと隠蔽できない。
プッシュ配信だと閲覧者数が少ない場合に投稿者がバレてしまうので、
閲覧者数が少ないスレッドでは匿名読み込みに切り替えないと不味い、かな。

184 ：
>>180
それは ny で失敗したはず
IP -> ID 識別は、ID の寿命を長くするとレインボーテーブルで一網打尽は前のスレでも散々
トリップ‥‥どうだろうか？

185 ：
そもそも匿名が何故必要かってところを勘違いしてないか？

186 ：
冤罪逮捕を防止するためだよ

187 ：
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

188 ：
そもそも逮捕されるような事が出来るツールという時点であまり説得力がないんだよな
普通に健全な内容であれば特別匿名性が高い必要もない

189 ：
インターネット自由宣言に則ったネットワークを構築するため

190 ：
つ外患罪・内乱罪
そういうものに対応できるシステムがあってもいいという立場もないわけではない，ああこれって予備・陰謀になりうるのか？
日本は主に島原の乱以来の営々たる血と汗の努力により現在は稀にみる平穏な土壌が育っているので必要性は感じられないのかもしれない
そういえば何かのアニメに自主すれば無罪とかいっていたが‥①アニメーションはなんだったか？②本当か？

191 ：
こっちはもう匿名性は放棄したんじゃないの？それともP2Pにすれば自動的に匿名になるとでも思ってる？

192 ：
どこかにこのスレの公式仕様みたいのでもあるのかね。

193 ：
>>1に「2ちゃんの代替となる」とあるだろう。
一般の2ちゃんユーザーが納得する程度の匿名性があれば十分だということなんだよ。
匿名性の技術的保証の辺りをグダグダ言う奴用には、もう一つのフォーク元のスレが用意してある。

194 ：
>>190
多分アニメは「攻殻機動隊 Stand Alone Complex 2nd GIG」
罪状は「内乱の予備・陰謀、外国に対し私的に戦争をする目的の予備・陰謀」
でもこれ架空の近未来日本を舞台にした作品だからこれを参考にするのは間違ってる。
第三次非核大戦後だの自衛軍だの電脳化率9割超だの難民わらわらだのだし…
プログラマを武器と見做して武器禁輸措置を適用しちゃうような世界。
まぁこういう言うのはアレだ、誤用じゃない方の確信犯として突き進む類の話じゃね？
言論の自由とか人権レベルで正しい行為だと確信しての行いが犯罪になるケース。
だけど真面目な話、憲法で保証されてる権利の行使だと、刑法はひっくり返る場合がありうる。
明確な外患誘致や内乱の意図がなければ最高裁まで引っ張って勝てる可能性がある話かと。

195 ：
ぼくのかんがえたさいきょうの掲示板（笑）

196 ：
>>195
それを大真面目に考えるのがこのスレなわけだがｗ

197 ：
このスレだと茶化しで済むが、向うのスレだとマジで噛み付いてくる奴がいるぞ。

198 ：
>>194
おお，thx なんのアニメだったか思い出せなかったんだ，神山氏は神だね‥‥

199 ：
ネットワーク上の第三者から、書き込み主を物理的に（ここではIPアドレスが）特定できてはいけない
同一人物からの複数書き込みの、書き込み主が同定できなければならない

これの両立が必要？

200 ：
2つ目は1つ目を守りながら実現するのが難しいし、
自主的にID振って他人のID詐称できない程度
(一人で複数IDを使用を阻止できなくても良い)
にしておいたほうが実現しやすいと思うけど。
どうせ2chだってID変えれる環境の奴は変えれる程度のものだし、
完全に阻止するためにはIPアドレス以上の同定能力が必要になる。
そこまでの同定能力は現実的じゃない、と思うんだが。

201 ：
童貞能力なら…

202 ：
変えれるけど、それなりに面倒なものをキーとして不可逆変換でIDを生成し
書き込み時の通信経路を不定にする
たとえばキー候補
・グローバルIPアドレス
・MACアドレス
・OSのプロダクトID（Windowsなら）
・OSのユーザーID
・システムドライブのハードID
キーから生成したユーザID、書き込み時刻、スレIDをネットワークに放流。
受信したノードは、自身がスレを保持しかつ未書き込みなら、確率でスレを更新する。
更新確率は放流寿命(TTLみたいなもの、加えて時間的な寿命も含む)が長いほど低く、短いほど高い。
そしてTTLを（確率で）デクリメントして、さらに放流。寿命が尽きたら再放流しない。
書き込みデータは、時間的寿命が尽きるまではキャッシュに保管。キャッシュデータのTTLは0にする。
書き込み以外にも、自ノード他ノード関わりなく最近更新されたスレデータもポツポツと放流する。
他ノードから流れてきたスレデータと自身が保持するスレデータ・キャッシュ上の書き込みデータを比較し差分がある場合は
マージしてから、そのスレを過去に送った先に送信、今回の送信元に返信する。
その際のタイムスタンプは、最後の書き込み時刻。
書き込みの時系列とレス順が一致しないので、レス番に変わるレスIDの仕様を盛り込む。
リーダーがレスIDをレス番に変換しても良いが、明示的に「>」をつけない書き込みがあり得るので
レス番は廃止したいとこだな。
うーん、スレデータが爆発するのと、改ざんをどうやって防ぐかが問題だな。
あとレス削除の仕様も必要。
ユーザIDに対して第三者が信用ポイントを加算していく、ってアイディアをベースにすると
なにか出来そうなんだけどな。

203 ：
>>199-199
オニオンルーティングで経路を隠しつつ，P2Pネットワークの入り口で IP アドレスを同定して ID を振ることは可能だよ．
ただ IP　アドレス空間が狭すぎてレインボーテーブル手法が可能であることが問題なだけ．
ソルトを工夫すればいけるんじゃないかとおもうが，具体的手法は思いつかない

204 ：
>>202
それだめだから
大原則　「送信者の提供情報は一切信じるな」

205 ：
>>203
その辺の値は生の値を改竄無く提供できないなら検証も出来ないのがなぁ…
一人が複数の値を名乗れる問題と、一人が他人の値を名乗れる問題は異なる。
前者はまぁ程々にするしかないけど(極論、協力者に代理頼めば別人になれる)、
後者は明らかに色々と問題が起きるから防がないと不味い。>>204
確率的書き込みは投稿ルートが不定だと観測網を設置することで絞り込めるし、
根本的に物理ネットワーク上の近隣で盗聴されると一発で特定されちゃうから不便。
トラフィック効率的にも、素直にオニオンルーティング系使ったほうが良いと思う。
>>203
入り口での生成だと、投稿者が投稿者ノードではなく入り口のノードとして振る舞う事で、
架空のIPアドレスを持った投稿者ノードからの投稿に偽装出来てしまうのはどう対策する？
というかその辺の問題にぶち当たる部分は程々にしとくのがコッチのスレでは？

206 ：
>>205
＞入り口での生成だと、投稿者が投稿者ノードではなく入り口のノードとして振る舞う事で、
＞架空のIPアドレスを持った投稿者ノードからの投稿に偽装出来てしまうのはどう対策する？
まず架空のIPアドレスというのは存在しない
接続された方が取得する（直接の）IPアドレスは本物だ，そうでなければ IPが成立しない．したがって「架空のIPアドレス」という文言自体がでることからして >>205 の文言は一切がっさい疑わしい
（たぶんバークレーソケットを触ったことがないんだろう‥）
ただし投稿者を特定できなくするオニオンルーティングを通過した後は，いずれ匿名掲示板ノードに到達するわけだが，このレベルの偽装はどうするべきか．
個人的には，DHT 実装でもない限り，ルーティング情報を盛り込んでユーザー側の判断にゆだねるのが妥当だと思う
fj で path: aaaa!bbbb! cccc! というヘッダがあったがあれは以外と有用だった>>628

207 ：
コッチのスレ的にはIDはとりあえず1日使い捨てのオレオレ証明書でいいと思う。
あと、ちょっと向こうのスレ的なネタになるけどIDの生成方法として、
出力ビット数を極端に落としたハッシュ関数ってのは使えないかな？
板ないしスレッドに相当する情報と日付から適当な式でN個(100個位)のID発行ノード用ハッシュ値を生成する。
投稿を行う前に、それらのハッシュ値を保持するノードに直接接続して1ビットID(IPアドレスベース)を発行してもらう。
表示の際は、投稿に含まれるNビットの生IDを適当なエラー訂正アルゴリズムに通してMビットのIDを表示する。
IDシード用ハッシュ値を保持するノードはその日のID=0用電子署名とID=1用電子署名とソルトを用意しておき、
ID発行依頼があればアクセス元IPアドレスとソルトで発行したID側の秘密鍵と、両IDの公開鍵をアクセス元に返す。
数ビット分のハッシュ関数を知ってもIDを逆算は出来ないし、ID発行ノードも1ビットでは誰に発行したIDか判別できない。
ID発行ノードが変動したり消えたりした分はエラー訂正アルゴリズムである程度は吸収できる。
普通のDHT同様、その日の署名+ソルトのセットを切断前に他人に引き継ぐ仕組みも頑張れば実現できる…かな？
問題は投稿ごとのメタデータのサイズと処理で、N*2個の公開鍵とN個の署名をIDのためだけに付加しなければならない。

208 ：
>>206
すまん、「架空のIPアドレスを持った(架空の)投稿者ノードからの投稿」だ。
2つ目の架空が抜けた。本当の投稿者が架空の投稿者をでっち上げて
「(架空の)投稿者から接続を受けた入り口ノード(本当は投稿者)です」
って振る舞う場合の話だから、(架空の)投稿者との間のIP接続なんて存在しない。

209 ：
>>207
投稿のたびに百個くらいのノードにIPアドレスを伝えちゃうと、あまり匿名にならない気がする。

210 ：
>>205
> 確率的書き込みは投稿ルートが不定だと観測網を設置することで絞り込めるし、
> 根本的に物理ネットワーク上の近隣で盗聴されると一発で特定されちゃうから不便。
そもそも観測網を設置されないと絞り込めないなら匿名性としては十分ではないのか？
匿名性の目的は、身を守ることであると思うが
ネットワークが犯罪の温床となり、余計な捜査をされないように、との意図なら
「自分が書き込んだものではない」ことが証明出来ればよい。
そういう意味で匿名性を犠牲にしても、改ざんや成りすましを防ぐ方が重要。
加えて、確実なデータ削除の仕組みが必要。
スレ趣旨の「２ちゃん互換」は、プロトコル互換でもデータ互換でもなく
安心して楽しめる「コミュニティ形成の場」としての互換なんだろ？
> トラフィック効率的にも、素直にオニオンルーティング系使ったほうが良いと思う。
十分なユーザー数に増えればオニオン系の方が良いとは思うが
ユーザーが増えなければ？
結局arpanetイメージに近いものになるのではないか？

211 ：
無限ループですな。

212 ：
>>210
＞結局arpanetイメージに近いものになるのではないか？
ま，そういうことだね
折れのイメージは arpanet + onion-routing + 通信文は一応の暗号化(鍵交換くらいでいいかと）
最後のはわりと重要で，ny がこれを実装しておれば寿命は数倍に延びたはず

213 ：
>>210
1日1回見に行けば十分だし、投稿しない人も見に行くようにすれば十分紛れると思う。
>>210
> 観測網を設置されないと絞り込めないなら匿名性としては十分
nyの例を見ればわかるが、ある程度普及すれば観測網が形成される。
観測網を設置すれば誰でも特定できる可能性があるってのは2chよりも弱くてちょっと痛い。
> 「自分が書き込んだものではない」ことが証明出来ればよい。
確率書き込みだとそれが証明できるっていう仕組みが分からんのだけど。
全員がリレーログを保持して提出できるようにするってことだとちょっと怖いな。
> 十分なユーザー数に増えればオニオン系の方が良いとは思うが
逆じゃね？確率書き込みだとユーザが少ないほうが観測ノードの効率が上がる。
オニオン系の場合も観測ノードの効率が上がるけど、中身は見えないからゴミ流したり時差つければOK。

214 ：
>>210
>「自分が書き込んだものではない」ことが証明出来ればよい。
悪魔の証明……

215 ：
永久機関を開発しようとしてる感じ。
「匿名だけど固有のIDを振ろう」
おかしいでしょ？

216 ：
>>215
いや，できなくはない，元祖スレでは割合に話は進んでいた
IPv4 の空間の狭さ，ソルトをどうするか，くらいまではOKだ

217 ：
bitcoinってどういう仕組みなの?

218 ：
>>213
nyの観測網は，通信文が暗号化されなかったことによることが大きい
著書にて触れられていたDHをせめて実装しておれば，観測網の構築を遅らすことも可能だった，申し訳ないが K 氏の誤算だ

219 ：
匿名性も何もないテスト版でもいいから
実際に作って動けばもっと活発になるんじゃないか？
ブラウザ経由で書き込めるようにすればtorで書き込めばいいんで
これだけでも一応使い物になりそう

220 ：
>>219
ブラウザ経由とか意味わかってないだろ
誰がサーバー立てるんだよ
P2Pの話してるんじゃないのか？

221 ：
ここにいる人たちは>>1にあるp2p2chとかちらしの裏だとダメなの？
使ったうえで改良について話しているのか、それとも1から作り直すために話しているのか気になる
匿名性を気にしないってことならこれを改善していくってのが一番いいと思うんだけど

222 ：
>>218
遅れようが、観測網は作られるんでしょ？
わざわざオニオンルーティングより弱い無暗号化(難読化)リレーにしたい理由が分からん。

223 ：
>>220
winny掲示板みたいなやつ
ブラウザでhttp://ipアドレス:port/で開いて
保持してるスレリスト表示そこから書き込めるようになれば
簡単にtorでも書き込める

224 ：
>>222
×難読化リレ
○公開鍵暗号
残念だがK氏著書にもあるとおりが一度は検討したDH鍵共有は、単なる難読化ではない。
いわゆる公開暗号系に属するものであり、第三者には解読不可能
http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%83%98%E3%83%AB%E3%83%9E%E3%83%B3%E9%8D%B5%E5%85%B1%E6%9C%89
クローラには弱い手法だから、あくまでも「遅らせるだけ」であったかもしれない。
クローラ対策は今のところチューリングテストしか思いつかない

225 ：
そもそも誰も本気で作ろうって奴がいないのに議論するだけ無駄。

226 ：
P2P型掲示板のコアを共同開発して、UIは各開発者が作れるようにしたい

227 ：
>>221
そこに人が増える可能性が感じられない。２ちゃんユーザーを根刮ぎ奪い取るような勢いが欲しい。

228 ：
>>224
DH鍵共有は公開鍵暗号じゃなくて鍵共有なのは些細なことだから置いとくけど、
ノード間通信にDHを使ってもISP等のスニッファが中身を読めなくなるだけだよ。
主なny観測網(≠規制装置)は擬似nyノードだから、実装・解析難度が上がるだけ。
一方で、オニオンルーティングは中継したノードに対しても内容を秘匿するから、
観測ノードが居ても問題ない。けれど確率書き込みだと観測ノードが読めてしまう。
チューリングテストっつっても、観測ノードが標準動作しかしないなら発見できなくね？
最悪、VMやデバッガ上で走らせてメモリ上にデコードされたデータを監視されるし。

229 ：
>>228
> 一方で、オニオンルーティングは中継したノードに対しても内容を秘匿するから、
でもさ、こういう意見もあるよ。これは本当なの？
http://monobook.org/wiki/Tor%E7%A7%98%E5%8C%BF%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9
Torの脆弱性 [編集]
Torの脆弱性を突く技術はほぼ全てTorネットワークとインターネットの接続点である
「出口ノード」に関するものばかりである。つまり、出口ノードが単一障害点であると言える。
Torの出口ノードは何かしらの事件があれば真っ先に調査対象となるため、
出口ノードになるという勇者（主に世界各国の人権団体など）は非常に限られており、
定期的に出口ノードのIPアドレスを集計し、データベース化しておくことで、
Tor経由の接続を検出することができる。また、パケットキャプチャを仕掛けた
出口ノードでは発信源は不明だが通信内容は傍受できたりする。

230 ：
中継が終われば投稿者の匿名化は完了してる。
掲示板の場合、投稿されたデータは公開情報だから出口に到達したデータは全部バラして問題ない。
確率書き込みだと匿名化が完了していない中継ノードの時点で中身が読まれてしまうから問題がある。
あとこの場合掲示板用P2Pネットワークの全ノードが掲示板専用オニオンルーティング網の出口ノードになるから、
掲示板専用P2P網の参加ノード数さえ確保できてれば出口ノード不足は起こらない。

231 ：
>>228
＞ノード間通信にDHを使ってもISP等のスニッファが中身を読めなくなるだけ
全くそのとおりなんだけれども、これ結構でかくない？
＞チューリングテストっつっても、観測ノードが標準動作しかしないなら発見できなくね？
まあ、そのとおりだね‥でも観測ノードがふつうに動作してくれるんなら、それはそれで問題ないんじゃない？
オニオンルーティングさえうまくいっておれば大きな問題はない
オニオンルーティングの先で
①投稿元が特定されるのがどうしてもいやなら、IDはあきらめる
②spamをばら撒かれるのがいやなら、昔の net-news のように path をつける

232 ：
>>229
オニオンルーティングの中だけでサービスを提供すればいい
Toｒ のその脆弱性は、オニオンルーティングの外に出るがための避けられない弱点だ

233 ：
>>230
その匿名化ってのが何を言ってるのか判らん。
中継が終わるとは「オニオンルーティング出口に到達すること」なのか？

234 ：
>>231
> これ結構でかくない？
近隣で盗聴された結果一発で何書いたか特定されるって事態は防げるし確かに大きいけど、
盗聴するまでもなく観測ノードで特定されちゃったら駄目じゃね？
> それはそれで問題ないんじゃない？
確率書き込みだとオニオンルーティングより匿名性が下がるのが問題なんであって、
匿名性を破るためのシステムがネットワークへの負荷になるかどうかは別の問題じゃない？
> オニオンルーティングさえうまくいっておれば大きな問題はない
このツリーは確率書き込みっていう無暗号化(難読化)リレーのリスクの話じゃなかったっけ？
>>233
投稿者を特定出来る可能性が十分に下がった状態になること、でいいかと。
オニオンルーティングの場合は、観測ノード以外のノードまでメッセージが秘匿されたまま到達すること、かな。
中継ルート上の全ノードが連携関係にある観測ノードだった場合は出口まで到達しても投稿者がバレる。

235 ：
>>234
投稿者の特定とは、投稿者の「IPアドレス」の特定？
それとも、他の投稿と同一投稿元であることの同定？

236 ：
>>235
どっちも投稿者の特定に繋がる情報だし区別したがる理由が分からんわ。
オニオンルーティングはIPアドレスの特定と近隣ノードでの盗聴回避を目的としてるシステムだけど、
IPアドレスが隠蔽されてる状態ならメタデータで暴露しない限り同一投稿元の同定は無いと思うが？

237 ：
IPアドレスの隠蔽は必要。これはポートアタック等による直接的な攻撃を避けるため。
現行の２ちゃんねるでのIDの一致は、高い確率で同一投稿元になる。
しかし、これはIPアドレスが公開されるわけではない。
この例で分かるように同定と特定は別物。
匿名とは「IPアドレスを特定されないこと」。
同定できるシステムにしないと成りすましを防ぐことが出来ない。
逆に言うと、特定できない範囲で同定できるシステムにする必要がある、ということ。

238 ：
>>237
> これはポートアタック等による直接的な攻撃を避けるため。
参加してる時点で、参加者を無差別に狙う攻撃に被弾する可能性はあるよ。
標的型の攻撃や、関連情報を名寄せして別の攻撃に使われるリスクのほうがヤバイ。
> 同定できるシステムにしないと成りすましを防ぐことが出来ない。
既存の他人に成りすますを防ぐためなら、同定する必要は全くない。
オレオレ証明書で署名して証明書が一致することを確認すればそれで済む。
一人で複数人に成りすますのを防ぐためには同定が必要だけども、
経済力や人脈を使うことで物理的に複数の代理人を用意できるから、
こっちは程々にしとかないとキリがない。

239 ：
表現の差で想定する程度は一緒なのかな。
異なるネットワーク回線や人脈を使った物理的代理人は回避しようがないが
証明書を使って、「同一環境」からの書込みは同定する必要がある、という程度な。

240 ：
これつかって犯行予告しても
捕まらない気がしてきたんだけど
あってる？

241 ：
>>240
そもそも反抗四国程度で軽殺が動くこと自体がなにかの間違い

242 ：
予告はもちろん達成報告しても全く無事ってくらいじゃないと
匿名の要件を満たせてない

243 ：
犯罪に使うための匿名の要件などいらない

244 ：
そこまでいくと完全匿名を目指してることになる

245 ：
>>242
結果としてそうなる可能性はあるが、意図的に公権力専用バックドアを設ける可能性もある。
>>242
犯行予告された側の対応は何が正しいのかって言うと結構難しいけどな。
>>242
開示請求が出れば公開される(筈)の2ちゃんねる程度の匿名性を考えるなら、そんなレベルの匿名性は不要。
ただ、有象無象による匿名性の突破が出来るようだと不味いから、
結果としてそういうレベルの匿名性が得られる可能性はある、程度の話。

246 ：
匿名は擬似的でもいい。アドレスが見えないだけとか。
TORなどで匿名化したらいい。

247 ：
今 TOR はブラウザしか使えない‥

248 ：
名指しで自分の子供に殺害予告されて
でまかせだって放置する親いるの？

249 ：
>>248
そこで子供を持ってくる思考はなんかアッチ系の人みたいでキモイ
普通に自分の殺害予告に置き換えて考えとけば十分だろ
で、過剰反応って言われるのは明らかに本気じゃない文脈で反応しちゃう方
つか過剰反応云々はスレチ気味だから止めないか？

250 ：
とりあえず方向性をまとめよう
目指してるところ
├国家の検閲にも耐えたいよ派
├一般人にバレないぐらいならいいよ派
├誰にバレたところでいいよ派
└匿名よりみんなで管理ってのが大切だよ派
ネットワークの感じ
├freenetの高速版目指すよ派
├tor板方式でいくよ版
└torの上に独自ネットワーク作るよ派

251 ：
>>250
・torの上に独自ネットワーク作るよ派
最近 Vidalia を単独でダウンロードできなくなっているから、これはできなくなった

252 ：
派閥争いは必要なのです

253 ：
>>251
意味わからんのだが…
TorはSOCKSプロキシとして動くからTCP上のプロトコルは普通に通るんじゃないのか？
つか実装コスト気にしないならTorと似た仕組みのレイヤを組み込んでおけばそれで済む。

254 ：
インターネットの自由宣言に基づくネットワークを構築したい派
http://jp.globalvoicesonline.org/2012/07/25/15378/

255 ：
>>253
最近は tor はブラウザと組で、でしか提供されず、tor をブラウザから切り離して使用することができない
＞実装コスト気にしないなら
あっさりいってくれるね

256 ：
ランドセルはよ！！　実装はよ！（時事ネタ）

257 ：
２ちゃんねるが崩壊しそうなので早く作ってくれ。

「２ちゃんねる」に対する損害賠償金を回収！
　この度，「２ちゃんねる」に対する損害賠償金の取立に成功したのでご報告いたします。
　「２ちゃんねる」については，数多くの名誉棄損的書き込みがなされ，管理人に対しても多くの人が訴訟を起こし，損害賠償を命ずる判決が
言い渡されています。しかし，「２ちゃんねる」の管理人の印税債権などが会社名義とされているため，ほとんどの場合，「２ちゃんねる」の管理人に
対して損害賠償債権を持つ人も泣き寝入りをさせられてきました。
　私は，「２ちゃんねる」の管理人が，掲示板の書き込みを書籍にした出版社に対して有する印税債権を差押え，出版社に印税の支払いを求めました。
出版社からは，印税債権を持っているのは管理人ではなく別の会社（Ａ社）だとして支払いを拒否されました。
そこで，その出版社に対して印税の支払いを求める訴訟を起こしました。
　裁判所は，名目上印税債権を持っているのはＡ社とされているものの，実際に印税債権を持っているのは「２ちゃんねる」の管理人だとして
（つまり，Ａ社は「２ちゃんねる」のダミ－会社だということ），出版社に印税の支払いを勧め，出版社が当方に印税を支払うということで
解決することとなりました。
「２ちゃんねる」の管理人からまとまった損害賠償金を回収したのは珍しいことだと思います。
これからも「２ちゃんねる」ほかの掲示板などでの被害を受けた人の権利救済のために戦っていきたいと思います。
弁護士　　齋　　藤　　　裕（新潟県弁護士会所属）
http://www.niigatagoudou-lo.jp/?p=352

258 ：
★2ch勢いランキングサイトリスト★
◎ +ニュース板
・ 2NN
・ 2chTimes
◎ +ニュース板新着
・ 2NN新着
・ Headline BBY
◎ +ニュース板他
・ Desktop2ch
・ 記者別一覧
◎ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
◎ 全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索

259 ：
親宛てに、プロバイダーから封書が届きました。

私が、２ちゃんねるに書き込みをした、日にちと時間と
内容も、すべて、プリントアウトされて、

「これだけ、書き込みを、２ちゃんねるに、していますね」

というプロバイダーからの封書。

名誉棄損どころか、いい恥さらし。

プロバイダーのこと、切ったほうが、いいかな。

契約を解除しないと、親に、プロバイダーが
２ちゃんねるの書き込みまで、全部、プリントアウトして
届けています。迷惑。うっとうしい。ストーカーみたいで、キモイ。

260 ：
過疎ってるみたいですね。しばらくサーバが不安定だったので見ていませんでした。
諸事情でコードを触れなかったのですが、これからゆっくり実装していきたいです。
Scala関連のP2P通信に利用するメッセージングについての技量が不足しているので勉強しているところです。
まだだれかいますか？

261 ：
>>260
単にROMってるだけの2ch mateユーザーですが、いますよ。

262 ：
見てるよー

263 ：
だれも自発的に動かないプロジェクトのスレなんて
あっても意味ないわな。

264 ：
ヒント：感想戦

265 ：
実装できる人がその人の自由に仕様決めるのでいいよ
つか言うだけは外野

266 ：
投げっ放しジャーマン

267 ：
じゃあまぁ俺が作るわ。
トリップの付け方がわからんくらいの素人だが。

268 ：
まじで掲示板作って欲しいよ（htmlしかできない雑魚より..）

269 ：
今作ってる
ちょいまち
予定では
2chのキャッシュ共有とP2P掲示板のハイブリッドみたいな感じ。
2chは無くても動くようにしたいけど捨てない。
2chのトリップとかおみくじ？とかよくわからん機能の事は考えてない
当然2chブラウザ使える。
匿名はそこそこ。
P2Pなんで荒らし対策の方に重点おいて考えてる。
へぼいのでもできたらどっかに上げるよ

270 ：
>>269
Unicode対応は？

271 ：
>>270
あー
2chっていまだSJISなんだっけ
考えてなかった
こまったな

272 ：
Unicodeに変換してからキャッシュして共有すればいいんでは

273 ：
ユニコード対応しちゃったら2chブラウザが使えない

274 ：
んーじゃあ、Unicodeキャッシュと並行してShiftJISキャッシュをサブで保持するとか？
Unicode対応してると、絵文字とか、断然可能性が広がるので、是非。

275 ：
んーこまったな
まぁなんか考えるわ
そんなことより考えなきゃいけないこといっぱいあるし
とにかくまず動くものつくらんと

276 ：
トリップはSJISでないと同じにならない。あと、各種出力がSJISでないと専ブラは使えない
さらに今の専ブラは２ちゃん仕様に特化してて、クッキーを使うと殆どの専ブラが使えなくなる
そして２ちゃんが新APIを実装するとかで専ブラはさらに２ちゃん特化の方向へ
俺も色々考えたんだけどSJISを使い続けた方がいいと思う
開発終了している専ブラや古いバージョンがそのまま使えるというのが人を集める条件になると思う

277 ：
SJISにない文字はイゲタになっちゃうとかでもいいから内部はUTF8にしたいなぁ
SJISめんどうだわ

278 ：
>>277
国際的に普通のライブラリだとかはUnicode (UTF8)基準だもんな。
やっぱり並行して互換用のShiftJIS化したキャッシュも生成するような形で、
従来の2chブラウザにこだわる人は「どうにか使えないこともない」という
程度の余地を持たせりゃ、十分じゃないの？

279 ：
何だか盛り上がってますね。私も開発を進めないと……

280 ：
バックエンドをGoでやるなら参加する

281 ：
言語はなんでもたいして変わらんだろ
特にバックエンドは
問題は仕組み
どうやったら参加人数増えるかだなぁ

282 ：
>>180みたいな仕組みでいいんじゃね？

283 ：
ビットコインのブロックチェーンの更新情報ってどうやって流してんだろ

284 ：
つーかスレタイの２ちゃんねる互換ってのは、２ちゃんブラウザーでも見れるってこと？

285 ：
Diasporaみたいに一般人はP2Pなしで扱えることは必須だよね
じゃなきゃ普及なんてしない

286 ：
>>284
スレの設立（本スレからのフォーク）趣旨としては、
必ずしもそうじゃない（必要条件というほどでもない）けど、
そんな「感じ」ではある。
UX的な「使い勝手」の話。
技術面での規格的な互換性は少しも意味してない。

287 ：
新月みたいに、ユーザー側からのUXまで別もんにするのはやめようということで

288 ：
へー
じゃあTwitter型とかは無しなんだ

289 ：
２ちゃん専ブラを使えるかどうかが大きいんだよね
まずそれを聞かれて使えなかったら興味無しって感じだから
新しい掲示板仕様にするなら広めるにはかなりのパワーがいる

290 ：
>>282
大体にたような感じで実装進めてる
とりあえずつくって
ここで仕様を説明しつつ公開する予定

291 ：
まぁtwitter型でもなんでもいいとはおもうんだが
そもそも人が来ないことには話にならないので
2chが作ってきた文化というかリソースを有効活用させてもらうのが楽ってだけでしょ
twitter型の掲示板ってのがどんなんだか興味あるので作って公開してくれるならなんでも俺はうれしい

292 ：
もう現行の2ちゃんブラウザは切り捨てていいんじゃね？
ちゃんとAPIを整備すれば喜んで対応してくれるだろう

293 ：
有志のサーバー群がP2P網を担って一般ユーザーはサーバーを自由に選択(民主的な信任とリスク)
とりあえずここまではいい？

294 ：
いいと思う
専ブラ捨てるのもありだな
スマホで一般ブラウザ使って専ブラ並に見れるようにするのも
JavaScriptが整備された今では難しくないし

295 ：
規制周りの機能をP2Pサーバ運営者ないしユーザに委ねることになるから、
専ブラの時はその辺のUIを無効化せざるを得ないんだよね…
専ブラのインタフェイスだけで全てをこなすのに拘るのは無理があるだろう。
専ブラに関しては、専ブラでもアクセスできると便利だね程度だと思ってる。

296 ：
データベースはどうする？
各ピアがそれぞれ全体を持つのか、断片を持つのか

297 ：
個人的には専用ブラウザの快適性は捨てたくないね‥

298 ：
なんか専ブラはAPIkey登録制にするとか話が進んでいるのか…

299 ：
>>296
完全なレプリカを全ピアが持つのは無駄でしかないと思う
ユーザーリクエスト→自サーバーにない時はDHTでアドレス取得、返信→ユーザー、アドレスからダウンロード
サーバー間のプロトコルを決めないとな

300 ：
先に仕様(ドラフト)を決めてから各自作り始めたら後の互換性で楽になる

301 ：
>>300
先に動くソフト作ってからそれに合わせてドラフト作った方が
クソ仕様で苦しむ人間を減らせていい

302 ：
>>301
は？

303 ：
2ch.scが新APIとやらでJSON + UTF-8になるらしい
それに仕様を合わせる必要はないけど、JSON + UTF-8 はありだな

304 ：
フロントエンドの話は後からでいいだろ
馬鹿しかいないのか

305 ：
マジかよ、2chにUnicode推しの俺のアイデアパクられたよ

306 ：
つぶれたようだね‥

307 ：
誰もいなそうだけど新月でいいんじゃね
専ブラで見れるようになってるよ

308 ：
P2Pって掲示板に応用できんのか？
P2Pはゲームやファイル共有のリアルタイムでの通信にしか使えないイメージなんだが
内輪での情報交換にはもってこいだろうが一般人が使えるものではなくなるんじゃないか

309 ：
【2ch】2ちゃんねるがdatを近日廃止、ウェブスクレイピング禁止2015年3月3日以降はAPI経由の許諾制★4 [転載禁止]©2ch.sc
http://daily.2ch.sc/test/read.cgi/newsplus/1424089221/

310 ：
時代来たんじゃね？
タイミングを逃すな

311 ：
ここの人達にスマホ用掲示板を是非
ストア経由で課金でも使うわ
移転先が無い……

312 ：
ビットコインをはじめよう
このリンクからビットコイン購入・販売所bitFlyerにご登録すると
1000円分のビットコインがもらえます！

https://bitflyerドットjp/gift/fn0tlipl

外部ウォレットに送金できるので、とにかく一応もらっておくといいです。
※上記のURLのドットを.に変えてアクセスしてね。

313 ：
461さん、再臨希望
まじめに進めよう、DHTを軸に

314 ：
俺的仕様要件
・Unicode(UTF-8)
・YAML(またはJSON)
・スレ立て・管理人＝まとめサイト主＝分散ネットワークの１ノード

315 ：
WikipediaのDHTページにDHTのセキュリティに関するリンクがあって今読んでる
http://www.globule.org/publi/SDST_acmcs2009.pdf

316 ：
Mainline DHTの脆弱性について(Sybil attack)
http://www.cs.helsinki.fi/u/lxwang/publications/P2P2013_13.pdf
解決案
http://pdos.csail.mit.edu/papers/sybil-dht-socialnets08.pdf

317 ：
ノードが保有するノードリスト情報に信頼度属性を付けたらどうか
速さ(Ping)、冗長性(Available Since)の二種類
Lookup時、接続優先順位をそれによって傾ける
そうするとハブ的なノードが自然に生まれてくる
BitTorrentのSwarm的なものがその周りで自然発生

318 ：
BitTorrentの場合Trackerでそこら辺をやっているのだろう

319 ：
ノードにログAPIオプションを付けて、ログAPIありのノードからRESTで信頼の置けるノードリストを取得可
ランダムにログを取得するノードをピックアップして統計を取れば全体の信頼ノードリストが出る
これをブラウザアプリに実装すれば自動で適切なゲートウェイ用ノードを選べる

320 ：
ランダムにピックアップする際の応答速度も要素に入れるとアプリユーザーから近いノード＋信頼性の高いノードという事になる

321 ：
DHTだったら到達できないってことはないし
アクセス集中する問題も、１スレに複数キー割り当て(複製コピー)して
ランダムに接続すれば負荷分散できると思う。
匿名は知らん

322 ：
レスの順序をタイムスタンプではなく>>154の方法で考えたんだけど
ttp://up3.viploader.net/ippan/src/vlippan337381.png

前の投稿のキーを含めることでそれより後の投稿であることは証明できるが
前の投稿のキーを含めるか含めないかを自分で操作できるなら
タイムスタンプと同じように改ざん（順序を前後）できてしまうのではないか

結局投稿はスレ立てた１（を担当するノード）に依頼するしかないのか？
それなら時系列は保たれるし更新の衝突もない。

323 ：
そもそも、そういう改竄をされても別に困らない気がするけど。

324 ：
そうなのか
一番長いキー以外は無視されるってやつ？
長いといっても高々1000しかないが

325 ：
お久しぶりです。最近忙しくて。
忙しい時期が過ぎ、アイデアもそこそこ出たので改めて掲示板開発を進めたいと思います。

方針としては、ライブラリ《OpenChord》を利用したChordアルゴリズムのDHTによるデータ管理と、Gitによる履歴管理をレスの順序管理に応用する形で行いたいと思います。
レスを追加する時はデータをDHTに流し、スレを表現するGitレポジトリのファイルにそのキーを追記してコミットします。必ずfetch&mergeを行うので分岐を防ぎます。
問題は全ノードがスレの存在や板の存在を認知できるようなブロードキャストの手法です。
私が以前に作ったものの手法を引き継ぐなら、単にノード間で更新を定期的に伝播する形式になると思います。この辺は新月と同じ感じですね。

開発はよく使うScalaを使い、GithubかBitbucketにレポジトリをホストすることにします。

ある程度いい感じのものができたらお知らせしたいと思います。
チラ裏ですみません。

326 ：
大歓迎ですよ

327 ：
応援してるよ

328 ：
gitレポジトリは分岐していくものなのに何言ってるんだか

329 ：
そういえば、新月にはDHT反対派がいたな。

330 ：
新月使ってるけどいモバイル回線だと公開ゲートウェイ経由になるのが不便だな
webRTCとかでNAT越え出来れば良いんだか

331 ：
単なる朔のGo言語クローンだからmessage floodingだが。

ttps://github.com/shingetsu-gou/shingetsu-gou

332 ：
なあ、俺の頭が悪いからわからないのかもしれないけどさ、
仮にDHTでkey-valueのペアをP2Pで共有できたとするよ。
きっとできるだろうさ。

だとしても、掲示板の>>1 >>2 >>3 .. という並びはどうやって表現するの？
CAP定理ってあるよね。
DHTは可用性と分断耐性は保証するけど、一貫性は保障しないよね。
https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86

333 ：
となると、だよ。
CAP定理的には、掲示板の一貫性を得るには可用性を犠牲にして、
一貫性＋分断耐性のシステムを作らなきゃいけないよね。

理論的に考えて、どこかに中央集権的なまとめ役的なサーバが"絶対に"必要になっちゃうんじゃないかね？
データはDHTに保存するとしても、キーの並びを保存しておく単一のサーバが必要だから、
掲示板を利用するすべての人がアクセスするサーバを用意しないといけないんじゃない？

DHTには(key1, value1), (key2, value2), ..　と保存されているけど、その順番はバラバラ。

サーバには

key1, key2, ..

が順番に保存される。

まあ、DHTをストレージとして使った掲示板ということになるね。
データがDHTに分離されているので、公権力でサーバを押さえられても掲示板を引き継ぐのは簡単かもしれない。

334 ：
P2P匿名掲示板の目的は、公権力や利害関係者などの攻撃者から言論の自由を守る、ということ。
従来の掲示板は中央集権的なシステムになっているため、
そのシステムの運用者が攻撃のターゲットにされれば、掲示板全体が終わる。
しかし、掲示板の性質上、理論的にP2Pにはできない事情がある。
そこで、次善の策として、入口となるサーバとデータを分離して、
データをDHTで管理するという手法を採り、
サーバの運用者の負担を減らす方向で妥協したらどうか、というのが俺の考え。

335 ：
この方式の良いところは、入り口サーバを公権力に物理的に押さえられたり、
ハッカーに乗っ取られたりしても、
入り口サーバのデータをDHT上に定期的にバックアップしておくなどすれば、
いつでも他の誰かが掲示板を引き継げる、ということ。
だから、入り口サーバを攻撃されても、掲示板利用者はあんまり痛くない。

336 ：
入り口サーバの運用者を攻撃しても無駄だ、
と攻撃者に思わせる事が一つの防衛手段になりうるということ。

337 ：
Gnu socialが良いらしい

338 ：
2ch.scのスレがあちこちで停滞してきているんだが、
これって、2ch崩壊の序曲なの？

今こそ、このスレが必要とされるとき！

339 ：
いやむしろ運営が下手だとヒドいことになるとみな気づいたから
よけいに見放される

340 ：
サッカーブッシュ日本代表日程ぷあたん（しゅっちょうまいくろ教育長交代）春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ２４チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン（販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート

341 ：
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
１９

342 ：
このプロジェクト死んだのか

343 ：
要は誰でも自由に掲示板が作れればいいってただそれだけの話
P2Pである必要なんかないし難しく考え過ぎなだけ
レン鯖があれば誰でも掲示板が展開できるスターターキットがオープンオースで有ればマジで話が終わるんと違うんかと

344 ：
それだと触法行為に対応できない
管理者を立てないかわりに完全な自由を獲得することができる，それがP2Pの理由

P2Pファイル共有と共存させればよい

345 ：
Bitcoinの自分のブロックチェーンにメッセージ付きで少額投げれば良いじゃん。

346 ：
>>344
流行んねぇよそんなの
だってp2pじゃルータに穴空けなきゃいけないじゃん
面倒くせぇ
パンピーはポート80でしか外部と通信しちゃ駄目ねって法律作られるだけで終了ちゃうの?

347 ：
>>346
お宝動画のためにルータに穴開けた奴は多い

＞パンピーはポート80でしか外部と通信しちゃ駄目ねって法律作られるだけで終了ちゃうの
クライアント側もポート番号をもっているんだよ，そしてそれは80と違う
そんな馬鹿な法律はできないから安心しな

348 ：
ファイル共有だって、ファイル分割してビットコインのブロックチェーンに投げれば良いじゃん。

349 ：
IP削除し続けてテキスト情報だけ時系列で記録すればいいんじゃないの？

350 ：
>>347
でも現実大半はその規制で防げちゃう上に殆どの人間は困らない
可能性あるんちゃう?

351 ：
外部とのやり取りに使うルータに穴開けた奴は罰金
プロバイダーが貸し出すルータ設定いじれないようにしちゃう規制だけでノックアウトじゃん弱いよね

352 ：
P2Pならメッシュネットワーク対応にしちゃえば、プロバイダなんか無関係

353 ：
＞大阪府三島郡島本町のイジメはいじめられた本人が悪い
＞みんなそう思ってる
＞誰も同情しない
＞うんこ食っとけ！
＞はよRクズ
　　　　　　　　↑
　島本町のバカどもがこんなスレを立ててる
いじめの加害者を擁護し被害者を非難するスレを公然と立てる
　島本町という町は「あり得ない町」だな

354 ：
kademliaベースで趣味で作ってるけど需要ある？

355 ：
>>354
あります！

356 ：
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

P189A

357 ：
なら

358 ：
NUL

359 ：
2ch公認のすすコイン始まったな

360 ：2020/06/02
法案ができるなら今こそこれ必要だな

VB.NET質問スレ(Part44)
【GPGPU】くだすれCUDAスレ part8【NVIDIA】
HSP総合スレ【part 10】 [無断転載禁止](c)2ch.net
文字コード総合スレ Part11
ふらっと C#,C♯,C＃（初心者用） Part143
C#だとそんなに重くなるもんなの？
プログラミングのお題スレ Part16
文字コードの種類は何故複数あるのでしょうか？
【初心者歓迎】最新COBOLについての質問スレ
統計解析R たぶんpart3くらい
--------------------
珈琲Part.168
フリラ―YouTuberを語ろう！　take45
【韓流】あの『公園少女』が日本で初の正式ファンミーティング開催[04/04]
ペットロスになってかなしい。コスパいいペットおしえてくれ。 [298176652]
【PC】Red Dead Redemption 2 Part8【RDR2】
【ブレファン】ブレイブファンタジア Part.29
静岡草薙球場
●2輪ロードレース総合 (MotoGP/SBK etc.) 374●
【DQR】ドラゴンクエストライバルズ LV1295
【植民地化】中国マネー、アフリカへ流入　習氏歴訪で次々と支援約束　負債増で懸念も　中国当局は発展に貢献と反論［18/07/25］
プログラム言語遍歴
【掴み率】セガNET麻雀 MJ 128本場 【握り一発】
【PSO2】Etデュエルブレード、ゴミｗ
【祝・スレ復活】閃乱カグラ 2連閃 【飛鳥舞い戻ります】
全都道府県の喪男が参集するスレ
キミの勇者のワンダはセーラー勇者カワイイ
【渡辺満里奈】“桜”夕食会の明細書問題に「（不正なことを）やっていないんだったら証拠を出して」
DISCO☆TRAIN９
au Cyber-shot S006 by Sony Ericsson stage 21
【琉球新報】ソウルで慰安婦について聞かれて私は謝り、沖縄から来たと言うとアメリカ人に謝られ、どちらとも友だちになった［8/30］
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼