霞と霧 @blue_flower@fedibird.com

この記事が掲載された時点よりも状況は拙速に悪化していると思われる
どんなサービスであろうと、そういう性的な要素が含まれているかも知れないと判断されれば無条件に資金繰りが悪化させられるという強烈なリスクを負ってしまうのだ
https://www.itmedia.co.jp/news/articles/2405/02/news110.html

ニコニコ、Visaでの有料会員支払いを一時停止へ　Mastercard、American Expressに続き(ITmedia NEWS)
#Yahooニュース
https://news.yahoo.co.jp/articles/d7d7f6d4a92408bf2f381b8a17a40256c376a236?source=sns&dv=pc&mid=other&date=20240509&ctg=it&bt=tw_up

Hi all! Well, I didn’t plan it, but word got out anyway: Bridgy Fed‘s Bluesky <=> fediverse support went online a couple weeks ago, quietly and without announcement, but people still found it. Over 1200 accounts have turned it on so far and bridged themselves one direction or the other. It’s great to see so much early interest!

(For anyone unfamiliar with Bridgy Fed, here’s an introduction.)

It’s still very early, and I wasn’t quite prepared for this much volume this quickly. Expect lots of bugs, missing features, downtime, and other rough edges. The docs are mostly up to date, at least. If you hit a problem, search the open issues, and if you don’t see it there, feel free to file it.

Also, much of the current state is not final. Expect some design and policy choices to change. For example, right now you have to manually enable the bridge, but that may change eventually, at least for Bluesky accounts bridging into the fediverse.

Otherwise, there’s a ton to do, and I’m only one person, doing this on the side, so progress will be slow. They say if you don’t feel uncomfortable when you ship, you probably waited too long, so let me just say that I feel very uncomfortable right now, hopefully in a good way. 😀 Thanks again for all the interest, and for your patience! [参照]

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

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

（ブリッジ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から（ブリッジ経由で）返信したところ。