14/05/09 09:39:28.91 b6QXm0aH
レス番は投稿情報のハッシュ(仮にレスIDとする)とかにしとくと楽だわな
>>128
レスを識別する情報(レスID)をそのレスの全情報のハッシュにしとけば、
強衝突性を突破しない限り同一レスIDのレスを捏造することは阻止できる。
全コピーの削除はネットワークの規模と複製回数で頑張ればいいし、
不正な投稿(といっても問題なのは未来や過去のタイムスタンプ位か？)さえ防げればいい。
>>129>>132
直線構造に拘る必要はなくね？ツリーでも一方向メッシュでもそれなりの順序は持つし。
基本は直線で、分岐見つけたら全ての先端のIDを添付して合流させてけばいい。
表示順は原則タイムスタンプ順で、あまりに古いレスID使って伸びた枝は閲覧時に警告を付ける。
本格的にチェックしたいなら信用できるタイムスタンプサーバを借りて部分的にP2Pをやめる。
>>133
プロトコル的な攻撃の話って、攻撃→防御じゃなくてバグ→攻撃の順で考えたほうがいいと思う
というか既存投稿の上書きな改竄は、異なる内容のレスを別のレスとして扱う実装だと無意味になる
元の投稿消したデータ群渡されても、元の投稿を含むデータ群読んで差分を挿入して終わり
元の投稿を持つやつ全員が結託して抹消しない限り、そいつと接触できれば直ぐ復元できる
138:デフォルトの名無しさん
14/05/09 11:03:34.80 NbpGrdz5
特定のレスをNGにして、自分ノードではやりとりしないっていう機能も必要だね
薬売買とか個人情報のやりとりあるレスは持ちたくない人いるでしょ
手動でNGに入れるのも面倒だから
つまり共有NGみたいなものが必要になるのか？
139:デフォルトの名無しさん
14/05/09 15:06:49.62 gsXjT/a8
>>138
いちいち本文チェックなんてしたらクソ遅くなるわ
キャッシュと同じ扱いでいいだろ
140:デフォルトの名無しさん
14/05/09 15:09:17.80 gsXjT/a8
なんつーかツリー型サーバーでしか出てこない様な概念を持ち出してくる奴なんなの？
141:デフォルトの名無しさん
14/05/09 18:37:25.91 +yL8uyYO
レス順が変わることの本質はスレッドの分岐で、それをマージするときにノーチェックでやるのか？ってところがポイント
ノーチェックだとレスを自由に増やせると思うけどね
142:461 ◆Of8OpFdQADOA
14/05/10 02:49:08.11 wuv9w3Kh
そもそもどうして投稿をマージして、しかもそらを再送出する必要があるんですか。
その都度自分が表示できるレスを集めて表示すればいいじゃないですか。
143:デフォルトの名無しさん
14/05/10 03:10:36.81 qPsk9Q0C
>>140
データの最小単位が伝達する経路自体はツリーになるけどそういう話ではなく？
>>141
極端な話ネットワークが二分割されてから結合した場合はマージせざるを得ない。
分岐してマージされたレスは異常状態(ログ破損に近い状態)としてマークしといて、どう処理するかは各自自由とかでよくね？
表示順としてローカルでの取得順かタイムスタンプ順かも選択したい人は居るだろうし。
>>142
この場合のマージはレスにつけるメタ情報から構成されるツリー(チェイン)のマージだから関係ないかと。
スレを意味するブロックにレス番情報がある場合はそれが該当するし、
レス毎に投稿時点での最新レスIDを参照させる場合はそれが該当する。
順序を付ける利点は、不正な投稿時刻を前後のレスの投稿時刻で検証・排除出来る事と、
ネットワークの分断の発生をツリー情報から観測・表示しやすくなることなんかが有ると思う。
144:デフォルトの名無しさん
14/05/10 10:02:50.39 oq9GBtii
総論の話中だが、
要素技術にWebRTCのプラットフォームを使うのはどうだろう？
skyway
URLﾘﾝｸ(nttcom.github.io)
javascriptで開発できるから、web系の人も開発に参加できる。
145:デフォルトの名無しさん
14/05/10 10:41:46.80 qPsk9Q0C
>>144
SkyWayその物はNTTのクラウドサービスだから、
URLﾘﾝｸ(github.com)
辺りを使ってサーバを(あとTURNサポートしてるのでTURNサーバも)提供しなきゃ駄目だけど…
違うサーバにぶら下がるとネットワークが隔絶しちゃうのをどーにかせんと。
146:デフォルトの名無しさん
14/05/10 11:17:44.29 oq9GBtii
課題はあるけど、WEB系の技術を使うことができれば、
通常のWEB通信に紛れてプロバイダの方でブロックしにくい。
（暗号化すれば内容によるブロックもできない）
147:デフォルトの名無しさん
14/05/10 12:15:33.26 m9xHqVTZ
ほう、それでWEB系の技術だけで
暗号化するにはどうしたらいいのかね？
148:デフォルトの名無しさん
14/05/10 12:43:23.93 oq9GBtii
>>147
jsライブラリならいっぱいあるだろ。
149:デフォルトの名無しさん
14/05/10 14:43:55.94 qPsk9Q0C
>>147
コンテンツボディとして暗号化データ流せば済む話だが、
SSL/TLSを使ったHTTPSっていうプロトコルがあってだね…
ま、コンテンツボディを暗号化する場合だとヘッダ周りで検出されるが。
150:デフォルトの名無しさん
14/05/10 14:53:52.12 m9xHqVTZ
つまりはWEB系の技術というのは
要するに既存技術をJavaScriptで実装したものって
だけの話だな
151:デフォルトの名無しさん
14/05/10 15:18:11.43 qPsk9Q0C
WEB系の技術って既存技術の内WEB系の物って意味じゃねーの？
あと「JavaScriptで実装したもの」って制限はどっから出てきたん？
152:デフォルトの名無しさん
14/05/10 15:18:41.10 cY+uAlOa
WebRTC使うならOpenPeerがあるってだいぶ前に書いたよな
URLﾘﾝｸ(openpeer.org)
153:デフォルトの名無しさん
14/05/10 17:45:32.03 D1xN7jn3
>>143
普通は新規の書きこみが発生するたびに分岐するんじゃないのかな？
書きこみを受けとったノードが処理をして隣接ノードへの伝達(同期)は分岐処理になるのでは？
それとも新規書きこみは新規書きこみとしてDHTの隣接ノードに伝達されるのか？
この場合は各ノードが独自に新規書きこみの処理を行なうことになるが、分岐が起こらない場合は
その書きこみを所持しているべき全ノードがこの処理を行なうことが前提になると思うが
とても行儀の良い人だけが参加する理想的なネットワークが形成されることが前提になっているのでは？
154:デフォルトの名無しさん
14/05/11 09:02:01.38 HBJbY+fy
>>153
投稿を示すデータの塊をデータのハッシュをキーとして伝達すれば何処から何処へ移動しても変質しない
後はデータの塊の中に投稿時点で存在していた既存投稿のキーを含めれば参照関係ツリーは縦に伸びていく
書き込み処理といっても、投稿を示すキーに対する投稿を示すデータの塊がネットワーク上に追加されて、
スレッドを示す情報に順不同でそのスレッドに投稿された投稿のキーが追加されるだけで、この辺りに特殊な処理は必要ない
スレッドを示す情報側は順不同なのでネットワークが接触したら重複除いてマージするだけで良いし、
スレッドの分岐の痕跡や後始末は各投稿データに含まれる既存投稿キーを参照して表示時に解決すればよい
スレッドを示す情報にキーを追加する際は、キーが示すデータを検証してから追加する、とかは必要かな…
行儀に関しては連投DDoSあたりはproof of workとか仮想通貨を導入しないと対策できないんでほどほどでいいかと
155:デフォルトの名無しさん
14/05/11 09:41:42.34 z48caAbF
え？DDoS？
156:デフォルトの名無しさん
14/05/11 10:28:28.25 MfUQ5tqR
確定投稿と未確定投稿に分けて考えればいいんだよ。
特にフラグ設けなくてもレス番の有無で判断がつくし。
未確定投稿を２ｃｈ互換で掲示するのは無理なので、外部に掲示されるのは確定投稿になってからで、
拡散された状態で一足先に見ることができるのは参加者の特典でいいんじゃないかと？
157:デフォルトの名無しさん
14/05/11 18:29:50.66 HBJbY+fy
>>155
行儀の良くない人がどの程度まで想定するのか分からんかったから
防ぐのが困難なレベルの行儀の悪さを想定したらそうなった
>>156
なんでそんな時間差付ける必要が？…って思ったけど、確定未確定ってレス番の確定か
確定条件によるけど、分断状態でそれぞれが違う内容で確定させたら駄目なような…
あと、ここで言う分断は引き継ぎに失敗しつつ稼働するノード群が入れ違いに休眠した場合とかでも起きる筈