search

misskey-dev / misskey

🌎 An interplanetary microblogging platform 🚀
https://misskey-hub.net/
GNU Affero General Public License v3.0
9.63k stars 1.28k forks source link

IPFSサポート #6862

Open SanMurakami opened 3 years ago

SanMurakami commented 3 years ago

IPFSはP2P型の分散ストレージで、ファイルのハッシュでCIDが生成されるので分散型SNSでは相性が良さそう。

あとは、IPFSのクライアントをインストールしているユーザーがピアになってくれるので、頻繁にアクセスされるデータはより早くアクセスできるメリットもある。

https://ipfs-book.decentralized-web.jp/what_is_ipfs/

syuilo commented 3 years ago

ファイルのアップロードにインスタンスサーバー介さなくなる？

rinsuki commented 3 years ago

鍵投稿とかの画像がIPFSで永久不滅っぽくされるの嬉しくなさそう

SanMurakami commented 3 years ago

ファイルのアップロードにインスタンスサーバー介さなくなる？

IPFSクライアントがインストールされていてブラウザの拡張機能が使える場合はそういうことも可能だと思う

SanMurakami commented 3 years ago

鍵投稿とかの画像がIPFSで永久不滅っぽくされるの嬉しくなさそう

一応ブロックチェーンなので消したことにすれば（ラグはあるが）消せそう

rinsuki commented 3 years ago

https://github.com/ipfs-inactive/faq/issues/9 だめそう

SanMurakami commented 3 years ago

まぁでも一回アップロードされたファイルがネット上から消えないのは普通の話だし、 現時点でファイル削除してもCloudFlareで1ヶ月キャッシュした上Googleのクローラーに吸い取られて更に3ヶ月ぐらいキャッシュされる事を考えたらその辺は諦めるべきじゃない？とは思う

rinsuki commented 3 years ago

鍵投稿ならクローラーには吸い取られなくない？

SanMurakami commented 3 years ago

もしくは鍵投稿は強制的にs3にするとか

syuilo commented 3 years ago

まあ現状でも、鍵投稿でも連合する以上それを尊重するかどうかは完全に相手サーバーに委ねられているからファイルも連合すると残り続ける可能性はある

SanMurakami commented 3 years ago

そう、そういう意味ではあまり今と変わってない感じある

SanMurakami commented 3 years ago

https://blockchainexe.com/legal_2_3/

世界中のノードから消えて初めてそのファイルがこの世から消えたという状態になります。これは正常に動いていれば削除することができます。

消してと言った後に、途中までは消していくのですが、ネットワークが繋がっていないとか、後はプログラムが壊れていて、消してくださいということに対して応答できないノードがあった場合、実はファイルとして残ってしまうことがあります。

若しくは故意にこのファイル残しておきたいから、プログラムを改造してどこかに取っておこうということが実はできてしまいます。

rinsuki commented 3 years ago

まあ一応鍵投稿ならフォロワー承認制にすれば信頼できるサーバーだけ選べる

SanMurakami commented 3 years ago

信頼できるサーバーだけ選べる

相手がいるサーバーが信頼できるかどうかは分からなくない？

rinsuki commented 3 years ago

個人鯖でかつadminが知り合いだったらまあ意地悪なことはしないだろうと仮定できそう

syuilo commented 3 years ago

あと自分で管理してるサーバーとかね

SanMurakami commented 3 years ago

でもそれって現実的にそこまで考えて投稿してる人あまりいなさそう

SanMurakami commented 3 years ago

というか、そもそも消せなくて困るようなファイルをSNSに投稿するんじゃないって話なんだけど

syuilo commented 3 years ago

一旦ファイルが削除できないのは置いといて話進めると良いかも

rinsuki commented 3 years ago

私は一個連合先を極端に絞った鍵垢運用してるわよ

というか、そもそも消せなくて困るようなファイルをSNSに投稿するんじゃないって話なんだけど

それはそうだけどうっかりアップロードしちゃった時に少しでも消えやすくあってほしくない？(DMで個人情報やりとりするならず者とかも世の中にはいるっぽいので)

あとIPFSは全く無関係の誰かがハッシュを知り得るという点でアレそう

アップロード者がoptinとかならいいのでは

rinsuki commented 3 years ago
  • IPFSはローカルの人かつオプトインした人に限る
  • それだけだとIPFSを使う人はなかなか増えないのでS3へのアップロードの方はファイルあたりサイズ制限を付ける
  • どうしてもIPFSを使いたくないけどでかいファイル上げたい人は課金させる？ (そもそも外部サービス使えよみたいな問題はあるが)

