11:41:02
2024-05-04 03:06:11 Posting のえる noellabo@fedibird.com
icon

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

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

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

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

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

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

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

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

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

11:42:33
icon

fed.brid.gy/docs#other-bridges
snarfed氏は確かFEP-fffd Proxy Objectsに関心を持っていたよなと思ってドキュメントを見たら、ちゃんと言及されていた

11:46:10
icon

Add proxy links to AP objects via FEP-fffd · Issue #543 · snarfed/bridgy-fed
github.com/snarfed/bridgy-fed/

Web site image
Add proxy links to AP objects via FEP-fffd ?? Issue #543 ?? snarfed/bridgy-fed
12:21:45
icon

@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

21:05:24
icon

`STANDARD`←何のstandard?
`general_purpose::STANDARD`←General purposeな何?
`engine::general_purpose::STANDARD`←何のengine?
`base64::engine::general_purpose::STANDARD`←長い!