投稿者: mfuku

NUXT/contentで試しの変換ブログはそのまま作り込み続けているのだが、ipfs対応について作ってみて、わかってきた。

最初ブログを一括変換して一つのcidを作って、残りはそこからの相対コンテンツという形にしてみたが、ipfsはコンテンツがわずかでも変わると別のcidに変わってしまう。

つまりボタンのgifを少しいじるだけでも別のコンテンツという扱いになってしまう。

例えば「ある1つの記事の内容を少しでも書き換えたら別のコンテンツとして新しいcidを発行します」という話であれば、記事の永続性の保証という意味で分かるのだが、「ある1つの記事の内容を少しでも書き換えたら、そのブログに含まれている他の記事も含めてすべて別のコンテンツとして新しいcidを発行します」では記事の永続性としてはちょっと使いにくい。ブログ全体としては確かに以前とは異なりますという意味では正しいが、そこを保証されても何が変わったのかが訳分からなくなってしまう。たとえばマニュアルのサイトとしてVer.1.0のサイトのcidを起こして、これがVer.1.1になったら次のcidを起こすという使い方は有用なのだが、個人サイトでデイリーな記事を追加したら毎日cidが変わりますという使い方は面倒なだけだし保存容量の無駄遣いにしかならないし。。。

つまり個人ブログみたいなものでやるなら「ブログ全体」→「1cid」ではなく、「1つの記事」→「1つのcid」にしてブログシステムがその記事のcid群を管理するという形にするのがよさそう。そうすればブログシステムそのものは書き換えてもcidが更新されない(ボタン画像を貼り替えてもcidは変わらない)という形にできる。1日のログを後で書き換えることはめったにないから発行したcidを永続しても問題ないし、技術記事などで内容を追記したときに新cidが発行されるという話なら、それは更新履歴として管理できると便利な話になる。

そうなってくると

一番単純には「保存した各単一記事cidのhttpゲートウェイurlをブログシステム側でiframeで埋め込む」とか「記事そのものはmdのままホストしてcidを発行して、jsとかで取得してレンダリングする」(corsをどうするのがよいかな?)とかいう形になるんじゃないかな。

iframeが復権するのかな?

ちょっと工夫しないとおいしくなさそうなので、少し再検討中。

ipfsのピン止め=webでいうファイルをホスト

サブドメインゲートウェイ版(cidv1b32)

https://bafybeidecboxdn52mlchzgzhahezrsrztbg3sfkuq3isbpfflousf44xw4.ipfs.dweb.link/

パスゲートウェイ版

https://ipfs.io/ipfs/QmV5FxCrkA9fAFVd1Ckn2wtKQWi66Hp4CUKcSGRSQYqc4E

パスゲートウェイだとガチの相対パスになるので、結構むずいな。。。SPAにでもしないといけないのか。

こういうコンテンツは変動していくものなので、コンテンツ指向だけでなくロケーション指向と織り交ぜないといかんねぇ。

(1バイトでも変わるとパスが変わるので、上記リンクは予告なく消えてますのでご了承を)

2021/04/29追記
ipfsのピン止め=webでいうファイルをホスト とは言えなかった。
そういうケースが現実的には多いものの、ピン止めは論理的な話なのでcidが発行済み(つまりどこかでipfsに保存済み)のファイルを別のipfsクライアントからピン止めすることも操作としてはできる。ただピン止めが保証されるためには実体ファイルが必要なので結局はピン止めしたクライアントにコピーされてくることになる(コピー完了後にピン止め成功)。○×というより△くらい?