【次世代P2P】IPFS

a810318c anonymous 2015-12-05 07:38
>>6a212c6a
現状のIPFSで掲示板を作るにあたり一番のネックは名前解決が貧弱なこと。
自ノード名に割りつけることはできるが、1ノードあたり唯一名前1つで、他の名前には割りつけられない。
例えばスレを更新するとそのデータのアドレスが変わるが、IPFSだけでは、そのアドレスを共有する手段がない。
なので、このチャットでもそのアドレスを共有するための中央サーバーが存在しているものと思われる。
d663e5d9 anonymous 2015-12-05 09:07
@markdown
>>a810318c
> Now, there are a few things to note; first, right now, you can only publish a single entry per ipfs node. This will change fairly soon.

https://github.com/ipfs/examples/tree/master/examples/ipns

本当だ。IPNSの開発が進まないとちょっとIPFSだけだと掲示版は難しいみたいだね。結局サーバーが必要なところは昔のNapsterに似てるような。
f119621c anonymous 2015-12-05 16:31
匿名性は?
3418d77f anonymous 2015-12-05 16:56
いろいろ考えた。

そもそも更新通達はDHTとかストレージとか関係ない分野で、これまた難しい分野の1つ。IPNSとか以前にIPFSで解決する問題ではない気がしている。

・従来のping,join,updateは必要
・get,have,recentとか非公式removedはmerkledagのハッシュだけ返す。各ノードがIPFSネットワーク上のデータを勝手にを見れるので。

もしIPFSで掲示板を作るとすれば、
データ構造としては、recent->threads->resの1つのDAGとなり、そのmerklerootをもって掲示板全体の状態なると思う。ただし、removedや閲覧してないスレも含めて全レスを含む。そうしないと、各自が1つづつ違うmerkledagを作ることになる。removedはおそらく各自が掲示板全体の状態と同じ構造の別のデータをそれぞれ持つことになる。

レス書き込み処理
・レスをmerkledagに書き込んで、そのハッシュを/updateする
・受け取った各自が該当threadにそのmerkledagを追加する。殆どのノードで同じハッシュを得ることになるはず。

結果、死んでる他ノードの状態でも一瞬でコピーできることになる(一瞬で最新状態にできる、という意味ではない)

タグ、2chのスレ番号は考えてない。
aff411af anonymous 2015-12-05 17:01
更新通達は論文も色々でてるみたいが一長一短でどれもいまいち。
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.105.4570&rep=rep1&type=pdf
http://www.p-grid.org/publications/papers/ICDCS2003.pdf
304a93f3 anonymous 2015-12-06 03:37
>>3418d77f
IPFSに新月の一部を別レイヤーとしてかぶせる形になるのかな?
merklerootを使うとレスの取りこぼしがなくなるのは美味しいけど、確かにノード間で同期をとるのが大変そう。スパムをどうするのかという問題もある。各ノードで勝手に弾くわけにもいかないし。

タグは別レイヤーで処理すればいいし、2chのスレ番号はスレッドの最初のレスの書き込み時刻にすればいい。
305cbf5d anonymous 2015-12-06 03:49
今の新月のプロコトルをそっくり流用して、レスのデータ(本文、添付ファイル等)だけIPFSでやり取りするという方法もある。過去ログの保持はしやすくなるかも。
06ab8b11 anonymous 2015-12-06 08:28
>>f119621c
今のところ匿名性は全く保証されていないみたいだね。将来的には対応する可能性もあるってさ。

How does ipfs compare to freenet?
https://github.com/ipfs/faq/issues/18

Does IPFS provide any guarantees about anonymity?
https://github.com/ipfs/faq/issues/12
1900acd2 anonymous 2015-12-06 15:36
>>304a93f3
むしろ同期は高速化できるんじゃないかと思う。
 ・merkle DAGなので、ノードのハッシュを上から見ていけば、O(log N)で比較できる(はず)
 ・同じハッシュならばデータ保存がダブルこともなく、ダウンロード時はtorrent方式で以前ダウンロードしてキャッシュを持つ複数の  ノードからダウンロードするので効率的
ただし、/updateで単純に人が提供した掲示板全体のハッシュを信用することはできないので、追加されたレスが正しいフォーマットかを自分で確認する必要ある。
ただ、merkle dagのルートハッシュさえ渡せば、更新状態が高速にわかる(はず)なので、結局は/updateはルートハッシュのやり取りになるんだと思う。merkle DAGの比較が掲示板同期の中心動作になるんだろうと思う。

一方で「掲示板全体を保有する」という苦労は低くなる、というより、ルートハッシュの管理だけで、あとはキャッシュが一定期間ディスクに残ってtorrentのswarmの役割を果たすのみで、保有の概念自体がかなり曖昧になる。
SPAM除去はあいも変わらず大変。いいようにいえば、既読スレの選択とともに、カスタマイズ性のある部分だと思う。

