こちらは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の目指すところで、理想から遠ざかってしまうのです。
解決策はあるかもしれませんが、原状、そういうポジションにあるということは憶えておいてください。
@perillamint I think one of the most trickiest workarounds would be handling of objects referencing other objects, such as reblogs/shares and quotes.
Perhaps, the implementation could act as a bridge and generate bridged objects when such references are made, but copyright implication of that approach is unclear, and it would worsen the duplication problem further