概要
2023-03-05に投稿された記事が話題だったので紹介します。以下の投稿で告知・公開されていました。
Rikuoh Tsujitani|riq0h@calckey.jpエッセイ記事。開発方針や人気サーバの肥大化に言いたいことがないわけではないが、分散できないのはどう考えても僕たちが悪い。
再投稿が100件超過と話題でした。「分散できないのはどう考えても僕たちが悪い | 点と接線。」が記事でした。
「Misskey.ioへのユーザー殺到 | GNU social JP」で紹介した、2022年2月のMisskeyへのユーザー殺到を受けて、サーバーの中央集権についての考察でした。
最近だと、先のユーザー殺到記事で登場した「misskeyの急速な流行と分散型SNSの限界 | 右や左の旦那様」や、1月末に議論のあった「Mastodon巨大サーバー集中化の問題とfedibird.comの公開登録一時停止 | GNU social JP」が同じ議論の内容です。
内容
記事の内容を自分なりに重要な部分を抜粋しながら掲載します。
2017年4月のMastodonブームとその終焉に触れ、国内2強サーバーとして、mstdn.jpとpawoo.netが同じ運営元で、この2サーバーだけで国内のMastodon人口の大半を寡占している現状を指摘。
昨今のMisskeyブーム (misskey.io) に触れ、Mastodonと目立つ違いとして、SlackやDiscordのような絵文字リアクションを紹介。
ただ、MastodonもMisskeyも分散SNSでありながら結局一極集中という同じ構図。特に、Misskeyはサーバーによって使用可能な絵文字リアクションの種類がまちまちだから、根本的なユーザー体験自体も異なる。現状、レターパックなどTwitterでバズっている絵文字を使おうとすると、ioに人が群がるしかなく、他のサーバーに分散する理由がない。
実際、Misskey著者自体も分散はおまけという扱い。分散を軽視しても差し支えない理念なら、絵文字リアクションなど以外にTwitterと差別化できる価値観がない。このままioがユーザーを吸い取って中央集権化するなら、分散SNSを僭称している分、他の分散SNSサーバーからすると、下手をするとTwitterよりたちが悪いかもしれない。
Misskeyは反中央集権といった思想は無く分散はおまけ機能
さらに、Misskeyにはチャンネルという、他のサーバーから参加不能な閉じたコミュニティー機能があり、分散からは離れている。結局、分散といっても競争で、io以外は負けたサーバーなんだという誤解も与えかねないし、実際そういう認識のユーザーも見かける。
ただ、このような非難をするのは簡単だが、実際はユーザーが悪い。社会性動物としての習性を克服できない人間が悪い。
登録ユーザー数上限を設けるなどすれば、一極集中は止められるが、ユーザー需要を無視したSNSがユーザーから支持されるわけがない。結局、人々の行動原理が変わらない限り、一極集中を止める術がない。巨大サーバーが新規受付を止めれば、人気サーバーに入れないならいいやと、ユーザーが入ってこないだけ。
大型サーバーに小規模サーバーがぶら下がって存在する状況で、一見すると分散型だが、中身はヘゲモニー政党制 (表面には複数政党制や野党が存在しているが、実際には与党が全ての権力を握り、事実上の反対側政党は存在しない制度 (ヘゲモニー政党制 – Wikipedia)) になっている。メガサーバーが停止すれば、ミニサーバーも大量のFF (フォロー・フォロワー) と断絶されるため、実用性は従来のSNSと大差ないか、むしろ低い。ユーザー断絶の問題は、自分専用の単独サーバーを設置しても解決できない。
ただ、将来的に計算資源が低廉になって、実装がより平易になって、リモートとローカルの違いがなくなると、解決するかもしれない。
考察
分散SNSのメガサーバー一極集中の問題と、人間の本能を取り上げ、本能を克服できないユーザー側に問題があるのではないか？という考察だったように思います。
Misskeyのかかえる問題点 (分散SNSを僭称している分のあたり) をうまく指摘している箇所は、うまく言語化されていて同感でした。こう思っている分散SNSの支持ユーザーがいて安心しました。
記事読了直後の私の所感は以下です。
ぐぬ管 (GNU social JP管理人)|gnusocialjp@gnusocial.jpこちらの投稿が話題なようです。 ユーザー目線での分散化の利点を特に意識、PRしないと、結局中央集権になってしまいますね。
「分散できないのはどう考えても僕たちが悪い」という題名ですが、私はそう思いません。 人間の本能、心理的に、中央に集まる傾向があるので、それを回避する仕組みが大事だと思います。 その議論はそこまで進んでいません。 理想は一人一台の単独サーバーです。
!sns Friendica/GSはこの理想に比較的適しています。テキストエディターや、ブラウザーのように、プラグインで、サーバー機能を独自にカスタマイズできるからです。 安くて設置も比較的簡単です。 そこをPRしたいのですが保守が必要でまだPRしにくい状況です。時間かかります…
今回のような分散SNSの中央一極集中の話はところどころで勃発しますが、あまり議論が深まっておらず、問題の指摘やその賛否程度でだいたい終わっている感じがします。
私としては、上記の通り人間の本能・習性が一極集中を選好しているので、人間のせいにするのではなく、それを回避する仕組み、積極的に分散化したいと思える、便益などを提示することが大事だろうと思っています。
FOSSと同じで、単に交流を楽しみたいだけの多くのユーザーにとって、分散やベンダーロックイン回避はあまり重視されません (元投稿の返信にも複数そういう意見あり)。ただ、FOSSの場合はそれでも無償利用という点で一般ユーザーにも便益がありました。
私と似たような考察・意見が以下などでありました。
Maekawa Minoru|trapezial@calckey.jpActivityPub以外の分散型実装を模索している身からすると、分散できないユーザーが悪いんじゃなくて「分散されられないようなデザインにしてしまっているのが悪い」とも思ってしまう。 所謂「検索性」を分散型としても上げられるような仕組みにできなかったから（野良から）襲われないと知ったユーザーが安堵をする→大移動が始まらず一極集中化を引き起こすことになると考えている。 エッセイ記事。開発方針や人気サーバの肥大化に言いたいことがないわけではないが、分散できないのはどう考えても僕たちが悪い。
Namekuji 🦴|nmkj@calckey.jp一人のサーバー管理者として記事を読んで思ったこと
僕たち運営者や開発者はどうしてもプラットフォームの技術自体に目を向けがちなのだけど、やはりSNSである以上重要なのはそれを使う人なんだと再認識させられた。加えて、ユーザーに分散の責任を持たせてしまうのもデザインとして問題があるように思う。僕も一極集中自体はあまり良くないとは思いながらも、メガサーバーの存在や、それを維持しようとすることを非難できない。僕はまだ良いアイデアを思いついていない。 とりわけ難しいのが、「サーバーを建てる」のは実は一番簡単な部分であり問題はその後だということ。モデレーションが追いつかなくなることが一番の懸念なので、そこまでいくと「身の丈に合っていない」と思われても仕方ないだろう。でもそれは、そういう場所を作ってしまった僕たち運営サイドの責任であり、分散しなかったユーザーのせいにはしたくない。 僕は分散型という概念を、どこかで何かが壊れても人の繋がりが絶たれず、望めば自分で自分のデータを管理下におけることだと認識しているので、特にハードルになってる一人用サーバーの構築をもっと簡単にできないかと思ってる。この前ちょっと紹介した開発中のアプリは、今の分散の問題に対する解の一つにしたい。エッセイ記事。開発方針や人気サーバの肥大化に言いたいことがないわけではないが、分散できないのはどう考えても僕たちが悪い。
管理者としても、ユーザーとしても、何もなければ分散よりも中央集権のインセンティブのほうが働きます。SNSにはネットワーク効果 (考察: Twitterユーザーが分散SNSに定着しない理由 | GNU social JP) がありますので、ユーザー数がUXにつながります。管理者としても、ユーザー数が多いほうが寄付などで収益・運営費の確保がしやすいです。分散SNS実装の多くはFOSSで用途は自由なので、中央集権を目指すかどうかはサーバー運営者の方針次第です。方針を非難したとしても、Twitterと同様に止めることは難しいです。
ActivityPub以外の、他の分散SNSのプロトコルだと、Nostrは他のユーザーとの交流に最低1個は同じリレーを使う必要があり、私の印象ではこれも中央集権のインセンティブがあります (分散SNSプロトコルNostrとiOSアプリDamus | GNU social JP)。
ATプロトコルはまだ開発中で未知数ですが、「AT Protocol (BlueSky)仕様を読んでみた ～ W3C DID仕様を添えて ～ – Qiita」を見る限り、ActivityPubに対して、ユーザーアカウントの移植性、クローリングなどで検索など、ローカルとリモートの垣根を減らす仕組みが入っています。ただ、これもどこかのサーバーに登録するタイプであれば、結局中央集権のインセンティブが働くしかない気もします。ローカルタイムラインが仮になかったとしても、人気・有名サーバーに人は集中するでしょう。
ネットワーク効果の存在するSNSの分散化・中央化回避は本質的に難しいのかもしれません。私が思うに、他のプロトコルでも似たような問題がある気がするので、現状出せる案がこの課題への対策の全てになる気がします。
どこかできっちり整理して書けばいいのでしょうが、うまくまとめられる自信がないので、ここで私の考えをとりとめもなく暫定的に記しておきます。
私はActivityPubの自分専用単独サーバー・ミニサーバーがこの問題の現状最善の答えと思っており、現状の分散SNSでできる一極集中の対策案は以下2点だろうと思っています。
- 自サーバーのお手軽化
- ユーザーリスト
1点目は設置を簡単・低費用化するということです。これは自前設置・分散化に対する便益の提示です。設置や運営に手間・費用がかかるなら、自分で設置しようと思う人はあまりいません。他人のサーバーに登録するなら、自分の趣向に合ったサーバーは別としても、メガサーバー以外にインセンティブが働きません。自前設置で得られる便益としてFriendicaやGNU socialのプラグインのような、サーバーのカスタマイズ機能も悪くないと思います。これは上記の私の所感でも提示しました。以前存在していた広告付きの無料のMastodonホスティングサービスのムトーも悪くない例でした。FriendicaやGNU socialは無料のレンタルサーバーでも動作する可能性が高いので、これをクリアできるポテンシャルはあります。
2点目はユーザーリストです。個人サーバーの課題は自分でユーザーを見つける必要がある点です。この件は「連合リレーへの参加を推奨しない理由 | GNU social JP」でも若干触れました。SNSの本質は、投稿とフォローだと私は思っており、興味のある投稿やユーザーを見つけることが大事だと思っています。これがないならSNSのメリットはほぼない気がします。既存の分散SNSのサーバーは、ローカルタイムラインや連合タイムラインでユーザー探しを補助しており、初回登録以外のメガサーバーの利点はこのローカルタイムラインだと思います。
ユーザーレコメンドや、どこかにオススメユーザー一覧やその提供サイトなどがあって、一括フォローなどできれば、ユーザー探しが簡単でしょう。後は、GNU socialやFrinendicaなどのグループ機能、リスト機能の拡充などもこの助けになるかもしれません。他のサーバーのグループや他人のリストをフォローする仕組みがあるのです。
自分のサーバーで有名ユーザーなどをフォローさえできれば、サーバーのトレンド機能で、話題の投稿の把握などはできます。ATプロトコルのように、何かクロールするようなもので、ユーザーや話題の投稿を一覧化するというのもいいかもしれません。
案を出してみましたが、どちらもユーザーが自発的にアクションを起こさないといけないので、元投稿の著者の通り、最終的にはユーザーが悪いのかもしれません…自前サーバーや、分散の便益については、日頃から意識して、訴求・PRしていく必要性を強く感じます。どこかできっちり整理・考察したいところです。
結論
「分散できないのはどう考えても僕たちが悪い」の話題の記事の紹介でした。
イーロン・マスクのTwitter買収を受けて分散SNSに大量のユーザーが流入してきて、分散SNSのフェーズが一段階進んだ感じがします。
ユーザーが増えたことで、今までも度々議論に上がってきた、分散SNSのメガサーバー一極集中問題の議論も再熱してきました。これまでは議論になっても、問題の指摘とその賛否に終わる感じで、やや浅い感じでした。新しいユーザーも巻き込んだ形で、具体的な対策を含む一段階深い議論が数多くなされることを期待したいです。議論の結果、「やっぱり分散する必要ないよね。やっぱりTwitterが一番だね。」という結論がでたとしても、それはそれで参考になります。
今回、私は以前から思っていた2の対策案を提示しました。ただ、現状、私は目の前の作業で手いっぱいで、具体的に何か行動を起こす余裕はありません。余裕ができるまでは、Mastodon/Misskey/Pleromaなどの分散SNSの多くのユーザーがどう思っているのか、議論の行方を見守り、その記録に努めます。
詳細プロフィール。SNS: Twitter/GS=gnusocialjp@gnusocial.jp/WP=gnusocialjp@web.gnusocial.jp。2022-07-17からgnusocial.jpとweb.gnusocial.jpのサイトを運営しています。WordPressで分散SNSに参加しています。このアカウントの投稿に返信すると、サイトのコメント欄にも反映されます。
コメント
This Article was mentioned on web.gnusocial.jp
This Article was mentioned on web.gnusocial.jp