のえる @noellabo@fedibird.com

メディアの保存には、Mastodonのプログラムを置いて実行しているサーバのローカルストレージに直接保存する方法の他、オブジェクトストレージという、メディアを保存する専用の保管場所を使うこともできます。

ローカルストレージを使った方法は、別途サーバを用意する必要がないこと、仕組みが単純なことから、設置・提供が簡単というメリットもありますが、

メディアは大量に保存され、保存容量がどんどん増えていくため、

ストレージが不足してエラーになり、その際にサーバプロセスも巻き添えにして全部に影響を与えてしまう問題、

サーバの処理負担の増大とトラフィックが多くなる（転送量課金されるとサーバで特に厳しい）問題、

サーバが大きくなってきた時に、複数のサーバで構成しようと思っても、特定サーバのストレージに依存していることで台数を増やせない（スケールアップできない）問題などがあり、

大量のデータを保存しても自動拡大し（事実上、お金を払えば無限に保存できる）、サーバプロセスとは分離した保管場所として、オブジェクトストレージを利用することがあります。

AWS(S3)やAzure、GCP、Wasabi、Cloudflare R2、VPS業者提供のものなどがよく利用されています。

Misskeyなども事情は同様です。

Mastodonは、サーバが利用者を守る設計になっています。

利用者の代わりに、サーバがリモートの情報にアクセスし、適切な変換をかけ、それを提供します。

サイズが大きすぎれば縮小し、一般的でない形式は扱える形式に変換し、サムネイルやブラーハッシュを生成して軽量に内容を確認できるようにします。

悪意あるメディアはブラウザをクラッシュさせるかもしれませんし、規格外のデータは、利用者の帯域（とくにモバイル）を大量消費したり、相手サーバの応答が遅ければクライアントの動作に悪影響を与えることもあります。

また、事前に代理取得しておくことで、いつアクセスしたか、誰がアクセスしたかをリモート側に悟られないよう隠蔽し、アクセスするブラウザの脆弱性などを突かれて不正なプログラムを仕込まれたり、情報が盗まれたり、騙されたりしないようにしています。

これらの処理は、サーバ側では処理や保管に相応の負担を引き受けることになりますが、

クライアントのプライバシーが守られ、安全で楽で快適になりますし、

全クライアントが直接アクセスするより、相手サーバも送信トラフィックが減ることになります。

（他方、CDNやリバースプロキシで軽減できますが、連合したサーバ数だけ同時アクセスが行われる問題はあります）

WebUIでは『利用できません』という表示とともに、クリックしたときにローカルサーバのメディアプロキシのURLに飛ぶように、添付ファイルの表示を行います。

このプロキシは、クリックしてリクエストされると、そのタイミングでもう一度リモートへメディアを取得しにいき、うまく取得できたらその画像のURLにリダイレクトしてくれます。

うまく取得できたら、サーバ上のリモート画像も保存されるので、次回からは『利用できません』ではなく、ちゃんと画像が表示されるようになります。

誰かが必要としたタイミングでリトライし、復元するための機能です。よくできてますね。

また、未対応形式の場合は、サムネイルは表示できませんが、リモートのURLに直接ジャンプするリンクになります。

相手先のサーバが対応している場合、添付ファイルにはブラーハッシュ（BlurHash）という、画像を極端にぼかしたイメージを再現するためのデータがついています。

サムネイルとしてセンシティブ画像などを伏せる際に使われる他、画像取得中の一時表示、そして取得失敗したときに、画像の代わりに表示します。

ブラーハッシュの実体は短いテキストなので、保存コストがゼロに近く、画像の保存や取得と違い、受け取り失敗することがないため、非常に便利な仕組みです。

Mastodonの画像処理についてちょっと書いておきましょうか。

まず、Mastodonは、サーバのユーザーが投稿しようとしている画像、リモートからやってきた投稿などについてくるリモート画像を、添付ファイルの保存場所に保存します。

ファイルの取得がエラーになったり、ファイル種別と拡張子がウソだったり、サイズが大きすぎたり、未対応の形式だった場合、

投稿の場合はWebUIやクライアントにエラーを返し、

リモート画像の場合はURLだけ保存して、ファイル未取得の添付ファイルとしてデータベースに記録を保存します。

添付ファイルは通常、APIから取得した場合、様々なメタデータを取得できますが、未取得・エラーの場合はそれを提供できないので、ほとんどがデータなし、ファイル種別は不明になります。

リモートのURLだけは教えてくれるので、クライアントアプリの実装側で、これを直接参照して、うまくいけば画像表示することは可能です。

ただし、Mastodonが通常行う、不正なデータを拒否し、サイズを調整し、必要なら読める形式に画像変換するなど、安全に対する対策が効かなくなります。

そのために直接参照ではなく取得したデータを提供しているので、安直にリモートURLへフォールバックすることはお勧めしません。

#fedibird #fedibird_info Wasabiがいまどうなってるのかはよく分からないのですが、書き込みはできるようになっているので、順次過去の保存失敗したリモート画像を再取得しています。

リモート側で読み出しエラーになるケースについては対応できませんが、みてる感じ、だいたい復活するんじゃないかと思います。

ちなみにwasabiのステータスページはこちらで、fedibird.comのリージョンはap-northeast-1（東京）です。
https://status.wasabi.com/

何かあったと認識していること、解決に向けて取り組んでいることはわかるので、まあ参考程度に。

画像アップロードテスト #fedibird

#fedibird #fedibird_info fedibird.comのメディアを保存しているオブジェクトストレージ Wasabiで、接続数制限を受けているようで、画像のアップロードやリモート画像が保存できない症状がでているようです。

接続数を絞る対策をとりましたが、先方で状況を見極め、制限を緩めるタイミングまで回復しないかもしれません。

状況をみていきますので、ご不便をおかけしますがしばらくお待ちください。

この話してるな？（DOM）
QT: https://fedibird.com/@noellabo/113005030017962298 [参照]

壊れそうなものばかり集めてしまうよ -- ジャンク収集家

Yet A. だからしごおわが深夜だょ

ThreadsとBlueskyが競争するってんなら、ThreadsはActivityPubをしっかり強化して

『明日またここに来てください。本物の分散ってヤツを見せてやりますよ』

やろうぜ

添付画像1は、引っ越し設定を行ったアカウントのMastodon WebUI上での表示です。

既に使えなくなったアカウントである旨、グレーアウトしている他、どのアカウントに移行したのか明示してリンクされます。

添付画像2は、引っ越し設定を行ったアカウントのMisskey WebUI上での表示です。

Mastodon同様『このユーザーは新しいアカウントに移行しました：』というメッセージとともに新アカウントへの誘導リンクが表示されています。

Fediverseでアカウントを引っ越す場合、ちゃんと引っ越し設定しといた方がいいよ、ということでもあります。

Mastodonでは、フォロワーを連れて行く引っ越しの他に、フォロワーを連れて行かない引っ越し設定もあります。

Misskey、Pleromaにも、それぞれ引っ越し機能があります。

過去のつながりを断ちたい場合はともかく、通常の移行の場合は、引っ越し機能で新アカウントを明示しておくことをお勧めします。

#fedibird #fedibird_info 引っ越し設定されているアカウントの投稿に対し、WebUIで返信を行った場合、引っ越し先へのメンションになるよう変更しました。

また、メンションをクリックした際に、引っ越し先のアカウントカラムを開くように変更しました。

クライアントアプリによる返信は、そのアプリの実装次第なので、同様の対応は行われません。

カニチップっていうとどうしてもこれ [参照]