Mastodonには、tootctlというメンテナンスツールがあるんですけど、これに古い不要なリモート投稿を削除する機能がついてます。
どのぐらい保持しておくか、日数を設定します。
フォロー中の人や、リプライやブースト、お気に入り、ブックマーク、ピン留めされた投稿などは削除しませんが、
フォロー中の人の投稿を無条件で全部保護するとあんまり減らないので、これも削除対象とするオプションなどがあります。
これをバッチでまわしておくと、ドン・ゴロツキのような状態が維持できるわけです。
最近は本体に投稿を残す日数を指定する設定が増えましたが、こちらは日数だけで無条件で消すので、tootctl statuses removeを使った方が良いです。
えっとね、MastodonやMisskeyのサーバが抱えている投稿のうち、ローカルのものは大事な過去データだけど、リモートから来たものは、単なるキャッシュなのね。一時的なコピー。
私たちがアクセスするときに使うクライアント(Webもアプリも)は常時インターネットにつながっていないから、サーバがキャッシュしていてくれないと自分の時系列順のタイムラインがみられないので、必要なものなんだけどさ。
これ、タイムラインが時系列であることもあって、そんなに何日分も保持してなくたって大丈夫なんだ。
Mastodonの場合、2週間ログインしないとホームタイムラインをリセットする仕様なので、そのギリギリで、遡りで+2週間とすると、まあ30日分ぐらい保持していればいいかな。
古いものは、消しちゃって大丈夫。必要なときはリモートからもらえばいい。
この運用を実際に実践しているのがドン・ゴロツキというMastodonサーバで、MAUが33、まあ20人ぐらいが、日々面白おかしく過ごしてる小さなサーバなんだけど、
もう6年ちょい運用してるけど、データベースの総量は6GB、投稿データであるstatusesテーブルのサイズはたったの714MB。
ストレージ25GBのVPSだけど、これからもやっていける見通しだよ。
mstdn.jpから実質的に去ってよそのサーバーにうつった人、ならたくさんいるよ
ブリッジ方式の弱点は、橋渡しを行っているブリッジが、ひとつだけしか存在しないことです。
よしんばブリッジを複数設けるとしても、今度は同じアカウントが複数の名称を持つことになり、重複してしまいます。
(ブリッジA、ブリッジB、ブリッジCがあると、noellabo.jp@A、noellabo.jp@B、noellabo.jp@C、というまったく同じ内容のアカウントが発生してしまうということです)
そして、そのブリッジを利用するActivityPub上のサーバ、AT Protocol(Bluesky)上のサーバが、ただ一つのサービスに依存することになります。
Bridgy Fedは、Ryan Barrettさんが作って、個人で運営しているサービスです。
Ryanさんは分散SNSに対する理解・理念・非営利で持続できる運営体制など、頼りにできる信頼に足る人物であろうと思いますが、
そうであっても、ひとつのサービスで発生したトラブルが全体に影響を及ぼす構造であることは避けられません(単一障害点)。
そういった問題を構造で解決しようというのが分散SNSの目指すところで、理想から遠ざかってしまうのです。
解決策はあるかもしれませんが、原状、そういうポジションにあるということは憶えておいてください。
こちらはBridgy Fedという、ActivityPubやBluesky、IndieWebなどのブリッジサービスを利用した相互接続の様子です。
Bridgy Fed
https://fed.brid.gy/docs
Threadsが(制限がありながらも)ネイティブにActivityPubを実装しているのに対し、ブリッジは異なる実装間を代理接続する形でつなぎます。
Mastodonから見えるアカウントは、Bridgy Fedのサービス上に作られた代理のアカウントです。Bot扱いになっていますね。
フォローしておくと、接続してあるBlueskyのアカウントの新着投稿を代わりに流してくれます。お気に入りも代わりに伝えてくれます。
Blueskyから見えるアカウントも、Bridgy Fedのサービス上に作られた代理のアカウントです。
アカウントのフォローは事前に許可しておいたり、DMでリクエストを許可するようになっているそうです。
なお、X (formerly Twitter)のアカウントをActivityPubにコピーしてくるサービスもあるにはありますが、これはできるだけ使わない方が良いです。
X側が相互接続を認めていないのを無理矢理つないでいるため、ただの無許可コピーになってしまっています。
QT: https://fedibird.com/@noellabo/112374571388595625 [参照]
#fedibird #fedibird_info サーバーのブロックの決定に対する異議申し立て
https://help.instagram.com/contact/1574148669814359/
っていうフォームがあるので、問題とされていることを解決してから連絡すれば解除(再び連合)されたりするんじゃないかな。
それにしてもこのフォーム、連絡先しか聞かないっていうの凄いね。メッセージ送らせてくれ!
#fedibird #fedibird_info Threadsが連合するサーバには条件があって、
そういう情報は基本的にここから辿ればいいんだけど、
https://www.threads.net/moderated_servers
Threadsがフェディバースの他のサーバーとの通信をブロックするケースについて
https://www.instagram.com/accounts/login/?next=https://help.instagram.com/914046486923176/
理由としては以下の4つ
・Metaのコミュニティガイドライン、Instagram利用規約、またはThreads利用規約に繰り返し違反したか、それらに関して重大な違反があった(管理者またはモデレーターによるものも含む)。
・フェディバースでシェアされたThreadsの情報を削除するようThreadsが利用者に代わってリクエストしたにもかかわらず、そのリクエストを尊重しなかった。
・十分なプライバシーポリシーが定められていない。
・一般にアクセスできるフィードがない。
が条件としてあげられているのね。
で、今回fedibird.comは、
fedibird.com
公開されているフィードがありません
ということで、連合が止まってます。
たぶん、先日のダウンタイムに/publicにつながらなかったからだと思うんだけどね。
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。