マストドン関連アプリを作る上で今までと勝手が違う部分と分散型クラウドストレージへの期待
こんにちは、マストドン廃人も4週目に突入しました。投稿する方の廃人から、アプリ開発の廃人にステータスが変更されています。
さて、マストドンのAPIを使ってアプリを作る場合、すでに各言語のライブラリが揃ってきているのでAPIを叩いてかぶってじゃんけんぽんまでは簡単にできそうです。
ただ、分散型であるがゆえの問題もありました。
投稿の特定、です。
マストドンでは投稿の管理がインスタンスごとに独立しています。
そうすると、複数のインスタンスの投稿をまとめようとするとIDが競合するという事が起こります。
TwitterやFacebookであれば、すべての投稿は一括管理されているので、こうしたことは考えなくても良かったのですが、マストドンでは他のサービスと同じ要領ではだめなんです。
マストドンで、インスタンスをまたいで投稿を特定するにはURLを使うことになります。
ということは、自作アプリのデータベースに保管する場合、キーをURLという文字列にしなければ行けません。
これって、データベース的にどうなんでしょう。教えて偉い人。
これを解決しようとしてアプリ側で独自のIDを使うというのも処理が複雑になりそうです。。。
インスタンスごとにテーブルをわけるとかしたらとんでもない数のテーブルができあがるし。
どうしたものか。まだ答えは出ていなかったりします。
分散型クラウドストレージへの期待
ここ数年、注目されているストレージ技術があります。
それが、分散型クラウドストレージです。
分散型クラウドストレージには Storj や IPFS といったものがあります。
厳密にいえば IPFS はストレージというよりもウェブなのですが、コンテンツを分散管理するという点では近いものがあります。
これらについては下記のページを読むとどのようなものかがわかるかと思います。
分散型のクラウドストレージでは、様々なデータが一つのネットワーク上で管理され、ユニークなIDで管理されます。
マストドンでこれを導入すると、各投稿やユーザーアカウントがインスタンスにかかわらず統合され、単一性を保証されるということです。
流石にいまからマストドンに導入するのは無理があるかもしれませんが。。。
ただ、今後もマストドンのような分散型のプラットフォームはでてくるでしょうから、そうしたものを作ろうという場合には分散型のクラウドストレージを検討するべきなのかもしれません。
今までのデータベースとだいぶ勝手が違うのと、まだ出てきたばかりのサービスばかりなので先行きは不透明ではありますが。
かつて日本にはWinnyというものがあったのですが、あれが順調に発展していたら日本が分散型クラウドストレージで世界をリードするなんてあったかもしれないななんてことを思います。
ちょっと大雑把な内容になりましたが、だいたいこんな感じです。
引き続き開発を続けていくので、また何かわかったことがあったらブログで報告するかもしれません。気が向けば。