分散性の違い

『BlueskyがActivityPubを採用しなかった3つの理由』がActivityPub批判/否定として読まれて(自分もそういうニュアンスは感じる)要らぬ軋轢を生んでいる気がするので、自分の理解と言葉で書いてみようという試み。便乗とも言う。

要旨

目指すものが違うし、両立は困難なので、独立・併存を試みるのは妥当

※但し、感覚的な仮定に独自解釈を重ねている

Blueskyの使命

そもそもBlueskyがやりたいこと、実現したいビジョンは何かという話。

例えばBluesky社のウェブサイトを見ると、「develop and drive large-scale adoption of technologies for open and decentralized public conversation」が使命であると書いてある。^{1 2}

これをどう読むかも議論が必要だが、ここでは一旦「public conversation ≒ 誰でも参加できる」「decentralized ≒ プロトコル」という取り出し方をしてみる。

個人的にはこの時点でも前者にかなり方向性の違いを感じるが、もう少し掘り下げていく。

public conversation

公開範囲の限定はメインターゲットでないと言っているように、Blueskyというかatprotoは基本的には全公開の方針をとる。³

加えて、Blueskyサービス(bsky)は検索やカスタムフィードの仕組みにより、特定の話題を見つけて加わることが容易になっている。これが地獄を生むのだという声もあろうが、とはいえBlueskyが目指す「public conversation」はそういうものなのだろう。前提としてそうしたいと言っているのだから、その良し悪しはここでの論点ではない。

なんなら時間方向にもオープンであろうとしていて、今でこそ妥協したが、当初は編集履歴も全部残そうとしていた。つまり誰でも/いつでも好きな発言を参照できることを目指していると思われる。APはフォロー中心で視界が決まり、公開(Public collection)は例外的な扱いであることを踏まえれば、方向性が違うことについては疑義が無いのではなかろうか。

それでも fediscovery.org みたいな試みはあるので一定の解決が得られそうではあるが、この辺は労力との兼ね合いや、真にグローバルにしたい意志があっての決別といったところか。

モデレーション周りの話もここにかかってくると思うが、そっちにはあまり明るくないし、そうでなくてもややこしい話になると思うので割愛。

decentralized

ここはかなり解釈の難しいところだが、個人的な主観で言うのであれば、Blueskyは一極集中が生じることを厭わない。appview(aggregator)に依存する構造を意図しているのは開発者も認めるところ。それどころか、同じ機能を持つappviewが複数存在する価値は低いとも言っている。

元々の思想として、APは複数のサービスが相互に接続する造りである⁴のに対して、atprotoは一つの巨大サービスを腑分けしたようなもの⁵で、利用者視点では分散感なんてほとんど無い。極端な話、運営者が唯一の隔離されたサービスを考えた時、APの出番は(少なくともs2sは)無いが、atprotoは使う。

ではBlueskyの言う「decentralized」はなんなのかというと、「中央」を選べる/ずらせることなんじゃないかと思う。利用者の好みや気分に応じて、もしくは方針変更や経済的な理由で頼れなくなった運用者に対して、特定のパーツだけを足したり引いたり入れ替えたりできること。これによって、利用者が依存している運営者が突如悪堕ちしたり失踪したりしても痛みを抑えられる、というのがBlueskyとatprotoが目指すところではないだろうか。それを「decentralized」と呼んでいいのか疑問が残るが、Nostrにおけるrelayの扱いの延長線上にありそうな気はする。

ひとまずそういうことにすると、APにアカウントポータビリティが普及していないのは如何にもまずい。それを乗り越えたとしても、提供されるサービスは殆ど所属サーバのみによって決まるので、有事のダメージが重い、とも言える。

共に生きよう

とはいえ、それでもAPを頑張ってなんやかんやすれば実現できるんじゃないか実現可能なんじゃないか、既存の標準規格と道を違えなくてもいいだろう、という向きもあるかもしれない。これに関しては、元記事が挙げた理由に対して「そこがAPのいいところなのに」みたいな意見が多数挙がっていたのが十分答えになるんじゃないかと思っている。

やりたい派とやりたくない派がいて、全体の世界観の話なんだから、無理に一つに詰め込むより棲み分けた方が自然じゃないだろうか。ありがたいことにブリッジもあるのだし。そうでなくとも両方使う人達だって沢山いる。会いに行く……かは分からんけど、適度な距離感でやっていきたい。

余談

自分はかなりatproto擁護の立場だと思うが、バランスを取るために、方向性で済まない弱点の話もしておきたい。

偶に言われる「そんな在り方が成立するか？」「Bluesky社がダメになっても続いていけるか？」については、正直分からない。個人的には楽観視しているが、とはいえ今Blueskyが突然消えたら多分どうしようもない。いつか来るその時のお楽しみということで、ここはひとつ。

追記

少し考え直してみたところ、Blueskyの言うdecentralizedはpublic conversationの一環と捉えられるので、そっちに一本化した方が見通しは良かったか。特に抱え落ちされないという意味でのロックイン回避⁶を軸にするなら、「時間方向にオープン」に直結すると言えそう。

composablityも重視されているので、少し欲張ってしまった。この辺りの理念は特にJay氏インタビューで語られている。

もしくは、先日のmeetupの講演でもいいかもしれない。Dan氏は以前からこのネタで講演して周っているようだ。

逆にpublic conversationは暗黙の前提になってしまっている気もするので、こっちも同じくらい高らかに掲げて語ってくれるとミスマッチも減るのではなかろうか。

Footnotes

1. これは会社立ち上げ時のブログ記事にも記載があるし、それ以前から言っている。「from platforms to protocols」もよく使われがちだが、前者に内包される要素をキャッチーに取り上げた感じ。 ↩

2. それはそれとして、この会社紹介ページでfederated/federationという言葉を使ってるのは、既存のFediverse概念に便乗した良くないアピールだと思う。最近は意図的に避けている節があり、それはそれで不誠実な気もするが。 ↩

3. とはいえ、利用者の強い要望に応える形でブロックもDMも実装したし、非公開コンテンツもある程度はatprotoでサポートするつもりだと言っている。 ↩

4. この見方がAP本来のものであるかは分からない。少なくとも現状は、独立でも動作するサービス群が相互に連携するためにAPを使う、というのが主流であるように見える。理想的には全利用者が独自のサーバを持つべきなのだろうか。 ↩

5. そもそもの始まりがTwitterにプロトコルが導入できるか検討しようという話だし……。 ↩

6. 掌返しから逃げられるかという観点は、相対的に少し弱い。特にdid:plcはフォークに乗り換えはできても共存ができないため、おそらく多数決になる。 ↩