@hanubeki @askyq @tell_me_fedi_jp V1のフィルターは、ホームとリストと通知についてはサーバサイドで投稿データを除外しますが、ローカルや連合など全員共通のパブリックタイムラインでは除外しないので、クライアントサイドでフィルター処理を入れる必要がありました。
V2系はサーバサイドでヒントだけ付与して、どのタイムラインでもサーバサイド除外しないので、クライアント処理を行わないケースでは対応状況が悪化する現象もみられます。（tootleとか）
のえる(@noellabo@fedibird.com)の投稿 主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator（開発者の一員）です。また、独自機能を盛り込んだFedibirdを管理・開発しています！
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
@hanubeki @askyq @tell_me_fedi_jp V1のフィルターは、ホームとリストと通知についてはサーバサイドで投稿データを除外しますが、ローカルや連合など全員共通のパブリックタイムラインでは除外しないので、クライアントサイドでフィルター処理を入れる必要がありました。
V2系はサーバサイドでヒントだけ付与して、どのタイムラインでもサーバサイド除外しないので、クライアント処理を行わないケースでは対応状況が悪化する現象もみられます。（tootleとか）
@ishii00141 @playground そういう目的のグループだよー
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@tell_me_fedi_jp @ishii00141 FedibirdのWebUIで実現するのは難しくないですが、Mastodon本家にPRしても採用されるかどうかは難しいところですね……。まあやってみるか……
Fedibirdのグループ各アカウント、移行前の過去投稿を移行しました。
古い書き込みも参照できるようになったよ！
グループの紹介ひっぱってきましょう。
こちらはドール同好会の宣伝投稿です。
参加する際、投稿するアドレスが変更になっています。 @doll をフォローして、メンションしてください。
（古いアカウントを参照すると、引っ越した旨、表示がでると思います）
QT: https://fedibird.com/@7ru3___/110644297488694638 [参照]
Fedibirdのグループ機能を用いた、ポケモンのグループ、サンリオのグループです。
過去の紹介とアカウント・URLが変わっています。下記を参照ください。
@pokemon ポケモングループ
https://fedibird.com/@pokemon
@sanrio サンリオグループ
https://fedibird.com/@sanrio
過去の投稿は、URLの方から参照可能です。
QT: https://fedibird.com/@AzumaRinto/109825746352685722 [参照]
Fedibird方式のグループ紹介です。
グループ機能のテスト用のグループ実験場（playground）があります。
動作試験などを行う場ですが、住み着いている方もおられますw
@playground
https://fedibird.com/@playground
特定目的のグループに参加するのは勇気がいる、ということであれば、ここで試してみるのも良いでしょう。
昔かいた、グループについての投稿を引っ張ってきましょう。参考にはなるかと思います。
4年ちょっと前のものですが、いまも事情は基本的に変わっていません。 [参照]
グループの話(1/5)
まず、ActivityPubの概要から。
Mastodon、Pleroma、Misskeyは、それぞれまったく異なるプログラムですが、ActivityPubというプロトコルに従ってやりとりすることで、相互接続を実現しています。
ActivityPubをざっくり言うと、Actorが別のActorに対してActivityを送信し、相互作用する仕組みです。
Actorはユーザーのアカウントに相当するものです。通常のユーザーはPerson、botはServiceという種類のActorとして表現されます。
Activityは『投稿を・作った』とか『投稿を・気に入った』『Actorを・フォローする』というようなメッセージです。
Actorは、受け取ったActivity、送ったActivity、フォローしているActor、フォローされているActorなどのコレクションを保持しています。
・ActorとActorがやりとりする
・ActorにPersonやServiceなどの種類がある
・Activityを送り合う
・フォロワーなどのコレクションを保持している
グループの話(2/5)
Actor同士が直接やりとりする投稿は、当事者以外、他の人には見えません。
そこで、Activityの宛先として、Publicコレクションという特殊な宛先を指定することができるようになっており、各サーバプログラムでは、これを誰にでも見えるようにしたり、連合タイムラインやローカルタイムラインに流して表示しています。
フォロワー限定やダイレクトが基本形で、公開や未収載が特殊な公開範囲だということです。
また、連合タイムラインやローカルタイムラインはユーザーを探すための場所ですよ、と説明されるのは、こういった事情があるためです。
公開投稿をどのように扱うか（見せ方を工夫するか）は、サーバ次第です。
なお、Activityの宛先には、メールと同様にToとCcがあります。一般に、PublicをToに指定したものが公開投稿、PublicをCcに指定したものが未収載として扱われています。
ここまで、なんとなくつかめましたでしょうか？
グループの話(3/5)
グループは、ActivityPubによるユーザーの集合の表現で、コミュニティやチャンネルを実現することができる仕組みとして利用できます。
Actorの種類としてGroupが定義されているので、これを用います。
Group Actorを宛先とすることで、Groupに参加しているActorへ間接的にActivityを送ることができます。
（ただし、第三者となるActorがActivityを転送するにはJSON-LD署名が必要で、現実的には投稿と削除ぐらいしか対応していない状況です）
Groupのメンバーを表現する方法はいろいろ考えられますが、Mastodonなどの既存実装との互換性を考えると、Groupのフォロワーをメンバーと見做す実装が現実的であるため、私はそれを採用しています。
グループの話(4/5)
投稿するActorがGroupへメンションすると、Group Actorがそれを、メンバー（自身のフォロワー）へAnnouce Activityで転送します。これが基本形です。私はこれを、アクティブ方式と呼んでいます。
もう一つ、Group Actorからフォローバックして、ハッシュタグなど特定の条件が揃った場合にブーストする方式も可能で、私はこれをパッシブ方式と呼んでいます。
パッシブ方式は、無意味に多くの投稿をGroupに配送してしまう弱点がありますが、メンションせずにグループに投稿を流せるので、利便性はなかなかのものです。
これらは、既存のMastodonなどのサーバでも十分に機能しますが、サポートする機能を実装することで、より効率良く、使いやすくすることが可能です。
このあたりは、色々とアイデアがあって進めているところです。
グループの話(5/5)
グループは、連合する、サーバをまたぐコミュニティの構築に活用することができます。
ローカルタイムラインがコミュニティとして利用されてきていますが、その弱点を補うことができます。
Group Actorをホストしているサーバにメンバー管理と配送を依存していますが、投稿は参加者のサーバから発信され、参加者のサーバに配送されて保存されていくので、容易には失われません。
また、引っ越し機能でフォロワーを移し替えることで、コミュニティホストを引っ越すことすら可能です。
チャンネルに用いることもできます。これは、自身の投稿のうち、特定の内容だけをフォローしたいユーザーニーズに応え、投稿する側も配送先を使い分けることができるようになります。
複数アカウントの使い分けと比べ、リプライやお気に入り・ブーストが単一のアカウントにフィードバックされたり、メインアカウントのフォロワーに対して全てをまとめて配送できたりするメリットがあります。マルチポストが防げます。
こちらのらりおさんの記事をぜひ。これを実現可能なものです。
https://blog.cardina1.red/2018/02/25/strongest-dist-sns-i-think/
今回、gdev.fedibird.comというサーバ上に作られたグループアカウントを、fedibird.comに引っ越しさせました。
MastodonやMisskey、Pleromaには、アカウントの引っ越しをサポートする機能があり、引っ越し先の新しいアカウントに既存のフォロワーを移し替えられます。
つまり、グループのメンバーを、別のアカウントに自動移行させることができます。
だいたいうまくいきましたね！
引っ越し機能（メンバー移し替え）ができなくても、メンバーに新しいグループアカウントを再フォローしてもらえばいいのですが、連絡がつけられなかったり、方法がわからなかったり、めんどうだったりして、離脱するケースも多くなると思います。
過去投稿を移し替えることは現状サポートされていないのですが、こちらは今回は手作業でやりました。fedibird.comにキャッシュされている情報を元に、新アカウントの投稿に書き換えています。
このグループの過去投稿にあたる、グループアカウントによるブーストは、あらためてリモートサーバへ伝播させていませんので、グループの設置サーバ以外では認識されていません。アカウントページを直接見に来る必要があります。
ともあれ、すべての投稿を引っ越しさせることができました。
QT: https://fedibird.com/@noellabo/104524341770775395 [参照]
今回はgdevはデータベースの問題でロールバック（過去のデータに戻す）を行いましたが、一応動いた状態で対応ができました。
ロールバックで失われる情報も、リモートサーバから補いました。
もしグループのサーバが完全に死んでしまった（壊れたり、サービス終了した）場合でも、過去投稿はリモートの様々なサーバにキャッシュされていて参照できますし、それを元に新しいグループを別のサーバに作って、そこで新たにメンバーが再集結すれば、コミュニティは持続できます。
まあ、まだ自在に引っ越しできる、とまでは言えず、もう少しそのあたりをサポートする機能を充実させる必要がありますが、ともかく、できるということがある程度実証できたかなと思います。
#fedibird #fedibird_info グループに返信する際、グループへのメンションを先頭にするよう修正しました（WebUI）
@sublimer プライベートなタグ付けには有効なので、エラーではないんだよねー。
注目のハッシュタグ使って、控え目な自分の投稿から抽出する使い方があるよ。
このアカウントは、notestockで公開設定になっていません。
@asunoparagasu mastodon-japan.netとかfedibird.comとか。意外と大手は対応少ないのよ。
@asunoparagasu あ、mastodon.socialでもいいよ。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
#fedibird #fedibird_info いまちょっとエラー出てたと思うけど、たぶんなおったのでひっかかった人は再確認よろしく！
自分のドメインを指定してあると、本人のアカウントだということ、わかりやすいよね。全然使ってないけどさ＼(^o^)／
Misskeyのプロキシアカウントは、必要ないときにフォローする動作をやめた方がいいと思うよ。
たとえば、私のフォロワーがそのサーバに既にいて、投稿が相手のサーバに届いているときでも、そこのサーバの誰かがリストに入れただけでフォローしてくる。しなくていいよ。
数えてみたんだけど、fedibird.comは4,125のサーバからフォローされているね。
そのうち、私のアカウントをフォローしているサーバは1,261だった。
私が適当に 
って投稿すると、1,261のサーバにCreate Activityが送信される。
リモートのフォロワーは7,363いるけど、各サーバへは代表して一回だけ送れば良いので、17%ぐらいの送信量で済んでるね。
自分の投稿をブーストできないようにする設定といえば、投稿範囲をフォロワー限定に設定ですね。
ちなみにfedibird.comから誰かがフォローしているリモートのサーバの数は4,574あるよ。
単に知っているというだけのトータルサーバ数は40,036。
問い合わせて200を返してくる、NodeInfoを備えた生きてるように見えるサーバが現在19,824。
うち、半分近くの9,683がMastodon系、2,296がMisskey系、1,624がPleroma系、gotosocialは867もありますね。friendicaが305、takaheが57、microblogpubが47、mitraが30、holloが14、gnusocialが12、といった具合です。
写真系では、Pixelfedが354、
動画系では、PeerTubeが935、owncastが141、loopsが1、
ブログ系では、wordpressが2,119、writefreelyが339、plumeが39、
リンクアグリゲーター系では、lemmyが252、mbinが14、kbinが5、
ってところかな。
@tell_me_fedi_jp @dampuzakura アカウント毎に設定できるドメインブロック（ミュート）については、現状、例外を設定できるような構造にはなってないですね。
キーワード購読にのみ、この設定を無視して拾う機能があります。
Elixir由来なところもあるかもしれないけど、ActivityPubのルーズさに対して、不整な値に対するチェックが厳しいのはあるよね。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
インセンティブ設計したくないなぁ。
良くて、胃が荒れる薬を、胃薬とセットで飲ますみたいなやつになる。
現行のPleroma / Akkomaに、プロフィール補足情報（Misskeyだと追加情報）が多すぎるとアカウント情報の取得に失敗し、再取得を繰り返してしまうバグが存在します。
これにより、CPUが使い尽くされたり、データベースが肥大したり、相手サーバへ過大な負荷をかけてしまいます。
Pleroma / Akkoma全体でこれが発生するため、実質的にDDoSを仕掛けるような挙動となります。
デフォルトが20なので、これを設定（Instance の Max remote account fields）で大きく引き上げる方法でまず対応し、
指定数をオーバーしたら切り捨てて対応するパッチをあてる対応が必要です。
https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4220
Pleroma / Akkomaの新バージョンがリリースされたら速やかにアップデートしましょう。
この不具合は、プロフィール補足情報の件数が多いActivityPub実装すべてで発生します。
Mastodonの標準は4件、Misskeyは16件、Fedibirdは8件ですが、独自に数を増やしているサーバであれば該当する可能性があります。
また、Misskey.ioのバナー機能はプロフィール補足情報で連合するので、こちらでも発生します。
Akkomaについて、今回の不具合への対応を含む不定期リリースが出ています。3.13.3です。
https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/CHANGELOG.md#3-13-3
stableブランチだね。
QT: https://ihatebeinga.live/objects/7dcc6cd6-3918-435e-bc95-571f70b28345 [参照]
@Reaper メモリとかカツカツのサーバの場合、定期リセットしないとメモリ不足になることはあります。安定していれば、何週間も再起動なしでいけます。（aptのupdateとかは来ますが）
Pleromaについても修正出てますね。2.7.1。
https://git.pleroma.social/pleroma/pleroma/-/blob/mergeback/2.7.1/CHANGELOG.md
QT: https://queer.hacktivis.me/objects/0c18522d-f19a-4408-92b2-8cb4091e4cb6 [参照]
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ちなみに投稿者は、投稿の公開期限が切れたら、削除するのか、残すのか、あらかじめ設定できます。
残す設定にすると、投稿者本人と、お気に入りやリアクション、ブックマークした人は、期限が切れてからも参照できます。
イベントの告知などで、期限切れ後は削除しておきたいが、関係者はあとから参照できた方が良かったり、
期間限定でイラストを公開した場合などで、気に入ってリアクションしてくれた人には見えるようにしておく、
などの使い方ができます。
このとき、時計マークは赤になります。
リモートサーバに配送された分については、Fedibird式の投稿期限切れ対応ができないことが多いので、期限切れ後に削除されます。
@6b0a60cff3eca5a2b2505ccb3f7133d8422045cbef40f3d2c6189fb0b952e7d4 ドメイン違いの同じidが本文内に同時にある場合は、両方ともドメイン付き表記になるというルールもあります。
昨夜の地震のときほったらかしてたので、どのぐらい重くなったり遅延したのかみてないのよね。fedibird.comどうだった？ #fedibird
東京ジャーミイに行った時の写真。
モスク綺麗だよねえ……
アドベントカレンダー、そろそろですねー。
Fediverse Advent Calendar 2024は、第一会場、第二会場が埋まりましたが、余裕を持って第三会場と第四会場を用意してお待ちしております。
第三会場
https://adventar.org/calendars/10242
第四会場
https://adventar.org/calendars/10836
今のところ、第三があと3つ、第四は全部空いてます。
カレンダーの空いている場所は、期日が過ぎてから使ってもかまいませんので、何か書こうと思っている人は、いつでもエントリーしてください。
Fediverse、ほとんどのサーバが営利目的でやってるわけじゃないので、囲い込み要らないんだよね。
いろんなことから自由なのは成り立ちからくるものだから、そういうところはブレないんだ。
いろんな人に試して貰って、合う人が定住し、合わない人が別の場所に行き、それが廻り続けていればOKじゃないかな。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@adachika192 @ritzparty Mastodon公式アプリのように、フォロー承認制だとフォロワー限定を強制してくるクライアントアプリもあります。（Fedibirdはそれを回避するオプションがあります）
まぁ、のえろまも建て直そうと思ってるので大丈夫 ＼(^o^)／
（何も大丈夫ではない）
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
KAGOYAから、
「VMwareたけーよね」
「Hyper-Vのプランはじめるわ」
ってお知らせ来てたよ。
まぁ、大変だ。
（……きこえますか……フォローした人だけTLに出るというのとブロックしたらお互い離れられるSNSをお探しのみなさん……今……あなたの……心に……直接……呼びかけています……フェディバースも……試してみるのです……）
Xにアクセスしたとたんに出るアレ（Grok2の宣伝）、とりあえずアプリ終了するよね。回れ右だ、回れ右。
今年のごち鯖アドカレの開催は見送りますが、野良ごち鯖アドカレはいくらでも開催していただいて問題ございません
鯖管「あたたかい」
QT: https://fedibird.com/@noellabo/103497149564956233 [参照]
@tell_me_fedi_jp @ishii00141 まず、リモートから届いた投稿のマークアップ（HTML表現）は、リモート側が決定しています。
# が付いている文字列がリンクになっていないのは、Threads側が原因です。
もう一つ。
Threads側の投稿のActivityPub表現には、ハッシュタグの情報が含まれていません。tagというフィールドは含まれているのですが、空です。
Mastodon側は、本文中にリンクがなくても、このtagに含まれている情報で、ハッシュタグタイムラインや検索、ハッシュタグのフォローなどができるのですが、空である以上、ハッシュタグはないものと解釈します。
また、Threads側は、タグの機能や表現をMastodonやMisskeyのような仕様にするつもりはないようなので、現状の仕様のまま変わらないかもしれません。
状況としては厳しいです。どうしたものか……。
@kPherox なんか違う概念として実装してるんだよ。トピックとして、投稿に一つだけタグつけられるみたい。
https://help.instagram.com/1356090605000312
#fedibird #fedibird_info 引っ越し設定されているアカウントの投稿に対し、WebUIで返信を行った場合、引っ越し先へのメンションになるよう変更しました。
また、メンションをクリックした際に、引っ越し先のアカウントカラムを開くように変更しました。
クライアントアプリによる返信は、そのアプリの実装次第なので、同様の対応は行われません。
Fediverseでアカウントを引っ越す場合、ちゃんと引っ越し設定しといた方がいいよ、ということでもあります。
Mastodonでは、フォロワーを連れて行く引っ越しの他に、フォロワーを連れて行かない引っ越し設定もあります。
Misskey、Pleromaにも、それぞれ引っ越し機能があります。
過去のつながりを断ちたい場合はともかく、通常の移行の場合は、引っ越し機能で新アカウントを明示しておくことをお勧めします。
添付画像1は、引っ越し設定を行ったアカウントのMastodon WebUI上での表示です。
既に使えなくなったアカウントである旨、グレーアウトしている他、どのアカウントに移行したのか明示してリンクされます。
添付画像2は、引っ越し設定を行ったアカウントのMisskey WebUI上での表示です。
Mastodon同様『このユーザーは新しいアカウントに移行しました：』というメッセージとともに新アカウントへの誘導リンクが表示されています。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ThreadsとBlueskyが競争するってんなら、ThreadsはActivityPubをしっかり強化して
『明日またここに来てください。本物の分散ってヤツを見せてやりますよ』
やろうぜ
@ottoto2017 バージョンが古い場合は『管理』の中です。
その他、ロールが導入された時、Owner権限がないと表示されないので、普通のAdmin権限しか与えてないと表示されない、ということもありました。
この話してるな？（DOM）
QT: https://fedibird.com/@noellabo/113005030017962298 [参照]
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
#fedibird #fedibird_info fedibird.comのメディアを保存しているオブジェクトストレージ Wasabiで、接続数制限を受けているようで、画像のアップロードやリモート画像が保存できない症状がでているようです。
接続数を絞る対策をとりましたが、先方で状況を見極め、制限を緩めるタイミングまで回復しないかもしれません。
状況をみていきますので、ご不便をおかけしますがしばらくお待ちください。
#fedibird #fedibird_info Wasabiがいまどうなってるのかはよく分からないのですが、書き込みはできるようになっているので、順次過去の保存失敗したリモート画像を再取得しています。
リモート側で読み出しエラーになるケースについては対応できませんが、みてる感じ、だいたい復活するんじゃないかと思います。
ちなみにwasabiのステータスページはこちらで、fedibird.comのリージョンはap-northeast-1（東京）です。
https://status.wasabi.com/
何かあったと認識していること、解決に向けて取り組んでいることはわかるので、まあ参考程度に。
Mastodonの画像処理についてちょっと書いておきましょうか。
まず、Mastodonは、サーバのユーザーが投稿しようとしている画像、リモートからやってきた投稿などについてくるリモート画像を、添付ファイルの保存場所に保存します。
ファイルの取得がエラーになったり、ファイル種別と拡張子がウソだったり、サイズが大きすぎたり、未対応の形式だった場合、
投稿の場合はWebUIやクライアントにエラーを返し、
リモート画像の場合はURLだけ保存して、ファイル未取得の添付ファイルとしてデータベースに記録を保存します。
添付ファイルは通常、APIから取得した場合、様々なメタデータを取得できますが、未取得・エラーの場合はそれを提供できないので、ほとんどがデータなし、ファイル種別は不明になります。
リモートのURLだけは教えてくれるので、クライアントアプリの実装側で、これを直接参照して、うまくいけば画像表示することは可能です。
ただし、Mastodonが通常行う、不正なデータを拒否し、サイズを調整し、必要なら読める形式に画像変換するなど、安全に対する対策が効かなくなります。
そのために直接参照ではなく取得したデータを提供しているので、安直にリモートURLへフォールバックすることはお勧めしません。
WebUIでは『利用できません』という表示とともに、クリックしたときにローカルサーバのメディアプロキシのURLに飛ぶように、添付ファイルの表示を行います。
このプロキシは、クリックしてリクエストされると、そのタイミングでもう一度リモートへメディアを取得しにいき、うまく取得できたらその画像のURLにリダイレクトしてくれます。
うまく取得できたら、サーバ上のリモート画像も保存されるので、次回からは『利用できません』ではなく、ちゃんと画像が表示されるようになります。
誰かが必要としたタイミングでリトライし、復元するための機能です。よくできてますね。
また、未対応形式の場合は、サムネイルは表示できませんが、リモートのURLに直接ジャンプするリンクになります。
相手先のサーバが対応している場合、添付ファイルにはブラーハッシュ（BlurHash）という、画像を極端にぼかしたイメージを再現するためのデータがついています。
サムネイルとしてセンシティブ画像などを伏せる際に使われる他、画像取得中の一時表示、そして取得失敗したときに、画像の代わりに表示します。
ブラーハッシュの実体は短いテキストなので、保存コストがゼロに近く、画像の保存や取得と違い、受け取り失敗することがないため、非常に便利な仕組みです。
Mastodonは、サーバが利用者を守る設計になっています。
利用者の代わりに、サーバがリモートの情報にアクセスし、適切な変換をかけ、それを提供します。
サイズが大きすぎれば縮小し、一般的でない形式は扱える形式に変換し、サムネイルやブラーハッシュを生成して軽量に内容を確認できるようにします。
悪意あるメディアはブラウザをクラッシュさせるかもしれませんし、規格外のデータは、利用者の帯域（とくにモバイル）を大量消費したり、相手サーバの応答が遅ければクライアントの動作に悪影響を与えることもあります。
また、事前に代理取得しておくことで、いつアクセスしたか、誰がアクセスしたかをリモート側に悟られないよう隠蔽し、アクセスするブラウザの脆弱性などを突かれて不正なプログラムを仕込まれたり、情報が盗まれたり、騙されたりしないようにしています。
これらの処理は、サーバ側では処理や保管に相応の負担を引き受けることになりますが、
クライアントのプライバシーが守られ、安全で楽で快適になりますし、
全クライアントが直接アクセスするより、相手サーバも送信トラフィックが減ることになります。
（他方、CDNやリバースプロキシで軽減できますが、連合したサーバ数だけ同時アクセスが行われる問題はあります）
メディアの保存には、Mastodonのプログラムを置いて実行しているサーバのローカルストレージに直接保存する方法の他、オブジェクトストレージという、メディアを保存する専用の保管場所を使うこともできます。
ローカルストレージを使った方法は、別途サーバを用意する必要がないこと、仕組みが単純なことから、設置・提供が簡単というメリットもありますが、
メディアは大量に保存され、保存容量がどんどん増えていくため、
ストレージが不足してエラーになり、その際にサーバプロセスも巻き添えにして全部に影響を与えてしまう問題、
サーバの処理負担の増大とトラフィックが多くなる（転送量課金されるとサーバで特に厳しい）問題、
サーバが大きくなってきた時に、複数のサーバで構成しようと思っても、特定サーバのストレージに依存していることで台数を増やせない（スケールアップできない）問題などがあり、
大量のデータを保存しても自動拡大し（事実上、お金を払えば無限に保存できる）、サーバプロセスとは分離した保管場所として、オブジェクトストレージを利用することがあります。
AWS(S3)やAzure、GCP、Wasabi、Cloudflare R2、VPS業者提供のものなどがよく利用されています。
Misskeyなども事情は同様です。
オブジェクトストレージはすごく便利なのですが、短所もあります。
オブジェクトストレージは比較的みなで同じサービスを使っていることが多いので、今回のWasabiの障害のように、複数のサーバで同時に障害が発生する結果となることがあります。
オブジェクトストレージは通常、多重にバックアップされる運用がされており、データが失われる可能性が極めて低くなるように設計されていて、たとえ一時的な障害が発生しても永久に内容が失われる心配はあまりされていません。
どうにもならず失われた場合、あきらめるという運用が一般的で、オブジェクトストレージをバックアップする運用は少ないと思われます。
信頼性はAmazon S3が圧倒的に高いですが、落ちたことがないワケではありません。
Wasabiは、昔はよく落ちましたが、最近は安定しています。でも、忘れた頃に障害を発生させます。
オブジェクトストレージサービスを自分で設置することもできるので、そういう運用をしている人もいます。
ただ、S3より信頼性の高いサービスができるかというと、難しいです。
バックアップを万全にしようとか、スケールやパフォーマンスを確保しようとするとコストが跳ね上がるので、自前運用する場合は、どのレベルで妥協するかがポイントになってきます。
Mastodon本体とオブジェクトストレージが分離していることで、理解しにくい挙動をすることがあります。
投稿に画像を添付してアップロードできるのに、それが壊れた画像になって表示できないという現象です。
この場合、オブジェクトストレージへの保存の経路は生きていて、参照する経路が死んでいます。
投稿したサーバには、画像は正しく保存されています。
参照する経路は、Mastodon本体とは別経路のサーバを辿るので、そういう不具合の出方もあります。
参照経路が回復したら、表示されるようになります。
なお、この参照に不具合が発生しているときにリモートに投稿が配送された場合、挙動は二通りになります。
リモートサーバからは参照でき、正しく扱われ、ちゃんと表示される場合と、
リモートからも参照経路から画像を取得できず、保存も表示も失敗する場合です。
後者の場合、後日参照経路が回復してから再取得されない限り、先方では壊れたままになるので、投稿タイミングはちょっと考えどころですね。
他のサーバの状況は、いくつかのサーバにアカウントがある状態でないと検証できないので、違うサーバのアカウントを使う仲間同士で連携をとっておくか、自分で複数アカウントを運用して相互フォローしておくのが吉です。
良いハルシネーションの例だ（良くはない）
QT: https://mk.shrimpia.network/notes/a16qbh8zi4 [参照]
@a10 実は、文字数は特に制限なく見えます。
画像の枚数は4枚までで、5枚目以降は存在することに気付きません。（Fedibirdは見えるし、限界超えててもわかります）
早い人は00:00から公開かな？
毎日、カレンダーにエントリーされた記事が公開されていきますので、読んだ感想をFediverseに投稿したり、心の中で（それな）などと呟いたりしてお楽しみください！
Fediverse Advent Calendar 2024は、現在75のエントリーをいただいています。
第四会場の初日は空いてるから、いまから滑り込んでもいいんじゃないかな！
あいてるところは、あとからでも参加して埋めていいからねー。
第一会場
https://adventar.org/calendars/10051
第二会場
https://adventar.org/calendars/10064
第三会場
https://adventar.org/calendars/10242
Fediverse Advent Calendarの公開グループを作りました。
興味のある方は、こちらのアカウントをフォローしてご参加ください。
@fediverse_advent_calendar
メンバー同士が相互フォローしたように話題を共有できます。
記事をみた感想や、自分の記事の紹介や補足、関連する雑談などにお使いください。
--
■ 使い方
・フォローしている人がグループのメンバーになります。
・グループのメンバーは、グループ宛の投稿がブーストされてきます。
・グループのメンバーは、公開または控え目な公開（未収載・ホーム）投稿で、グループアカウントに対してメンションすることで、グループ向けに投稿できます。
・過去の投稿の一覧は、グループの公開ページからみられます。
https://fedibird.com/@fediverse_advent_calendar
@fediverse_advent_calendar というわけで、直前ですが、公開グループを作りました。
記事を書いた方、記事を読んだ方、ぜひご投稿ください。
私の感想なんて……と思われる奥ゆかしい方々が多いのではないかと思いますが、どのみち記事を書かれた方はエゴサしてまわりますので、みせてくださいませ！
本人にメンションするのは気が引けるとしても、ここで（エアリプ気味に）流すなら、少しは書きやすいのではないかと思います。
ADVENTARのRSSフィードから自動投稿するBotも仕掛けてみたので、うまくいけば新着記事のお知らせも流れてくる……と思います。
@fediverse_advent_calendar_rss
交流などが不要であれば、こちらのBotを直接フォローしてもかまいません。
というわけで、よろしくお願いしますー。
アドカレ、Fediverseでも習慣として根付いた感あるよね。やー、楽しみ楽しみ。
そうそう、Misskeyの最新版とFedibirdだと、フォローした時に、添付画像のような通知がくるよ。
Metatext（iOS用のMastodonアプリ）が気に入ってる人に、Feditextっていうコミュニティベースの後継アプリが開発中で、もう試せるってことを教えておくよ。
フォローするといいよ。
@Feditext
Fedibirdで使うと、絵文字リアクションがみえるよ。
Fediverseのアドベントカレンダー、2024年も実施します。
アドベントカレンダーはキリストの降誕祭・待降節に由来するもので、
12月1日（クリスマスの4つ前の日曜日）〜12月24日、毎日印をつけたり、毎週キャンドルを灯しながら数えていく習慣がありまして、
クリスマスを待つ子供達に、お菓子やおもちゃが入った扉がついているカレンダーがつくられ、毎日ひとつずつ開けていく習慣が根付いています。
最近では大人向けの、紅茶が入っていたり、化粧品が入っているカレンダーもありますよね。
で、これになぞらえて行われている、毎日記事を書いて発表する技術界隈から始まったイベントがありまして、
その流れを汲んでいるのが、今回私たちが企画しているアドベントカレンダーです。
みんなでテーマに沿った記事を持ち寄って、それを読んで一年を振り返ったり、知見を共有したり、抱負を語ったりするイベントです。
個人的な感想や振り返りなども受け付けているので、みなさん、ぜひ参加してください。エントリー受付中です。
登録・詳細はこちらからどうぞ。
https://adventar.org/calendars/10051
Mastodonのクライアントアプリを選ぶ上で重要なことの一つなんだけども。
クライアントアプリって、みんなのスマホとかで動作する部分だけじゃなくて、
通知の実現のために、サーバを運用しているのね。通知をIPhoneやAndroidに伝えるためのサーバ。
だから、（言葉にするとあまりにも当たり前なんだけど）活発に開発・メンテナンスされていて、きちんと通知サーバを維持しているアプリを使った方がいいんだ。
もう更新されてないアプリ、通知のサーバも放置されてること多いからね……。
みんなにもちゃんと通知来ないし、サーバにも失敗ジョブが溜まるだけなんだよ……。
※ 主にスマホ用のアプリ。PCは通知の実現方法が異なるため
通知Bot、ガンガンフライングかましてくるな。ADVENTARのRSSのせいだし、まあいいけど！
うーん、やはり通知Botは外しましょう @fediverse_advent_calendar
