そそ、ActivityPubにおける「グローバルビューの欠如」は不必要な文化の衝突を防ぐための意図的なものであるのよね。最初から全ての人がつながっているとそれだけ衝突が発生しやすくなる。
#Bluesky は #Fediverse の課題点を技術的に克服しえるものとして #ActivityPub に変わる新たな #ATProtocol を作ったという流れは理解してるけど、その #Fediverse の課題点がそもそも従来のように「SNS はグローバルビューをもつべき」という世界観から見たときの「課題感」だと思っていて、#Fediverse はそもそも「適度に分断し、適度に繋がる」ということを前提として設計されていて理想像がそもそも違うし、それを「#Fediverse には投稿の無断収集に文化的抵抗がある」という話だけでなんとなく「ネガティブで保守的な文化がある」という感じにしか書かれていないのが少し残念だった。
なぜ #Fediverse にそういう文化があって、なんでそれが一定数そこで支持されてるのかということまで深堀りしていくと、そこにはもうちょっとポジティブな見方もできることもあるはずなんだけどなーと。
ただ、どこにでも原理主義的な考えはあるように、たしかに #Fediverse には「勝手にクロールされる」ということに強烈に拒否反応を示す人がいたり、そういう人の声で串刺し検索サービスが「もう無理ー」と潰れてしまったことは、事実、自分が #Mastodon #VivaldiSocial 始めたあとにもあったし、#Mastodon に現状の検索機能にも結構強く反対している人がいたのは見ているので、確かにそういう文化的「傾向」というのはあるとは思うし、対抗する #BlueSky が目指す理想もわかるところはある。
じゃあ #Bluesky が「良い」のか?といえば自分にとってはそんなことはなくて、現状ではむしろ #Bluesky こそ稼働しているインスタンスはほぼ中央集権だし、結局「技術的に分散可能というだけで実質中央集権」みたいな「分散型という傘をかぶっただけの存在」になる可能性はあると思う。
その点、標準化団体が標準技術としてすでに定めている #ActivityPub に対応した複数のソフトフェアがあって、またインスタンスの大小があるにせよ、それらのソフトウェアが使われた複数のサーバーを個人や企業が運用していて、それがすでに連合しているという実績も #Fediverse にはあって、それを無視して従来の SNS の視点でみた「グローバルビューがない」という観点だけ(※)で過小評価するのはフェアじゃないような。
※
アカウントポータビリティは少なくとも にはあるし、スケーラビリティーについても、理論的限界はそうであっても、実際には時間が改善・解決していく部分もあるし、今必要なスケールに対応できているのであればそんなにクリティカルな問題じゃないと個人的には思っている
(つまるところ not for me な記事だったというオチ
OSC 2024 Tokyo/Fallに出場するまでの間、Holloに追加する機能:
• Moveアクティビティに対応(FEP-7628)
• 絵文字リアクションの送信(受信はすでに可能)
• ブロック
• ミュート(一部実装済み)
結局のところ ActivityPub は、どこまで行っても「自分でサーバーを建てられる人のためのプロトコル」なのではないか、という結論に至った。
ATProtocol のことは詳しく知らんけど、各サーバーが全世界の全投稿を保持するのであれば、それは巨大なインフラコストに帰結するわけで、事実上の独占あるいは寡占状態になる以外の選択肢がないと思われる。(そこを上手いことやる仕組みがあるのかもしれないけど)
ActivityPub はグローバルビューを捨てることにより、各サーバー管理者が身の丈にあったサーバーを構築することを可能にしている。
お金を払ってでっかいサーバーを建てたりでっかいサーバーに所属したりすることもできる一方で、低コストで小さいサーバーを運用したり所属することもできる。
次に何かを作るなら、プログラミング言語としてGleamを使ってみたいです。
BEAM(ErlangとElixirのランタイム)でも動作し、JavaScriptでもコンパイルされる静的関数型言語。
ActivityPubをC#で実装しようと試みた事が有るが、JSON-LDの拡張性に対応し、十分な柔軟性を持たせるのが難しかったので断念した。ActivityPubの初期実装たちや、ActivityPubの前身であるプロトコルの実装たちが主にPHPやRubyの様な動的言語なので、プロトコルも自然と動的言語で実装しやすくなっている気がする。
Holloはタイムラインを別にキャッシュする方式ではなく、リアルタイムでフィルタリングする方式なので、古いタイムラインも全て見る事が出来ます。
QT: https://mi.taichan.site/notes/9z2lnj9qe2 [参照]
https://whtwnd.com/boobam.bsky.social/entries/BlueskyがActivityPubを採用しなかった3つの理由
Fediverseの全域で同等な体験が得られないことにむしろFediverse民は価値を見出しているとか、巨大サーバーは無視して端っこどうしでチョコチョコやっても良いしやらなくても良いとか、そういう機微が分からないんだなぁ、と思ってしまった。
いち早くFediverseに移住した弊社としては色々と思うところはありますが、この記事にはあまり賛同できませんね。
もちろんが最高で良いとも思ってはいませんが、AT Protocolの掲げる理想より、ActivityPubのほうがずっと現実的であり場合によっては優れているとも考えています。
この記事で「グローバル検索性」のなさを指摘していますが、本当にそれが必要なのか、それを実現したでの悲劇などを考える必要があるでしょう。
1に、これを実現するためには全ての投稿を一箇所に集める必要があり、それは検閲に繋がります。ActivityPubは、検閲できないようにするため、あえてグローバル検索を犠牲にしたんだと思います。機能が劣るのではなく、そういう設計思想、割り切りだと思います。
2に、結果としてActivityPubでは、ブースト・RNで範囲は拡大されますが基本的には投稿が届く先はフォローで繋がっている先までに限られます。
このため縁もゆかりも無いところにはあまり届かないので、あらぬところから唐突に反抗的なメンションが来たりする可能性も少なく済み、棲み分けで平和に暮らすことができると思います。
では意図しない先にまで届いてしまうグローバル検索性があるため、マウントを取ろうとする人の登場など日常茶飯事でした。 [参照]
個人用ActivityPubサーバーを運営したいけど、MastodonやMisskeyをインストールするにはサーバーの仕様が足りないので悩んでいますか?それなら、個人用の軽量ActivityPubサーバーであるHolloを使ってみてください!
私はソウルに住んでいる30代後半のオープンソースソフトウェアエンジニアで、自由・オープンソースソフトウェアとフェディバースの熱烈な支持者です。
私はTypeScript用のActivityPubサーバーフレームワークである「@fedify」と、1人用フェディバースのマイクロブログである 「@hollo」の作成者でもあります。
このアカウントは主に日本語で話します。まだ日本語が下手なので、ご理解ください。メインアカウントは「@hongminhee」(主に英語)です。