ちなみに、ノード、タグの共有は、最新状態に気を使うものでないので、通信でなく、必要時とか1日毎とか、定期的に直接相手のデータを覗けばいいのだと思う。そのほうがうまくすればtorrent技術が使えて効率的。
19918ee1 anonymous 2015-12-06 15:40
1つ心配なのは、各自もつキャッシュは一定期間アクセスがなければ消えるわけで、アクセスのないレスはIPFSネットワークからそのうち消えてしまうんじゃないか、と思うんだが、どうなんだろう?
54cde7ef anonymous 2015-12-06 15:41
>>305cbf5d
それもありだが、個人的にはport0対策をすっきりさせたいので、オーバーレイネットワーク部分も使いたいと感じる
c523b88d anonymous 2015-12-06 18:03
>>305cbf5d
個人的にはport0対策をすっきりしたいので、iipfsのoverlay networkは使いたい
ただ、可能なら新月とどこかで接続できればベスト
15cbca68 anonymous 2015-12-06 19:47
>>1900acd2
ああそうか、各ノードのmerkledagは同じである必要はないのか。なるほど。
c460dc5d anonymous 2015-12-07 16:57
merkledagの追加の仕方が大体わかった。

https://gist.github.com/utamaro/412efb7780fd3ee8a139
c3d5f19c anonymous 2015-12-07 21:45
ipns,unixfsの使い方もわかったので満足した。
https://gist.github.com/utamaro/31e6eedd228f30383cc0
78715e6f anonymous 2015-12-07 21:49
ちなみにipfs上で生の通信の仕方は例がある。
https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmQwAP9vFjbCtKvD8RkJdCvPHqLQjZfW7Mqbbqx18zd8j7/api/service/readme.md
10277736 anonymous 2015-12-08 12:51
>>c460dc5d
> merkledagの追加の仕方が大体わかった。
>
> https://gist.github.com/utamaro/412efb7780fd3ee8a139

Goからは直接IPFSにアクセスできるのか! いいな〜 従来の新月の実装と並行してmerkledagをやり取りする新プロトコルを実装してもいいかもしれない。
8bd50b97 anonymous 2015-12-10 19:50
>>10277736
合をベースになにかのんびり考えてみることにする。
ただ、新月互換はややこしそうなので考えないし(新月は、これ以上いじり倒さないことにした)、
関連文章は英語ベースにしておく。

https://github.com/RaccoonDogBBS

多分使用者はいないだろうが、技術的な興味本位ということで。
059e2f4f anonymous 2015-12-11 01:04
>>8bd50b97
名前長い
225f9311 anonymous 2015-12-11 06:02
>>8bd50b97
> 新月は、これ以上いじり倒さないことにした

え~、それは残念… また気が向いたら是非宜しく。
dd662b2b anonymous 2015-12-11 07:01
>>8bd50b97
どうせならRaccoonDagにすればいいのに
e1ed70e6 anonymous 2015-12-11 07:17
>>dd662b2b
先約済み
a8cd1829 anonymous 2015-12-11 07:24
>>e1ed70e6
ああ、Dagねw
fa68aebb anonymous 2016-01-03 15:38
色々実験したが、どうも、完全にはポート0に対応してない。

port0ピア(A)が最初にIPFSに参加するとき、ポート0でないいくつかのピア(B)にコネクションを貼るが、これがAへの唯一の接続。
BからはAに接続できる(コネクションを使いまわせる)が、他のピア(C)からは接続できない。
BはAが作ったDAGにアクセスできるが、Cはできない
リレー機能はDAG取得機能等と組み合わされてるわけではなく、あくまで単体機能になっている。

今後に期待したい。
0e6399fb anonymous 2016-01-03 15:44
ポート0のPCでDAGを作ってipfs.io/ipfs/XXXXでアクセス可能だったので、ポート0対応できてる、
と勘違いしたが、
おそらくipfs.ioは初期ノードで、PCが最初にコネクションを貼ったからだったのだろう。

ポート0でないPCから、別のポート0PCで作ったDAGがどうしても見れなかったので、、、
146b2276 anonymous 2016-01-03 15:47
>>fa68aebb
ああ、これは推測です。裏はないです。

>ポート0でないPC(D)から、別のポート0PC(E)で作ったDAGがどうしても見れなかったので、、、
その後、ipfs.ioでDAGにアクセス後は、Dからも該当DAGが見えた(つまりipfs.io経由で見えてたと思われる)ことも付記しておきます。
b85a0872 anonymous 2016-01-03 16:04
ただ、通常のネットワークよりは遥かにポート0の悪影響は緩和しているようにも思える。
・同じ情報を拡散する用途では、ポート0でないピアが自身に接続しているポート0ピアにそのうちに情報を伝達するだろうから、
 問題はおこらない可能性が高い。ただし、前提としてポート0ピアが、多くのポート0でない同じサービスを使用するピアに
 既接続である必要がある。
・ポート0でないピアが、自身に接続しているポート0ピアのDAGを一旦取得すれば、キャッシュが消えない期間は、
 他のピアはそのDAGを取得できる。
