のえる @noellabo@fedibird.com

カタログ売って無い（近所の祭り）

銀だこ、たこやき扱いが認められない感あったのそういうことなのか

#fedibird #fedibird_info Nightly利用者向けのお話です。

現在というかここしばらく、nightly.fedibird.comのキューが一部遅延中で、主にリモートからの投稿が遅れて届く現象が観測されていると思います。

先日の検索まわりの変更とバックグラウンドでのインデックス作成に起因するものですが、サーバのパワー不足もあるので、安定までは少々お待ちください。

ブリッジ方式の弱点は、橋渡しを行っているブリッジが、ひとつだけしか存在しないことです。

よしんばブリッジを複数設けるとしても、今度は同じアカウントが複数の名称を持つことになり、重複してしまいます。

（ブリッジ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 [参照]

これがFediverseからアクセスできる私のBlueskyアカウント（のブリッジ用Bot）
@noellabo.jp

スクリーンショットは、Blueskyの書き込みにfedibird.comから（ブリッジ経由で）返信したところ。