新しいものを表示

Blueskyについては、私のやりたいことがない、ということにつきます。

じゃあ、私はカキフライね!

サクサクでジューシーでおいしかったよ!!

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
fed.brid.gy/docs

Threadsが(制限がありながらも)ネイティブにActivityPubを実装しているのに対し、ブリッジは異なる実装間を代理接続する形でつなぎます。

Mastodonから見えるアカウントは、Bridgy Fedのサービス上に作られた代理のアカウントです。Bot扱いになっていますね。

フォローしておくと、接続してあるBlueskyのアカウントの新着投稿を代わりに流してくれます。お気に入りも代わりに伝えてくれます。

Blueskyから見えるアカウントも、Bridgy Fedのサービス上に作られた代理のアカウントです。

アカウントのフォローは事前に許可しておいたり、DMでリクエストを許可するようになっているそうです。

なお、X (formerly Twitter)のアカウントをActivityPubにコピーしてくるサービスもあるにはありますが、これはできるだけ使わない方が良いです。

X側が相互接続を認めていないのを無理矢理つないでいるため、ただの無許可コピーになってしまっています。
QT: fedibird.com/@noellabo/1123745
[参照]

のえる  
これがFediverseからアクセスできる私のBlueskyアカウント(のブリッジ用Bot) @noellabo.jp スクリーンショットは、Blueskyの書き込みにfedibird.comから(ブリッジ経由で)返信したところ。

サーバーのブロックの決定に対する異議申し立て
help.instagram.com/contact/157

っていうフォームがあるので、問題とされていることを解決してから連絡すれば解除(再び連合)されたりするんじゃないかな。

それにしてもこのフォーム、連絡先しか聞かないっていうの凄いね。メッセージ送らせてくれ!

スレッドを表示

Threadsが連合するサーバには条件があって、

そういう情報は基本的にここから辿ればいいんだけど、
threads.net/moderated_servers

Threadsがフェディバースの他のサーバーとの通信をブロックするケースについて
instagram.com/accounts/login/?

理由としては以下の4つ

・Metaのコミュニティガイドライン、Instagram利用規約、またはThreads利用規約に繰り返し違反したか、それらに関して重大な違反があった(管理者またはモデレーターによるものも含む)。

・フェディバースでシェアされたThreadsの情報を削除するようThreadsが利用者に代わってリクエストしたにもかかわらず、そのリクエストを尊重しなかった。

・十分なプライバシーポリシーが定められていない。

・一般にアクセスできるフィードがない。

が条件としてあげられているのね。

で、今回fedibird.comは、

fedibird.com
公開されているフィードがありません

ということで、連合が止まってます。

たぶん、先日のダウンタイムに/publicにつながらなかったからだと思うんだけどね。

「カンタンですヨ」

「全部つぎ込んでるからですヨ」

のえる さんがブースト
のえる さんがブースト
のえる さんがブースト
古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。