@noppe 10bitのHEICで問題を起こしてる可能性あるんですが、8bitのHEICで送信するようにできますか？
のえる(@noellabo@fedibird.com)の投稿
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator（開発者の一員）です。また、独自機能を盛り込んだFedibirdを管理・開発しています！
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
@noppe 10bitのHEICで問題を起こしてる可能性あるんですが、8bitのHEICで送信するようにできますか？
@noppe 外からはわからないです。本来対応しているべきかと……。
（ちなみにPhotoshopは8bitは読めるけど10bitは読めない挙動でした。頑張れ）
本件はサーバ側の不具合回避ということで、ワークアラウンド扱いでお願いします。そのうちなおす！
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@natumi_kaoru Mastodonはそういう状況を考慮した上で、あえて許可してるよね。DMだけ拒否できない（ブロック貫通する）ように特別処理されてるよ。
@yamako ていうかMastodonの仕様とダイソーのサイトの仕様だねえ。ダイソーはとりあえず悪くない。
#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につながらなかったからだと思うんだけどね。
#fedibird #fedibird_info サーバーのブロックの決定に対する異議申し立て
https://help.instagram.com/contact/1574148669814359/
っていうフォームがあるので、問題とされていることを解決してから連絡すれば解除（再び連合）されたりするんじゃないかな。
それにしてもこのフォーム、連絡先しか聞かないっていうの凄いね。メッセージ送らせてくれ！
こちらは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 [参照]
ブリッジは、相互接続されている状態を模倣してくれるし、一定の利便性を提供してくれますが、双方のサービスが本当につながっているのとは異なります。
必要最小限、恩恵が受けられて依存しない範囲で利用し、その欠点・問題点を十分に踏まえて利用すべきものです。
つながるのは面白いので試せる人は試してみると良いと思いますが、使わない方が良い場合も多いので、事前によく調べてみてください。
ブリッジ方式の弱点は、橋渡しを行っているブリッジが、ひとつだけしか存在しないことです。
よしんばブリッジを複数設けるとしても、今度は同じアカウントが複数の名称を持つことになり、重複してしまいます。
（ブリッジA、ブリッジB、ブリッジCがあると、noellabo.jp@A、noellabo.jp@B、noellabo.jp@C、というまったく同じ内容のアカウントが発生してしまうということです）
そして、そのブリッジを利用するActivityPub上のサーバ、AT Protocol（Bluesky）上のサーバが、ただ一つのサービスに依存することになります。
Bridgy Fedは、Ryan Barrettさんが作って、個人で運営しているサービスです。
Ryanさんは分散SNSに対する理解・理念・非営利で持続できる運営体制など、頼りにできる信頼に足る人物であろうと思いますが、
そうであっても、ひとつのサービスで発生したトラブルが全体に影響を及ぼす構造であることは避けられません（単一障害点）。
そういった問題を構造で解決しようというのが分散SNSの目指すところで、理想から遠ざかってしまうのです。
解決策はあるかもしれませんが、原状、そういうポジションにあるということは憶えておいてください。
@yamatsumi_s Bridgy Fedも危うくbird.makeupになりかけたけど、了解を得る方式にあらためて理解を得た、という経緯がありますね。ブリッジは難しい。
Xがつながることを拒否している以上、なんとも……
えっとね、MastodonやMisskeyのサーバが抱えている投稿のうち、ローカルのものは大事な過去データだけど、リモートから来たものは、単なるキャッシュなのね。一時的なコピー。
私たちがアクセスするときに使うクライアント（Webもアプリも）は常時インターネットにつながっていないから、サーバがキャッシュしていてくれないと自分の時系列順のタイムラインがみられないので、必要なものなんだけどさ。
これ、タイムラインが時系列であることもあって、そんなに何日分も保持してなくたって大丈夫なんだ。
Mastodonの場合、2週間ログインしないとホームタイムラインをリセットする仕様なので、そのギリギリで、遡りで＋2週間とすると、まあ30日分ぐらい保持していればいいかな。
古いものは、消しちゃって大丈夫。必要なときはリモートからもらえばいい。
この運用を実際に実践しているのがドン・ゴロツキというMastodonサーバで、MAUが33、まあ20人ぐらいが、日々面白おかしく過ごしてる小さなサーバなんだけど、
もう6年ちょい運用してるけど、データベースの総量は6GB、投稿データであるstatusesテーブルのサイズはたったの714MB。
ストレージ25GBのVPSだけど、これからもやっていける見通しだよ。
@koimoa mstdn.jpは、日本で爆発的にMastodonが流行った時に中心になったサーバで、日本の利用者登録がここに集中しました。
当初から利用者がもっと分散するべきだという意見は強かったのですが、一人一人は自分が気に入ったサーバを使っているだけですし、なにより流速の速いローカルタイムラインで盛り上がっていましたから、なかなかその状況は変わりませんでした。
ですが、サーバの不調が度々発生し、少しずつユーザー離れが進みました。
現在でもユーザー数は多いですが、たくさんあるサーバの一つという位置付けになっています。
この話は、misskey.ioに一極集中している状況に対し、misskey.ioを去ってよそのサーバにうつった人がどのくらいいるだろうか？ という話題があったため、Mastodonでは移行が進んだよ、と答えたものです。
Mastodonには、tootctlというメンテナンスツールがあるんですけど、これに古い不要なリモート投稿を削除する機能がついてます。
どのぐらい保持しておくか、日数を設定します。
フォロー中の人や、リプライやブースト、お気に入り、ブックマーク、ピン留めされた投稿などは削除しませんが、
フォロー中の人の投稿を無条件で全部保護するとあんまり減らないので、これも削除対象とするオプションなどがあります。
これをバッチでまわしておくと、ドン・ゴロツキのような状態が維持できるわけです。
最近は本体に投稿を残す日数を指定する設定が増えましたが、こちらは日数だけで無条件で消すので、tootctl statuses removeを使った方が良いです。
