IPFSサポート

[SanMurakami]

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

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

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

[syuilo]

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

[rinsuki]

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

[SanMurakami]

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

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

[SanMurakami]

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

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

[rinsuki]

ipfs-inactive/faq#9
だめそう

[SanMurakami]

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

[rinsuki]

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

[SanMurakami]

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

[syuilo]

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

[SanMurakami]

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

[SanMurakami]

https://blockchainexe.com/legal_2_3/

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

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

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

[rinsuki]

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

[SanMurakami]

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

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

[rinsuki]

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

[syuilo]

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

[SanMurakami]

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

[SanMurakami]

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

[syuilo]

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

[rinsuki]

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

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

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

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

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

[rinsuki]

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

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

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

[rinsuki]

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

[syuilo]

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

そういやそうだった

[SanMurakami]

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

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

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

[SanMurakami]

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

[tamaina]

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

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

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

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

[tamaina]

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

• 画像のthumbnail/webpublicは生成する必要がある
• ユーザーがIPFSを配信できる環境を用意するのは困難（確実なファイル配信にはIPFSノードをデーモンとして実行する必要がある）
  →インスタンスで用意したIPFSノードに誰でもアップロードできるようにする？→それはさすがに厳しいから認証情報付ける？→あまりにも面倒…

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

[tamaina]

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

[tamaina]

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

[tamaina]

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

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

[PichuChen]

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.