#fedibird #fedibird_info 画像まわり、さらにいろいろいじりました。

・heic, heif, avif, bmpの対応を改善。avif以外は受け取ったあとwebp変換して扱います。

・カラープロファイルが抜けることがあったので、保持されるようにしました。

・サイズの大きいGIF animationを受け取って縮小するようにしました。従来よりも大きなサイズに対応しています。

・メディアプロキシのレートリミットを緩くしました。

動画のサムネイル生成がちょっとおかしい気がしますが、他はだいたい整備できたと思いますので、このへんで一区切りです。

MisskeyやPleromaなどMastodon以外のActivityPubサーバからやってくるメディアとの互換性が向上しました。

添付画像の他、アバターやヘッダー画像が受け取れないケースをだいぶ減らせたのではないかと思います。

この画像が表示されないという実例をみつけたら可能であれば対処していきますので教えてください。

Mastodonのメディアプロキシについては、恐らくほとんど知られていないと思いますので、少し解説。

まず、Mastodonはリモートから届いた投稿やユーザー、カスタム絵文字などのメディアを、自身の管理下のストレージに保存（キャッシュ）します。

Mastodonは、ユーザーの行動を解析・トラッキングさせない工夫として、外部へのアクセスをサーバが代行し、タイミングをずらし、直接参照させないようにしています。

また、不安定なネットワークではなく、キャッシュした情報から提供することで安定したアクセスを保証し、

不正な情報の埋め込みや、位置情報などの意図しない漏洩を避けるための事前処理をしています。

軽量なサムネイルも生成します。

さて、キャッシュはずっと保持していると延々と増え続けるため、運用上、古いキャッシュを定期的に破棄することが多いです。

この時、メディアが見られなくなってしまっては不便なので、ユーザーが表示しようとしたタイミングで再取得するようになっています。

この代行をメディアプロキシが行っています。

Mastodonは、メディアのURLの代わりにメディアプロキシのURLを渡します。ブラウザやクライアントがそれを表示しようとすると、そのタイミングで再取得してから渡しています。

#fedibird #fedibird_info メディアプロキシの働き・仕組みについては別項で書きました。
https://fedibird.com/@noellabo/110365382404522467

さて、fedibird.com固有の事情ですが、

メディアサーバの引っ越しにあたって、ローカルのデータは完全移行（何か取りこぼしてる可能性はありますが）できましたが、

リモートのキャッシュは全て複製しきれず、添付画像の古いものの大部分は旧サーバに置いてきました。（そして破棄しました）

これを、まだデータを保持しているつもりになっているデータベースから、保持している記憶を忘れてもらい、必要なタイミングでメディアプロキシが働くようにしてあります。

この再取得は、ブーストで古い投稿が再びタイムラインに流れたときや、アカウントの投稿一覧・画像一覧から表示した時に働きますが、

Mastodonの標準のレートリミット（ひとりあたり一定期間のアクセス数を制限する仕組み）が10分に30回だけと、非常に厳しく設定されています。

Webプロセスに負荷がかかるので妥当な設定だと思いますが、fedibird.comはそれなりに処理能力がありますし、再取得が集中しますので、

暫定的に1分に300回まで解放しています。 [参照]