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

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

(ブリッジA、ブリッジB、ブリッジCがあると、noellabo.jp@A、noellabo.jp@B、noellabo.jp@C、というまったく同じ内容のアカウントが発生してしまうということです)

そして、そのブリッジを利用するActivityPub上のサーバ、AT Protocol(Bluesky)上のサーバが、ただ一つのサービスに依存することになります。

Bridgy Fedは、Ryan Barrettさんが作って、個人で運営しているサービスです。

Ryanさんは分散SNSに対する理解・理念・非営利で持続できる運営体制など、頼りにできる信頼に足る人物であろうと思いますが、

そうであっても、ひとつのサービスで発生したトラブルが全体に影響を及ぼす構造であることは避けられません(単一障害点)。

そういった問題を構造で解決しようというのが分散SNSの目指すところで、理想から遠ざかってしまうのです。

解決策はあるかもしれませんが、原状、そういうポジションにあるということは憶えておいてください。

フォロー

こりゃブルースカイのブリッジ大変だ、リレーを増やそう……というわけにはいかないよ、という事情を説明したのがこれ。
QT: fedibird.com/@noellabo/1123784
[参照]

のえる  
ブリッジ方式の弱点は、橋渡しを行っているブリッジが、ひとつだけしか存在しないことです。 よしんばブリッジを複数設けるとしても、今度は同じアカウントが複数の名称を持つことになり、重複してしまいます。 (ブリッジA、ブリッジB、ブリッジCがあると、noellabo.jp@A、noellabo.j...

こん!のえるさん🍎🍎
素敵な金曜日を✨️✨️
🍎

@risahana こん! 🍎 🍎
金曜日はいいねえ。仕事しあげなくちゃねー

ログインして会話に参加
Fedibird

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