あたりが良い落とし所そう @rinsuki https://misskey.io/notes/8f3nswej3v

これで行くならmisskeyとしてはオプトインなIPFSアップロード機能を付けるとよさそう (ただし鍵/DMで投稿する画像をIPFSに上げられたら嫌という問題はまだありそう、そもそもアップロード時に公開範囲わかんないという問題があるけど)

rinsuki commented 3 years ago

あとサードパーティーアプリからのアップロードどうするの問題もあるか (アプリにIPFSのアップロード実装させるの面倒そう)

syuilo commented 3 years ago

アップロード時に公開範囲わかんない

そういやそうだった

SanMurakami commented 3 years ago

あとサードパーティーアプリからのアップロードどうするの問題もあるか (アプリにIPFSのアップロード実装させるの面倒そう)

IPFSのCIDを投げるだけでは駄目なの？

アップロード時に公開範囲わかんない問題に関してはクライアントで開いてるフォームを判定するとか？ ドライブでアップロードした時にはどちらにアップロードするか質問するダイアログを出すとか

SanMurakami commented 3 years ago

サードパーティアプリでアップロードした時は判定できないから、サードパーティアプリでアップロードした場合の動作とか設定にあると良いかも

tamaina commented 2 years ago

そもそも実装方法ってどういう感じのを考えているのだろう？

いろいろあるけど、たとえば

  1. IPFSノードのHTTPクライアントを叩いてあとは配信などをIPFSにお任せする。
    IPFSノードの設定は自分で何とかする。 HTTPからの参照はhttps://cloudflare-ipfs.com/ipfs/などのゲートウェイを用いる。
  2. MisskeyにIPFS通信機能を組み入れる。 オブジェクトストレージや/files/の内容をほかのノードに送信したり、instance.host/ipfs/***でゲートウェイ機能も提供できるようにする。

…と書いてみたけど、1のほうが圧倒的に楽そう(というか2の実装をやる意味ない気がする)

tamaina commented 2 years ago

ファイルのアップロードにインスタンスサーバー介さなくなる？

ので、あんまり考えない方がよさそう

tamaina commented 2 years ago

鍵投稿や公開範囲云々の話は、現状のMisskeyの実装でもファイルのURLがわかれば全世界に公開されてしまうので、IPFSにしたところで状況は変わらない…？
（と思ったけど、IPFSにノードのファイルのインデックスを取得する機能がある場合は駄目か(そんな機能あるの？)）

tamaina commented 2 years ago

（って今になって言い出したのは、MisskeyドライブをIPFSアップローダーとして活用できそうと考えたため）

tamaina commented 2 years ago

HTTPからの参照は...ゲートウェイを用いる

うーん、アップロードしたてのファイルだと使い物にならないくらい遅い…

PichuChen commented 2 weeks ago

Hello,

Regarding IPFS, I have some testing results to share.

  1. You must have a CID (start from Qm) to retrieve a file
  2. Even with a CID, you may not get the file immediately; the average waiting time is between 2 and 5 minutes.
  3. IPFS is very similar to BitTorrent. If you delete the file quickly enough, there will be no seed, and no one will have the chance to download the file.
  4. ActivityPub will contain the image URL, and Mastodon will save the image on their server (or just cache it).
  5. The publisher has to pin the file and keep at least one copy, as no one will back up the file for free.
  6. Setting known peers address will be very helpful for sending files; after setting peers, it takes less than 0.5 seconds to get the file.
  7. Providing the public IPFS gateway is a bad idea, as it will cause unnecessary bandwidth costs.

I think the advantages for supporting IPFS with Misskey are as follows:

  1. Other instances can download the resource from another friendly instance, reducing bandwidth pressure if users upload short videos.
  2. If some instances fail to maintain their file storage, IPFS provides a chance to recover the files from friendly instances.
  3. Newsworthiness: If it succeeds, I think it will be a successful use case for IPFS.
  4. IPFS can function as a very cheap VPN system, built in home labs by volunteers.

I haven't tested Helia (js-ipfs) on the frontend yet. If someone thinks there is value in researching this topic (Misskey supports IPFS), I can do some research on Helia. However, since some users might be using mobile data (paying by packet numbers), turning on data uploading by default is a bad idea.