690a7fcf anonymous 2016-01-10 01:49
ipfsって割りと革命的な技術な気がするけど流行らないねぇ。
なんというかP2Pってだけで毛嫌いされている気がする
0f903054 anonymous 2016-01-10 02:20
>>690a7fcf
革命的≠流行る
毛嫌いされてるというより理由する価値を伝えられてない
技術者以外が参加しないといずれ終わる
256d4714 anonymous 2016-01-10 05:33
>>b85a0872
詳細な報告乙。しかしIPFSのPort0の扱いは微妙だな~
一般人に普及させるためにはPort0を意識させないのが大事だと思うけど、
これじゃあ無理だよね。やっぱりスーパーノードは必要なのかしらん。
e4943a15 anonymous 2016-01-10 05:36
>>0f903054
Skypeみたいに普通に便利に使ってたら実はP2Pでしたっていうのが理想的だと思う。
5394833f anonymous 2016-01-10 07:51
>>e4943a15
ゲイツが覗き見しているけどね
89027748 anonymous 2016-01-11 21:00
流行るって開発者とユーザーでごっちゃになってないか?
末端ユーザーからすればプロトコルが何かなんて関係ない。
開発者は増えてる。
16d84afb anonymous 2016-01-11 21:04
IPFSのCLIが末端ユーザーの間で流行らないという趣旨なら、本気で言っているのかという話。
68620e26 anonymous 2016-01-11 23:58
IPFS上の更新通知については議論が行われてるっぽいね
https://github.com/ipfs/notes/issues/64
11dce6ee anonymous 2016-01-18 22:43
IPFS上で
https://en.wikipedia.org/wiki/Cooperative_storage_cloud
を構築することを考えてみる、気が向いてる限りは。

https://github.com/goayame/spec
fac50974 anonymous 2016-02-19 11:36
IPNSのキーってまだノードのキー1つで固定なのか
複数作って管理したり出来るようになれば色々と使い道が思いつくんだが
31cab48a anonymous 2016-02-26 21:15
wordnet
https://ipfs.io/ipfs/QmRspYdRNpSJtZaXZDgMMqW5SH4SyDPmGzvmkWeN1zJRkh
25f6ded8 anonymous 2016-03-05 20:38
https://ipfs.pics
意外と使われてるみたい
a5feaad0 anonymous 2016-03-09 23:15
IPFS上に匿名の掲示板って作れる?
Zeronetでは匿名掲示板は果てしなく面倒らしい・・・
2ddd61c9 anonymous 2016-03-10 16:23
>>a5feaad0
>>06ab8b11 
619166e0 anonymous 2016-03-11 11:32
そもそも現状のIPFSは単なる分散ファイルシステムなので、掲示板とかそういったのは別のレイヤー
書き込み内容はIPFSで共有できても更新通知や各掲示板の書き込みのリストとかは別のネットワークで共有する必要がある
8ab152c5 anonymous 2016-03-15 20:12
IPFSにあげてハッシュとファイル名の紐付けをメモり忘れたらもう取り出せない?
>>25f6ded8 なんか見てるとアカの他人が上げたファイルとリンクの紐付けができてるみたいだけどどういう方法?
b004ba16 anonymous 2016-03-15 21:23
ipfs.picsはipfs.picsを通してアップロードされた画像だけ紐付けしてる
d77a0f03 anonymous 2016-03-15 21:34
なるほど。
てことはやはりハッシュ値を忘れるともう拾ってくることはできないわけか…
自鯖内にも紐付けたリストみたいなのは残らないよね?
44b02d57 anonymous 2016-03-16 00:15
普通にipfs addすると自動的にピンされる(キャッシュから自動削除されなくなる)ので
ハッシュ値だけならは残ってるよ
ipfs pin lsで見られる

紐付けたリストが欲しいならディレクトリをIPFSに追加すればいいような
ディレクトリのハッシュさえ知っていればファイル名からファイルの内容にアクセスできる
121c3bd5 anonymous 2016-04-09 11:57
go-ipfs 0.4.0
https://ipfs.io/blog/14-ipfs-0-4-0-released/
900f0c69 anonymous 2016-10-03 18:58
巨大なファイルのダウンロード効率ってどんな感じ?
256KBに分割されて、ピース毎に検索されるのなら凄く遅くなると思うのだけれど
d5bea92a anonymous 2016-10-03 21:19
>>900f0c69
IP/イーサネットでもっと小さく分解されるから大丈夫
検索もある程度まとめて行われる筈だし
26ef8edd anonymous 2016-10-29 16:00
ファイルの大きさよりは、目的のファイルがどの程度の人数に保持されてるかの方が速度に影響があるっぽい感じだし
それほどオーバーヘッドはなさそう
もちろん>>d5bea92aの言うとおり並列リクエストもされるだろうし

Top of this page. | 0 1 old>> | Archive | Mobile

limit: 1536KB

(【次世代P2P】IPFS/57/0.0MB)

Powered by shinGETsu.