このスレは「P2P型の完全匿名掲示板はまだ出来ないの?」スレからforkして生まれました
2ちゃんの代替となる2ちゃん型掲示板をP2Pで実装してみようぜ、なスレです
名前が長いので若干スレタイは変えましたファイル共有ソフト等の話題はスレ違いなのです
origin:P2P型の完全匿名掲示板はまだ出来ないの?その4
http://toro.2ch.net/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ちゃんねる互換P2P匿名掲示板の実装を考える 1
■ このスレッドは過去ログ倉庫に格納されています
2014/04/23(水) 23:29:44.09ID:k48oXhUz
103デフォルトの名無しさん
2014/05/06(火) 20:55:23.86ID:WFxcGpUO104P.Yumina ◆Ky/cs3er/I
2014/05/06(火) 21:19:26.66ID:68cG1kKx >>103
それが作った自分も分かってないんだよwww
そもそも自分がP2Pを作ったのってP2Pシステムのテストをしたかったっていう
個人的な理由があったからなんだけど(その他にも色々理由はあったけど)、
P2P掲示板を作っても誰も使ってくれないから全くデータが取れなかったw
で、動画共有機能を追加したら多少はノードが増えると思っていたんだが
それでも全然増えなくて、これはいったん止めにするしかないわ、となった。
そんな訳で、直接配置でどれくらいパフォーマンスが出るのかはよく分からない。
ただ、10ノード程度で動いていたときはDHT絡みで特に問題はなかったと思う
(繋がらないノードの扱いには結構苦労した記憶があるけど)。
それが作った自分も分かってないんだよwww
そもそも自分がP2Pを作ったのってP2Pシステムのテストをしたかったっていう
個人的な理由があったからなんだけど(その他にも色々理由はあったけど)、
P2P掲示板を作っても誰も使ってくれないから全くデータが取れなかったw
で、動画共有機能を追加したら多少はノードが増えると思っていたんだが
それでも全然増えなくて、これはいったん止めにするしかないわ、となった。
そんな訳で、直接配置でどれくらいパフォーマンスが出るのかはよく分からない。
ただ、10ノード程度で動いていたときはDHT絡みで特に問題はなかったと思う
(繋がらないノードの扱いには結構苦労した記憶があるけど)。
105デフォルトの名無しさん
2014/05/06(火) 21:25:59.34ID:Fr+PW76D インフラが整ってきたせいで
P2Pの必要性が減ってきてしまったからね。
動画配信はP2Pの出番のように
考えられていた時期もあったけど、
今や個人が無料で配信できてしまう時代。
P2Pよりも優れていて、すぐに再生できる
アップ者はアップが終わったらネットに繋がなくていいといった
メリットもある。この点でP2Pを超えてしまっている。
P2Pの必要性が減ってきてしまったからね。
動画配信はP2Pの出番のように
考えられていた時期もあったけど、
今や個人が無料で配信できてしまう時代。
P2Pよりも優れていて、すぐに再生できる
アップ者はアップが終わったらネットに繋がなくていいといった
メリットもある。この点でP2Pを超えてしまっている。
106デフォルトの名無しさん
2014/05/06(火) 22:17:05.56ID:soHpq/YZ 作るやつがいないものをいくら議論したって無駄だろ。
107デフォルトの名無しさん
2014/05/07(水) 01:17:20.12ID:eSaIM8aR108デフォルトの名無しさん
2014/05/07(水) 02:19:06.09ID:2caJ5LuF CREAのひとだったのか
匿名にするなら実データをバケツリレーでポストしないと誰が書いたかバレバレになるよ
匿名にするなら実データをバケツリレーでポストしないと誰が書いたかバレバレになるよ
109デフォルトの名無しさん
2014/05/07(水) 06:03:42.93ID:S8HTbvhn 匿名にする必要ないだろ。
110デフォルトの名無しさん
2014/05/07(水) 18:11:42.50ID:Vbe/shdF >>38
golangみたいな今日明日にでも消えそうな言語で開発とかww
golangみたいな今日明日にでも消えそうな言語で開発とかww
111デフォルトの名無しさん
2014/05/07(水) 20:37:08.51ID:E+53UQ5m goはいい言語だと思うけど「俺がgoで作ってやったったwww」ぐらいじゃないと使うことにはならないだろうな
112デフォルトの名無しさん
2014/05/08(木) 07:36:21.65ID:tK+74K/E >>95
でかいコンテンツを直接格納するとそのキーを割り当てられた奴が悲惨なことになるから、
格納するデータをメタデータや十分に分割した物する実装じゃないと実用にならないんじゃないの?
>>96
前スレでChordかなんかでの一例は出てたね。クライアントが制御しきれない情報(例:IPアドレス)のハッシュ+α
>>98
ビットトレントのDHT(Kademliaだっけ?)はトレントファイルを共有してた筈だけど、
トレントファイルをコンテンツとみなせば直接格納には該当しないかな?実装知らんので詳しく分からん。
>>102
匿名化って目的のために帯域を消費して中継してんだから、無駄ではないだろ。
あんまりスマートではないけど、だからって「まともでない」って判断はどーかと。
匿名性が必要か否かは別の議論。
でかいコンテンツを直接格納するとそのキーを割り当てられた奴が悲惨なことになるから、
格納するデータをメタデータや十分に分割した物する実装じゃないと実用にならないんじゃないの?
>>96
前スレでChordかなんかでの一例は出てたね。クライアントが制御しきれない情報(例:IPアドレス)のハッシュ+α
>>98
ビットトレントのDHT(Kademliaだっけ?)はトレントファイルを共有してた筈だけど、
トレントファイルをコンテンツとみなせば直接格納には該当しないかな?実装知らんので詳しく分からん。
>>102
匿名化って目的のために帯域を消費して中継してんだから、無駄ではないだろ。
あんまりスマートではないけど、だからって「まともでない」って判断はどーかと。
匿名性が必要か否かは別の議論。
113デフォルトの名無しさん
2014/05/08(木) 08:45:43.26ID:aLJM5gos114デフォルトの名無しさん
2014/05/08(木) 09:12:30.09ID:tK+74K/E >>113
だね。2chのスレッドは1スレッド512kBいかない程度な事も多いから、スレッド単位かレス単位かは悩ましそうだけど…
だね。2chのスレッドは1スレッド512kBいかない程度な事も多いから、スレッド単位かレス単位かは悩ましそうだけど…
115デフォルトの名無しさん
2014/05/08(木) 09:37:14.61ID:aLJM5gos google app engineの仕様では1キー1MBだから、それに合わせてもいいね。
116デフォルトの名無しさん
2014/05/08(木) 09:42:07.96ID:aLJM5gos DHTで掲示板を作る事自体は簡単なんだけど、
問題は、P2Pではピアが信用出来ないので、
改ざん耐性を高める必要があって、どういう設計をすればよいか、なんだよねぇ。
問題は、P2Pではピアが信用出来ないので、
改ざん耐性を高める必要があって、どういう設計をすればよいか、なんだよねぇ。
117デフォルトの名無しさん
2014/05/08(木) 09:44:19.68ID:aLJM5gos つまり、自分が所有するピアのデータを自分自身で書き換えられないか、
書き換えた事が検出可能な設計にするにはどうすればよいか。
書き換えた事が検出可能な設計にするにはどうすればよいか。
118デフォルトの名無しさん
2014/05/08(木) 09:49:16.77ID:rrq/Td9f 複数のソースをゲットすればいい
別ルートからのデータを比較して同一じゃなければ改ざん認定
正しいのがどれか判別する方法は知らん
別ルートからのデータを比較して同一じゃなければ改ざん認定
正しいのがどれか判別する方法は知らん
119デフォルトの名無しさん
2014/05/08(木) 09:50:37.46ID:rrq/Td9f データと書いたがハッシュね
120デフォルトの名無しさん
2014/05/08(木) 09:54:07.68ID:rrq/Td9f 確率論的には3つのうち1つだけ違っていたらそれが改ざんとしてしまってもいい
121デフォルトの名無しさん
2014/05/08(木) 13:47:43.26ID:aLJM5gos あと、掲示板のレスの順番は正確でなければならないが、
ACID(atomicity, consistency, isolation, durability)をどうやって保証するか。
P2PのDHTでのACID保証について議論したい
ACID(atomicity, consistency, isolation, durability)をどうやって保証するか。
P2PのDHTでのACID保証について議論したい
122デフォルトの名無しさん
2014/05/08(木) 13:52:15.09ID:rrq/Td9f >>121
実際の処理はユニークIDで処理して、UIに番号で表示すればよい
実際の処理はユニークIDで処理して、UIに番号で表示すればよい
123デフォルトの名無しさん
2014/05/08(木) 13:54:55.86ID:rrq/Td9f P2PでACIDという発想がどこから出てくるのか
124デフォルトの名無しさん
2014/05/08(木) 14:12:32.37ID:tK+74K/E >>123
P2Pというか、分散DBの類だからこそACID意識するんじゃないの?
P2Pというか、分散DBの類だからこそACID意識するんじゃないの?
125デフォルトの名無しさん
2014/05/08(木) 14:29:26.84ID:aLJM5gos126デフォルトの名無しさん
2014/05/08(木) 14:41:08.06ID:aLJM5gos レス1の次に書き込まれたレスは、必ずレス2にならなくてはならない。
これを保証するにはどういう設計にすればよいのだろう。
これを保証するにはどういう設計にすればよいのだろう。
127デフォルトの名無しさん
2014/05/08(木) 14:45:19.56ID:rrq/Td9f128デフォルトの名無しさん
2014/05/08(木) 14:53:49.00ID:5NN0m/yU レスが改竄されないことを前提とすると
レス2にレス1のハッシュ値を添付しなければならないようにすれば
少なくともレス2がレス1より前に存在しなかったことは保証できるな
レスが改竄されない方法は知らんw
掲示板のためにproof of workを使うのはコスト高すぎだろうしなー
まあ、多少順番が狂っても別にいいと思うけど
レス2にレス1のハッシュ値を添付しなければならないようにすれば
少なくともレス2がレス1より前に存在しなかったことは保証できるな
レスが改竄されない方法は知らんw
掲示板のためにproof of workを使うのはコスト高すぎだろうしなー
まあ、多少順番が狂っても別にいいと思うけど
129デフォルトの名無しさん
2014/05/08(木) 15:30:16.25ID:lBa33A+E 必ず分岐が起こるがその場合どうするのか?
単純にタイムスタンプで同期させると改竄が容易になる。
改竄に対しては多数決で改竄防止という話が出ているが、
そうすれば新規書きこみは全て捨てられることになる
単純にタイムスタンプで同期させると改竄が容易になる。
改竄に対しては多数決で改竄防止という話が出ているが、
そうすれば新規書きこみは全て捨てられることになる
130デフォルトの名無しさん
2014/05/08(木) 20:32:46.09ID:oHeX29Ky レスの順番なんてどうでもいいだろ
本当に必要な場面になったら、後から安価して順序を説明すりゃいい
本当に必要な場面になったら、後から安価して順序を説明すりゃいい
131デフォルトの名無しさん
2014/05/08(木) 20:42:45.56ID:Lwvjy9Um 順序の制御は無理だろう
>>127 のいうとおりだ、UI に渡すときに整合性が取れていればなんら問題ない、そのためにアンカー先を別途探しにいく実装があってもよい
アンカー先探しをあきらめる条件をどうするか、だね
>>127 のいうとおりだ、UI に渡すときに整合性が取れていればなんら問題ない、そのためにアンカー先を別途探しにいく実装があってもよい
アンカー先探しをあきらめる条件をどうするか、だね
132デフォルトの名無しさん
2014/05/08(木) 21:07:16.40ID:lBa33A+E レス順が変わるのはスレッドが分岐したときの副作用で、この分岐には適切に対処しないと改竄スレッドを流されてしまう穴になる
書きこみを複数のノードに投げて、最新スレッドの取得同期は多数決にすると最新投稿が捨てられる可能性が高くなる
書きこみを複数のノードに投げて、最新スレッドの取得同期は多数決にすると最新投稿が捨てられる可能性が高くなる
133デフォルトの名無しさん
2014/05/08(木) 21:12:09.26ID:oHeX29Ky 改竄は防げない前提で考えたほうがいいんじゃないの?
された場合にどうするかを考えたほうが現実的な気がする
例えば、他の人とログを比べて改竄されてそうな場所をピックアップする機能とか
改竄してまくってそうなやつをブロックする機能とかあればいいんでない?
された場合にどうするかを考えたほうが現実的な気がする
例えば、他の人とログを比べて改竄されてそうな場所をピックアップする機能とか
改竄してまくってそうなやつをブロックする機能とかあればいいんでない?
134デフォルトの名無しさん
2014/05/08(木) 21:16:48.49ID:JZCmTzL0 内容に不一致があればそれ以降はフォークとみなすしかないんじゃね
135デフォルトの名無しさん
2014/05/08(木) 21:23:14.60ID:oHeX29Ky ワーキングディレクトリに他のノードからの更新を受けておいて、
そこから手動で自分のログに指定したレスをプルする。
こうすれば常に綺麗な状態は保てるんじゃない?
プル地獄になりそうだけど
そこから手動で自分のログに指定したレスをプルする。
こうすれば常に綺麗な状態は保てるんじゃない?
プル地獄になりそうだけど
136461 ◆Of8OpFdQADOA
2014/05/08(木) 22:04:50.39ID:fes617/2 私の実装ではレスごとに固有のIDを与えて内部で自動変換していますね。
見た目が変わらなければどうということはないです。
見た目が変わらなければどうということはないです。
137デフォルトの名無しさん
2014/05/09(金) 09:39:28.91ID:b6QXm0aH レス番は投稿情報のハッシュ(仮にレスIDとする)とかにしとくと楽だわな
>>128
レスを識別する情報(レスID)をそのレスの全情報のハッシュにしとけば、
強衝突性を突破しない限り同一レスIDのレスを捏造することは阻止できる。
全コピーの削除はネットワークの規模と複製回数で頑張ればいいし、
不正な投稿(といっても問題なのは未来や過去のタイムスタンプ位か?)さえ防げればいい。
>>129>>132
直線構造に拘る必要はなくね?ツリーでも一方向メッシュでもそれなりの順序は持つし。
基本は直線で、分岐見つけたら全ての先端のIDを添付して合流させてけばいい。
表示順は原則タイムスタンプ順で、あまりに古いレスID使って伸びた枝は閲覧時に警告を付ける。
本格的にチェックしたいなら信用できるタイムスタンプサーバを借りて部分的にP2Pをやめる。
>>133
プロトコル的な攻撃の話って、攻撃→防御じゃなくてバグ→攻撃の順で考えたほうがいいと思う
というか既存投稿の上書きな改竄は、異なる内容のレスを別のレスとして扱う実装だと無意味になる
元の投稿消したデータ群渡されても、元の投稿を含むデータ群読んで差分を挿入して終わり
元の投稿を持つやつ全員が結託して抹消しない限り、そいつと接触できれば直ぐ復元できる
>>128
レスを識別する情報(レスID)をそのレスの全情報のハッシュにしとけば、
強衝突性を突破しない限り同一レスIDのレスを捏造することは阻止できる。
全コピーの削除はネットワークの規模と複製回数で頑張ればいいし、
不正な投稿(といっても問題なのは未来や過去のタイムスタンプ位か?)さえ防げればいい。
>>129>>132
直線構造に拘る必要はなくね?ツリーでも一方向メッシュでもそれなりの順序は持つし。
基本は直線で、分岐見つけたら全ての先端のIDを添付して合流させてけばいい。
表示順は原則タイムスタンプ順で、あまりに古いレスID使って伸びた枝は閲覧時に警告を付ける。
本格的にチェックしたいなら信用できるタイムスタンプサーバを借りて部分的にP2Pをやめる。
>>133
プロトコル的な攻撃の話って、攻撃→防御じゃなくてバグ→攻撃の順で考えたほうがいいと思う
というか既存投稿の上書きな改竄は、異なる内容のレスを別のレスとして扱う実装だと無意味になる
元の投稿消したデータ群渡されても、元の投稿を含むデータ群読んで差分を挿入して終わり
元の投稿を持つやつ全員が結託して抹消しない限り、そいつと接触できれば直ぐ復元できる
138デフォルトの名無しさん
2014/05/09(金) 11:03:34.80ID:NbpGrdz5 特定のレスをNGにして、自分ノードではやりとりしないっていう機能も必要だね
薬売買とか個人情報のやりとりあるレスは持ちたくない人いるでしょ
手動でNGに入れるのも面倒だから
つまり共有NGみたいなものが必要になるのか?
薬売買とか個人情報のやりとりあるレスは持ちたくない人いるでしょ
手動でNGに入れるのも面倒だから
つまり共有NGみたいなものが必要になるのか?
139デフォルトの名無しさん
2014/05/09(金) 15:06:49.62ID:gsXjT/a8140デフォルトの名無しさん
2014/05/09(金) 15:09:17.80ID:gsXjT/a8 なんつーかツリー型サーバーでしか出てこない様な概念を持ち出してくる奴なんなの?
141デフォルトの名無しさん
2014/05/09(金) 18:37:25.91ID:+yL8uyYO レス順が変わることの本質はスレッドの分岐で、それをマージするときにノーチェックでやるのか?ってところがポイント
ノーチェックだとレスを自由に増やせると思うけどね
ノーチェックだとレスを自由に増やせると思うけどね
142461 ◆Of8OpFdQADOA
2014/05/10(土) 02:49:08.11ID:wuv9w3Kh そもそもどうして投稿をマージして、しかもそらを再送出する必要があるんですか。
その都度自分が表示できるレスを集めて表示すればいいじゃないですか。
その都度自分が表示できるレスを集めて表示すればいいじゃないですか。
143デフォルトの名無しさん
2014/05/10(土) 03:10:36.81ID:qPsk9Q0C >>140
データの最小単位が伝達する経路自体はツリーになるけどそういう話ではなく?
>>141
極端な話ネットワークが二分割されてから結合した場合はマージせざるを得ない。
分岐してマージされたレスは異常状態(ログ破損に近い状態)としてマークしといて、どう処理するかは各自自由とかでよくね?
表示順としてローカルでの取得順かタイムスタンプ順かも選択したい人は居るだろうし。
>>142
この場合のマージはレスにつけるメタ情報から構成されるツリー(チェイン)のマージだから関係ないかと。
スレを意味するブロックにレス番情報がある場合はそれが該当するし、
レス毎に投稿時点での最新レスIDを参照させる場合はそれが該当する。
順序を付ける利点は、不正な投稿時刻を前後のレスの投稿時刻で検証・排除出来る事と、
ネットワークの分断の発生をツリー情報から観測・表示しやすくなることなんかが有ると思う。
データの最小単位が伝達する経路自体はツリーになるけどそういう話ではなく?
>>141
極端な話ネットワークが二分割されてから結合した場合はマージせざるを得ない。
分岐してマージされたレスは異常状態(ログ破損に近い状態)としてマークしといて、どう処理するかは各自自由とかでよくね?
表示順としてローカルでの取得順かタイムスタンプ順かも選択したい人は居るだろうし。
>>142
この場合のマージはレスにつけるメタ情報から構成されるツリー(チェイン)のマージだから関係ないかと。
スレを意味するブロックにレス番情報がある場合はそれが該当するし、
レス毎に投稿時点での最新レスIDを参照させる場合はそれが該当する。
順序を付ける利点は、不正な投稿時刻を前後のレスの投稿時刻で検証・排除出来る事と、
ネットワークの分断の発生をツリー情報から観測・表示しやすくなることなんかが有ると思う。
144デフォルトの名無しさん
2014/05/10(土) 10:02:50.39ID:oq9GBtii 総論の話中だが、
要素技術にWebRTCのプラットフォームを使うのはどうだろう?
skyway
http://nttcom.github.io/skyway/
javascriptで開発できるから、web系の人も開発に参加できる。
要素技術にWebRTCのプラットフォームを使うのはどうだろう?
skyway
http://nttcom.github.io/skyway/
javascriptで開発できるから、web系の人も開発に参加できる。
145デフォルトの名無しさん
2014/05/10(土) 10:41:46.80ID:qPsk9Q0C >>144
SkyWayその物はNTTのクラウドサービスだから、
https://github.com/peers/peerjs-server
辺りを使ってサーバを(あとTURNサポートしてるのでTURNサーバも)提供しなきゃ駄目だけど…
違うサーバにぶら下がるとネットワークが隔絶しちゃうのをどーにかせんと。
SkyWayその物はNTTのクラウドサービスだから、
https://github.com/peers/peerjs-server
辺りを使ってサーバを(あとTURNサポートしてるのでTURNサーバも)提供しなきゃ駄目だけど…
違うサーバにぶら下がるとネットワークが隔絶しちゃうのをどーにかせんと。
146デフォルトの名無しさん
2014/05/10(土) 11:17:44.29ID:oq9GBtii 課題はあるけど、WEB系の技術を使うことができれば、
通常のWEB通信に紛れてプロバイダの方でブロックしにくい。
(暗号化すれば内容によるブロックもできない)
通常のWEB通信に紛れてプロバイダの方でブロックしにくい。
(暗号化すれば内容によるブロックもできない)
147デフォルトの名無しさん
2014/05/10(土) 12:15:33.26ID:m9xHqVTZ ほう、それでWEB系の技術だけで
暗号化するにはどうしたらいいのかね?
暗号化するにはどうしたらいいのかね?
148デフォルトの名無しさん
2014/05/10(土) 12:43:23.93ID:oq9GBtii >>147
jsライブラリならいっぱいあるだろ。
jsライブラリならいっぱいあるだろ。
149デフォルトの名無しさん
2014/05/10(土) 14:43:55.94ID:qPsk9Q0C150デフォルトの名無しさん
2014/05/10(土) 14:53:52.12ID:m9xHqVTZ つまりはWEB系の技術というのは
要するに既存技術をJavaScriptで実装したものって
だけの話だな
要するに既存技術をJavaScriptで実装したものって
だけの話だな
151デフォルトの名無しさん
2014/05/10(土) 15:18:11.43ID:qPsk9Q0C WEB系の技術って既存技術の内WEB系の物って意味じゃねーの?
あと「JavaScriptで実装したもの」って制限はどっから出てきたん?
あと「JavaScriptで実装したもの」って制限はどっから出てきたん?
152デフォルトの名無しさん
2014/05/10(土) 15:18:41.10ID:cY+uAlOa WebRTC使うならOpenPeerがあるってだいぶ前に書いたよな
http://openpeer.org
http://openpeer.org
153デフォルトの名無しさん
2014/05/10(土) 17:45:32.03ID:D1xN7jn3 >>143
普通は新規の書きこみが発生するたびに分岐するんじゃないのかな?
書きこみを受けとったノードが処理をして隣接ノードへの伝達(同期)は分岐処理になるのでは?
それとも新規書きこみは新規書きこみとしてDHTの隣接ノードに伝達されるのか?
この場合は各ノードが独自に新規書きこみの処理を行なうことになるが、分岐が起こらない場合は
その書きこみを所持しているべき全ノードがこの処理を行なうことが前提になると思うが
とても行儀の良い人だけが参加する理想的なネットワークが形成されることが前提になっているのでは?
普通は新規の書きこみが発生するたびに分岐するんじゃないのかな?
書きこみを受けとったノードが処理をして隣接ノードへの伝達(同期)は分岐処理になるのでは?
それとも新規書きこみは新規書きこみとしてDHTの隣接ノードに伝達されるのか?
この場合は各ノードが独自に新規書きこみの処理を行なうことになるが、分岐が起こらない場合は
その書きこみを所持しているべき全ノードがこの処理を行なうことが前提になると思うが
とても行儀の良い人だけが参加する理想的なネットワークが形成されることが前提になっているのでは?
154デフォルトの名無しさん
2014/05/11(日) 09:02:01.38ID:HBJbY+fy >>153
投稿を示すデータの塊をデータのハッシュをキーとして伝達すれば何処から何処へ移動しても変質しない
後はデータの塊の中に投稿時点で存在していた既存投稿のキーを含めれば参照関係ツリーは縦に伸びていく
書き込み処理といっても、投稿を示すキーに対する投稿を示すデータの塊がネットワーク上に追加されて、
スレッドを示す情報に順不同でそのスレッドに投稿された投稿のキーが追加されるだけで、この辺りに特殊な処理は必要ない
スレッドを示す情報側は順不同なのでネットワークが接触したら重複除いてマージするだけで良いし、
スレッドの分岐の痕跡や後始末は各投稿データに含まれる既存投稿キーを参照して表示時に解決すればよい
スレッドを示す情報にキーを追加する際は、キーが示すデータを検証してから追加する、とかは必要かな…
行儀に関しては連投DDoSあたりはproof of workとか仮想通貨を導入しないと対策できないんでほどほどでいいかと
投稿を示すデータの塊をデータのハッシュをキーとして伝達すれば何処から何処へ移動しても変質しない
後はデータの塊の中に投稿時点で存在していた既存投稿のキーを含めれば参照関係ツリーは縦に伸びていく
書き込み処理といっても、投稿を示すキーに対する投稿を示すデータの塊がネットワーク上に追加されて、
スレッドを示す情報に順不同でそのスレッドに投稿された投稿のキーが追加されるだけで、この辺りに特殊な処理は必要ない
スレッドを示す情報側は順不同なのでネットワークが接触したら重複除いてマージするだけで良いし、
スレッドの分岐の痕跡や後始末は各投稿データに含まれる既存投稿キーを参照して表示時に解決すればよい
スレッドを示す情報にキーを追加する際は、キーが示すデータを検証してから追加する、とかは必要かな…
行儀に関しては連投DDoSあたりはproof of workとか仮想通貨を導入しないと対策できないんでほどほどでいいかと
155デフォルトの名無しさん
2014/05/11(日) 09:41:42.34ID:z48caAbF え?DDoS?
156デフォルトの名無しさん
2014/05/11(日) 10:28:28.25ID:MfUQ5tqR 確定投稿と未確定投稿に分けて考えればいいんだよ。
特にフラグ設けなくてもレス番の有無で判断がつくし。
未確定投稿を2ch互換で掲示するのは無理なので、外部に掲示されるのは確定投稿になってからで、
拡散された状態で一足先に見ることができるのは参加者の特典でいいんじゃないかと?
特にフラグ設けなくてもレス番の有無で判断がつくし。
未確定投稿を2ch互換で掲示するのは無理なので、外部に掲示されるのは確定投稿になってからで、
拡散された状態で一足先に見ることができるのは参加者の特典でいいんじゃないかと?
157デフォルトの名無しさん
2014/05/11(日) 18:29:50.66ID:HBJbY+fy158デフォルトの名無しさん
2014/05/18(日) 19:40:42.92ID:oxq+ikAO >>48
hidden service の情報が FBI にごっそり抜かれたそうだ、pure でない限り必ず弱点が発生するね
http://www.gizmodo.jp/2013/08/post_12892.html
tor 規制も遠くない
hidden service の情報が FBI にごっそり抜かれたそうだ、pure でない限り必ず弱点が発生するね
http://www.gizmodo.jp/2013/08/post_12892.html
tor 規制も遠くない
159デフォルトの名無しさん
2014/05/19(月) 07:33:43.51ID:xEeDrkw/ 記事の内容読んだか?
>Firefoxの脆弱性を突いてTorユーザーの身元を特定できるカスタムのマルウェアが広まっていたんですね。
FBIがスパイウェア撒いたって話だから、通信形態は関係ない
>Firefoxの脆弱性を突いてTorユーザーの身元を特定できるカスタムのマルウェアが広まっていたんですね。
FBIがスパイウェア撒いたって話だから、通信形態は関係ない
160デフォルトの名無しさん
2014/05/19(月) 17:58:41.42ID:WT1tTslw アノニマスが開発した「AirChat」が凄い!インターネットなしでデータ通信
http://blog.livedoor.jp/itsoku/archives/38902170.html
http://blog.livedoor.jp/itsoku/archives/38902170.html
161デフォルトの名無しさん
2014/05/19(月) 21:46:42.22ID:lhsjIgd7 >>160
読んでないけど、手旗信号と見た
読んでないけど、手旗信号と見た
162デフォルトの名無しさん
2014/05/19(月) 22:31:10.57ID:zujUZLqg 最終的にはインターネットに繋がるらしいが、
「ローカルネットを沢山繋いでインターネット」
って意味で言うと結局インターネットの一部なんだよな。
-- 我々はボーグだ。お前達は同化される。抵抗は無意味だ。
「ローカルネットを沢山繋いでインターネット」
って意味で言うと結局インターネットの一部なんだよな。
-- 我々はボーグだ。お前達は同化される。抵抗は無意味だ。
163デフォルトの名無しさん
2014/05/19(月) 23:14:38.92ID:rPuNmFhW だから、DSの擦れ違い通信だって
164デフォルトの名無しさん
2014/05/20(火) 03:58:15.26ID:XZ8PbsoH いつのまにか Vidalia 単体のダウンロードができなくなった‥
ブラウザででしか使用できない‥
ブラウザででしか使用できない‥
165デフォルトの名無しさん
2014/05/20(火) 06:54:05.58ID:gZsncm2t 素人には危険だからかな
166デフォルトの名無しさん
2014/05/20(火) 10:24:43.89ID:PJc6Nn45 https://github.com/gitchain/gitchain
これまんま掲示板に転用できないか?
これまんま掲示板に転用できないか?
167461 ◆Of8OpFdQADOA
2014/05/24(土) 18:37:39.78ID:OAvaL96R 開発者向けの話題を提供しましょう。
ノード間のメッセージングにはTCPかUDPを使われるかと思いますが、皆さんならプロトコルをどう設計しますか?
バイナリで組む人もおられるでしょうし、HTTP風にテキストベースで書く人もおられると思うのですが、皆さんの知恵を聞かせてください。
ノード間のメッセージングにはTCPかUDPを使われるかと思いますが、皆さんならプロトコルをどう設計しますか?
バイナリで組む人もおられるでしょうし、HTTP風にテキストベースで書く人もおられると思うのですが、皆さんの知恵を聞かせてください。
168デフォルトの名無しさん
2014/05/24(土) 19:40:20.45ID:uWBH7T6t そんなのどっちでもよい
169デフォルトの名無しさん
2014/05/24(土) 19:59:57.61ID:jYoMAPG8 >>167
こっちでは今PDですら遮断される状況だから偽装してほしいな
こっちでは今PDですら遮断される状況だから偽装してほしいな
170デフォルトの名無しさん
2014/05/24(土) 20:32:26.64ID:7m1F5+NU 今迄のは開発者の話題ではないと思ってたのか。なんかこいつにイラっとくるのってオレだけかな
171デフォルトの名無しさん
2014/05/24(土) 20:33:42.07ID:9qFFfmjf >>170
アスペかよ
アスペかよ
172デフォルトの名無しさん
2014/05/24(土) 20:35:25.26ID:8L8QZ0Si >>167
扱いやすいしバイナリ一択だな
扱いやすいしバイナリ一択だな
173デフォルトの名無しさん
2014/05/24(土) 20:44:07.64ID:uWBH7T6t そんなのどうでもいいって言った理由は、
バイナリかテキストかによってアプリの機能や
開発しやすさになんら影響をあたえることがないから。
プロトコルをオープンにしてだれでもあつえるようにするなら
テキストのほうがやりやすいだろうし、逆に解析をしづらくしたいのなら
バイナリのほうがいいだろう。程度の意味しかない。
アプリからすれば、そんなプロトコルの違いは、下層のレイヤーが
吸収してオブジェクトの形にするから、どっちでも同じだし、
あとから変えることだって簡単。プロトコルの命令の種類の話しならともかく。
テキストかバイナリかという表現形式なんか、どうでもいい。
バイナリかテキストかによってアプリの機能や
開発しやすさになんら影響をあたえることがないから。
プロトコルをオープンにしてだれでもあつえるようにするなら
テキストのほうがやりやすいだろうし、逆に解析をしづらくしたいのなら
バイナリのほうがいいだろう。程度の意味しかない。
アプリからすれば、そんなプロトコルの違いは、下層のレイヤーが
吸収してオブジェクトの形にするから、どっちでも同じだし、
あとから変えることだって簡単。プロトコルの命令の種類の話しならともかく。
テキストかバイナリかという表現形式なんか、どうでもいい。
174デフォルトの名無しさん
2014/05/24(土) 21:07:02.75ID:8L8QZ0Si 機能面ではそうだが、テキストはパースにも構築にも、バイナリに比べて数十倍数百倍の時間が掛かるからなぁ
比較とかもバイナリの方が簡単だし
比較とかもバイナリの方が簡単だし
175デフォルトの名無しさん
2014/05/24(土) 21:13:01.28ID:uWBH7T6t それは全体の1%にも満たない部分だから
時間がかかっても問題ない。
時間がかかっても問題ない。
176デフォルトの名無しさん
2014/05/24(土) 21:15:21.89ID:oWuOT6f1 どうでもいいことに拘ってないで、まずは要件定義をしろw
177デフォルトの名無しさん
2014/05/24(土) 22:08:44.78ID:7CvGDBUR >>167
UDPで経路毎の最大パケットサイズ調べたりメッセージ分割したり結合したり、絶対ダルいからUDPは嫌だな
バイナリで組むかテキストで組むかは趣味の領域な気もするけど…
単一接続で長いメッセージを含む複数のメッセージを送る場合はテキストだと無駄が多い気がする
ていうかそれ以前に遮断の防止などでSSLなどに偽装したコネクション張る事から考える
UDPで経路毎の最大パケットサイズ調べたりメッセージ分割したり結合したり、絶対ダルいからUDPは嫌だな
バイナリで組むかテキストで組むかは趣味の領域な気もするけど…
単一接続で長いメッセージを含む複数のメッセージを送る場合はテキストだと無駄が多い気がする
ていうかそれ以前に遮断の防止などでSSLなどに偽装したコネクション張る事から考える
178デフォルトの名無しさん
2014/05/24(土) 22:48:03.61ID:oWuOT6f1 要素技術なんぞ詳細設計の段階の話だろうがw
まずは要件定義しろw
まずは要件定義しろw
179デフォルトの名無しさん
2014/05/24(土) 23:07:23.72ID:rfdD6r00 Unicodeをデフォルトにしようず。
UTF-8が無難だが日本的にはUTF-32にも惹かれる
UTF-8が無難だが日本的にはUTF-32にも惹かれる
180Unicodeキボンヌ
2014/05/25(日) 00:00:09.81ID:wqNjSVko 書込時の匿名性はP2Pによって実現するといっても、
閲覧時にP2Pは不要(cf.新月ネットワークの場合は閲覧用にもP2Pを利用する)。
サーバーは有志の運営に委ねる(中央集権的管理の完全否定)。
運営者は現在の2ちゃんねるの過去ログ転載サイトのように、広告収益などを目当てにネットワーク資源を提供すればよい。
サーバーのログ上の特定の書き込みを、何らかの問題発生時に、削除するかしないかは各サーバー管理者の判断による。
サーバー間の信頼関係システムも設け、専門外の板については、他サーバーのログをそのまま信用してクローンする。
理想的にはスレ毎に、スレ立て人自身が管理者となって、サーバーを立てているような状態。
ちゃんと管理されているスレは繁栄することが期待できる。
一般ユーザーの書き込みの匿名性は、P2Pによって、ユーザー同士の端末を一定HOP経由してから、サーバーへの書き込みがされるようにする。
サーバー同士の書き込みの伝播にまでP2Pを適用するかどうかは、確保したい匿名性のレベルの議論による。
閲覧時にP2Pは不要(cf.新月ネットワークの場合は閲覧用にもP2Pを利用する)。
サーバーは有志の運営に委ねる(中央集権的管理の完全否定)。
運営者は現在の2ちゃんねるの過去ログ転載サイトのように、広告収益などを目当てにネットワーク資源を提供すればよい。
サーバーのログ上の特定の書き込みを、何らかの問題発生時に、削除するかしないかは各サーバー管理者の判断による。
サーバー間の信頼関係システムも設け、専門外の板については、他サーバーのログをそのまま信用してクローンする。
理想的にはスレ毎に、スレ立て人自身が管理者となって、サーバーを立てているような状態。
ちゃんと管理されているスレは繁栄することが期待できる。
一般ユーザーの書き込みの匿名性は、P2Pによって、ユーザー同士の端末を一定HOP経由してから、サーバーへの書き込みがされるようにする。
サーバー同士の書き込みの伝播にまでP2Pを適用するかどうかは、確保したい匿名性のレベルの議論による。
181デフォルトの名無しさん
2014/05/25(日) 02:30:20.38ID:UOeAOsx2 >180
つまり、一番最初に見た人が、
一番最初に書き込んだ人である確率が極めて高い
ってことでいいですか?w
つまり、一番最初に見た人が、
一番最初に書き込んだ人である確率が極めて高い
ってことでいいですか?w
182Unicodeキボンヌ
2014/05/25(日) 04:05:32.41ID:wqNjSVko 意味不明。
サーバーに反映されないと誰も見れないのに、なぜそうなるの?
サーバーに反映されないと誰も見れないのに、なぜそうなるの?
183デフォルトの名無しさん
2014/05/25(日) 04:51:54.21ID:dtutVys2 >>180
匿名化対象は、投稿者→匿名、配信者→公開、閲覧者→公開、だと仮定して、
その構造でサーバ間を暗号化する目的がよく分からんのだが…
サーバの持ってる前データはオープンで、サーバにデータを投稿した人間は不明でしょ?
サーバ間での同期は複製元も複製先もオープンで、匿名化すべき部分が見当たらないのだけど。
それとも匿名化対象が、投稿者→匿名、配信者→公開、閲覧者→匿名、であり、
複製先サーバがオープンな配信者として動作しない、読み専の閲覧者である場合も含むってこと?
>>182
閲覧に関して普通の専ブラと同じ方式をとった場合は、
投稿者は書き込み直後にそのスレの更新動作をする。
この動作は他の閲覧者の自動更新や手動更新よりも先行する可能性が非常に高い。
プッシュ配信でもしてしまって投稿者閲覧者問わずに更新させるか、
閲覧に関してもオニオンルーティングするかしないと隠蔽できない。
プッシュ配信だと閲覧者数が少ない場合に投稿者がバレてしまうので、
閲覧者数が少ないスレッドでは匿名読み込みに切り替えないと不味い、かな。
匿名化対象は、投稿者→匿名、配信者→公開、閲覧者→公開、だと仮定して、
その構造でサーバ間を暗号化する目的がよく分からんのだが…
サーバの持ってる前データはオープンで、サーバにデータを投稿した人間は不明でしょ?
サーバ間での同期は複製元も複製先もオープンで、匿名化すべき部分が見当たらないのだけど。
それとも匿名化対象が、投稿者→匿名、配信者→公開、閲覧者→匿名、であり、
複製先サーバがオープンな配信者として動作しない、読み専の閲覧者である場合も含むってこと?
>>182
閲覧に関して普通の専ブラと同じ方式をとった場合は、
投稿者は書き込み直後にそのスレの更新動作をする。
この動作は他の閲覧者の自動更新や手動更新よりも先行する可能性が非常に高い。
プッシュ配信でもしてしまって投稿者閲覧者問わずに更新させるか、
閲覧に関してもオニオンルーティングするかしないと隠蔽できない。
プッシュ配信だと閲覧者数が少ない場合に投稿者がバレてしまうので、
閲覧者数が少ないスレッドでは匿名読み込みに切り替えないと不味い、かな。
184デフォルトの名無しさん
2014/05/25(日) 05:24:34.63ID:NeNyrW9A185デフォルトの名無しさん
2014/05/30(金) 00:54:12.35ID:wHSl8lb9 そもそも匿名が何故必要かってところを勘違いしてないか?
186デフォルトの名無しさん
2014/05/30(金) 01:26:19.48ID:SDqP+4IS 冤罪逮捕を防止するためだよ
187デフォルトの名無しさん
2014/05/31(土) 15:35:19.94ID:QHlXh24u そもそも逮捕されるような事が出来るツールという時点であまり説得力がないんだよな
普通に健全な内容であれば特別匿名性が高い必要もない
普通に健全な内容であれば特別匿名性が高い必要もない
188デフォルトの名無しさん
2014/05/31(土) 16:13:40.81ID:sWppcuRc インターネット自由宣言に則ったネットワークを構築するため
189デフォルトの名無しさん
2014/05/31(土) 16:39:38.30ID:eTy5fHBW つ外患罪・内乱罪
そういうものに対応できるシステムがあってもいいという立場もないわけではない,ああこれって予備・陰謀になりうるのか?
日本は主に島原の乱以来の営々たる血と汗の努力により現在は稀にみる平穏な土壌が育っているので必要性は感じられないのかもしれない
そういえば何かのアニメに自主すれば無罪とかいっていたが‥@アニメーションはなんだったか?A本当か?
そういうものに対応できるシステムがあってもいいという立場もないわけではない,ああこれって予備・陰謀になりうるのか?
日本は主に島原の乱以来の営々たる血と汗の努力により現在は稀にみる平穏な土壌が育っているので必要性は感じられないのかもしれない
そういえば何かのアニメに自主すれば無罪とかいっていたが‥@アニメーションはなんだったか?A本当か?
190デフォルトの名無しさん
2014/05/31(土) 17:06:46.63ID:VTj4ztuh こっちはもう匿名性は放棄したんじゃないの?それともP2Pにすれば自動的に匿名になるとでも思ってる?
191デフォルトの名無しさん
2014/05/31(土) 17:17:05.44ID:QdYI2yy/ どこかにこのスレの公式仕様みたいのでもあるのかね。
192デフォルトの名無しさん
2014/05/31(土) 17:30:37.03ID:QKYyOmO8 >>1に「2ちゃんの代替となる」とあるだろう。
一般の2ちゃんユーザーが納得する程度の匿名性があれば十分だということなんだよ。
匿名性の技術的保証の辺りをグダグダ言う奴用には、もう一つのフォーク元のスレが用意してある。
一般の2ちゃんユーザーが納得する程度の匿名性があれば十分だということなんだよ。
匿名性の技術的保証の辺りをグダグダ言う奴用には、もう一つのフォーク元のスレが用意してある。
193デフォルトの名無しさん
2014/05/31(土) 18:45:31.68ID:PqKUKu7D >>189
多分アニメは「攻殻機動隊 Stand Alone Complex 2nd GIG」
罪状は「内乱の予備・陰謀、外国に対し私的に戦争をする目的の予備・陰謀」
でもこれ架空の近未来日本を舞台にした作品だからこれを参考にするのは間違ってる。
第三次非核大戦後だの自衛軍だの電脳化率9割超だの難民わらわらだのだし…
プログラマを武器と見做して武器禁輸措置を適用しちゃうような世界。
まぁこういう言うのはアレだ、誤用じゃない方の確信犯として突き進む類の話じゃね?
言論の自由とか人権レベルで正しい行為だと確信しての行いが犯罪になるケース。
だけど真面目な話、憲法で保証されてる権利の行使だと、刑法はひっくり返る場合がありうる。
明確な外患誘致や内乱の意図がなければ最高裁まで引っ張って勝てる可能性がある話かと。
多分アニメは「攻殻機動隊 Stand Alone Complex 2nd GIG」
罪状は「内乱の予備・陰謀、外国に対し私的に戦争をする目的の予備・陰謀」
でもこれ架空の近未来日本を舞台にした作品だからこれを参考にするのは間違ってる。
第三次非核大戦後だの自衛軍だの電脳化率9割超だの難民わらわらだのだし…
プログラマを武器と見做して武器禁輸措置を適用しちゃうような世界。
まぁこういう言うのはアレだ、誤用じゃない方の確信犯として突き進む類の話じゃね?
言論の自由とか人権レベルで正しい行為だと確信しての行いが犯罪になるケース。
だけど真面目な話、憲法で保証されてる権利の行使だと、刑法はひっくり返る場合がありうる。
明確な外患誘致や内乱の意図がなければ最高裁まで引っ張って勝てる可能性がある話かと。
194デフォルトの名無しさん
2014/05/31(土) 20:22:55.65ID:LCfd5xM6 ぼくのかんがえたさいきょうの掲示板(笑)
195デフォルトの名無しさん
2014/05/31(土) 21:29:14.84ID:F4zWTlG/ >>194
それを大真面目に考えるのがこのスレなわけだがw
それを大真面目に考えるのがこのスレなわけだがw
196デフォルトの名無しさん
2014/05/31(土) 21:37:02.40ID:Q4fGK0zf このスレだと茶化しで済むが、向うのスレだとマジで噛み付いてくる奴がいるぞ。
>>193
おお,thx なんのアニメだったか思い出せなかったんだ,神山氏は神だね‥‥
おお,thx なんのアニメだったか思い出せなかったんだ,神山氏は神だね‥‥
198デフォルトの名無しさん
2014/06/01(日) 13:14:29.54ID:ahYmPm0r ネットワーク上の第三者から、書き込み主を物理的に(ここではIPアドレスが)特定できてはいけない
同一人物からの複数書き込みの、書き込み主が同定できなければならない
これの両立が必要?
同一人物からの複数書き込みの、書き込み主が同定できなければならない
これの両立が必要?
199デフォルトの名無しさん
2014/06/01(日) 13:42:27.05ID:nKywzM47 2つ目は1つ目を守りながら実現するのが難しいし、
自主的にID振って他人のID詐称できない程度
(一人で複数IDを使用を阻止できなくても良い)
にしておいたほうが実現しやすいと思うけど。
どうせ2chだってID変えれる環境の奴は変えれる程度のものだし、
完全に阻止するためにはIPアドレス以上の同定能力が必要になる。
そこまでの同定能力は現実的じゃない、と思うんだが。
自主的にID振って他人のID詐称できない程度
(一人で複数IDを使用を阻止できなくても良い)
にしておいたほうが実現しやすいと思うけど。
どうせ2chだってID変えれる環境の奴は変えれる程度のものだし、
完全に阻止するためにはIPアドレス以上の同定能力が必要になる。
そこまでの同定能力は現実的じゃない、と思うんだが。
200デフォルトの名無しさん
2014/06/01(日) 14:17:33.73ID:OFREtEr0 童貞能力なら…
201デフォルトの名無しさん
2014/06/01(日) 15:13:18.34ID:ahYmPm0r 変えれるけど、それなりに面倒なものをキーとして不可逆変換でIDを生成し
書き込み時の通信経路を不定にする
たとえばキー候補
・グローバルIPアドレス
・MACアドレス
・OSのプロダクトID(Windowsなら)
・OSのユーザーID
・システムドライブのハードID
キーから生成したユーザID、書き込み時刻、スレIDをネットワークに放流。
受信したノードは、自身がスレを保持しかつ未書き込みなら、確率でスレを更新する。
更新確率は放流寿命(TTLみたいなもの、加えて時間的な寿命も含む)が長いほど低く、短いほど高い。
そしてTTLを(確率で)デクリメントして、さらに放流。寿命が尽きたら再放流しない。
書き込みデータは、時間的寿命が尽きるまではキャッシュに保管。キャッシュデータのTTLは0にする。
書き込み以外にも、自ノード他ノード関わりなく最近更新されたスレデータもポツポツと放流する。
他ノードから流れてきたスレデータと自身が保持するスレデータ・キャッシュ上の書き込みデータを比較し差分がある場合は
マージしてから、そのスレを過去に送った先に送信、今回の送信元に返信する。
その際のタイムスタンプは、最後の書き込み時刻。
書き込みの時系列とレス順が一致しないので、レス番に変わるレスIDの仕様を盛り込む。
リーダーがレスIDをレス番に変換しても良いが、明示的に「>」をつけない書き込みがあり得るので
レス番は廃止したいとこだな。
うーん、スレデータが爆発するのと、改ざんをどうやって防ぐかが問題だな。
あとレス削除の仕様も必要。
ユーザIDに対して第三者が信用ポイントを加算していく、ってアイディアをベースにすると
なにか出来そうなんだけどな。
書き込み時の通信経路を不定にする
たとえばキー候補
・グローバルIPアドレス
・MACアドレス
・OSのプロダクトID(Windowsなら)
・OSのユーザーID
・システムドライブのハードID
キーから生成したユーザID、書き込み時刻、スレIDをネットワークに放流。
受信したノードは、自身がスレを保持しかつ未書き込みなら、確率でスレを更新する。
更新確率は放流寿命(TTLみたいなもの、加えて時間的な寿命も含む)が長いほど低く、短いほど高い。
そしてTTLを(確率で)デクリメントして、さらに放流。寿命が尽きたら再放流しない。
書き込みデータは、時間的寿命が尽きるまではキャッシュに保管。キャッシュデータのTTLは0にする。
書き込み以外にも、自ノード他ノード関わりなく最近更新されたスレデータもポツポツと放流する。
他ノードから流れてきたスレデータと自身が保持するスレデータ・キャッシュ上の書き込みデータを比較し差分がある場合は
マージしてから、そのスレを過去に送った先に送信、今回の送信元に返信する。
その際のタイムスタンプは、最後の書き込み時刻。
書き込みの時系列とレス順が一致しないので、レス番に変わるレスIDの仕様を盛り込む。
リーダーがレスIDをレス番に変換しても良いが、明示的に「>」をつけない書き込みがあり得るので
レス番は廃止したいとこだな。
うーん、スレデータが爆発するのと、改ざんをどうやって防ぐかが問題だな。
あとレス削除の仕様も必要。
ユーザIDに対して第三者が信用ポイントを加算していく、ってアイディアをベースにすると
なにか出来そうなんだけどな。
202デフォルトの名無しさん
2014/06/01(日) 15:34:19.39ID:iF6nhgL2 >>198-199
オニオンルーティングで経路を隠しつつ,P2Pネットワークの入り口で IP アドレスを同定して ID を振ることは可能だよ.
ただ IP アドレス空間が狭すぎてレインボーテーブル手法が可能であることが問題なだけ.
ソルトを工夫すればいけるんじゃないかとおもうが,具体的手法は思いつかない
オニオンルーティングで経路を隠しつつ,P2Pネットワークの入り口で IP アドレスを同定して ID を振ることは可能だよ.
ただ IP アドレス空間が狭すぎてレインボーテーブル手法が可能であることが問題なだけ.
ソルトを工夫すればいけるんじゃないかとおもうが,具体的手法は思いつかない
203デフォルトの名無しさん
2014/06/01(日) 15:35:13.55ID:iF6nhgL2■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【速報】中国、水産物輸入停止と通達 「処理水」理由、日本政府へ ★3 [おっさん友の会★]
- 【速報】中国、水産物輸入停止と通達 日本政府に ★2 [おっさん友の会★]
- 高市首相答弁を“引き出した”立民・岡田克也氏が改めて説明「なぜ慎重な答弁をされなかったのか。非常に残念に思っている」 [ぐれ★]
- 中国側が首相答弁の撤回要求、日本側拒否★6 [夜のけいちゃん★]
- 【速報】 米大使「はっきりさせておこう、米国は尖閣諸島含め日本の防衛に全面コミット、中国がどうしようが変わらない」 [お断り★]
- 「厚かましい挑発的発言だ」中国国連大使が高市首相発言に強く反発 日本の常任理事国入りに明確に反対 [ぐれ★]
- わー国上級の子女、徴兵されない模様wwww [399259198]
- 【高市訃報】ホタテ業者、死亡😇😇😇 [573041775]
- 【速報】中国、水産物輸入停止★2 [989870298]
- 【高市悲報】マルハニチロ ニッスイ キョクヨー スシロー、急落 下落 [165981677]
- 「日本の保守層のご機嫌を取りながら、中国、ロシア、アメリカのご機嫌も取る」👈こういう総理がいれば良かったよな [762037879]
- 【悲報】高市早苗さん、たった一人で日本を崩壊へ導く [714769305]
