ActivityPubのリファレンス実装はMastodon
システムの高速化はPleroma
エンターテイメントはMisskey
アイデンティティの管理はHubzilla
低通信量化はボクのWebTorrentをFidiverseへ応用するやつ
Twitterがどういうアプローチで分散化させてくるか本当に見もの
Twitterがそのユーザ数を支えきれなくなりつつあるというのは数年前から指摘されていて、Twitterは目に見えるほどマネタイズへ注力してきた
Facebookを参考にしたのか積極的な広告掲載によって収益を挙げることを目指し、そのために旧来のAPIを閉じるという強権を奮った(もちろん低通信量によるコストダウンの意味合いもあっただろうけど)
外部からの観測に過ぎないけど、Twitterはユーザによるセンセーショナルな言動を敢えて見逃す素振りを見せていてゴシップ的な雰囲気を作り出すことでアクティブユーザ数を増やすという姿勢を最近見せている
アクティブユーザ数を増やすことによって広告がより多くの人の目に触れるようにしたいのだと思われる
ここから考えられること、それはTwitterはもはや少なくとも広告が無くてはならない運営体制になっていて、例え分散SNS化を果たしても広告配信の仕組みを何処へ持つのではないかという想定がある
Twitterが採用する分散SNSシステムのアテが実は既にある
TwitterはデプロイツールとしてMurderというシステムを採用しており、これはBitTorrentを応用したものだ
https://www.publickey1.jp/blog/10/twitterbittorrent.html
このことからTwitterの分散SNSシステムは分散SNSサーバ間をBitTorrentで接続する可能性があり、これはちょうどボクが発案したFediverseへWebTorrentを応用するやつの逆パターンだ
ボクも当然ながらサーバ間をBitTorrentで接続する案は持った。しかし開発・保守・運用の観点からこの案を棄却した
何故なら、前提として分散SNSサーバ間をBitTorrentで接続するということ、それ即ちActivityPubとの互換性が得にくいということだからだ(技術的にはやろうと思えばできるけど)
MastodonのOStatusリムーブによりGNU Socialとの通信互換が失われたようなことは可能な限り避けたいという想いがあった
Twitterの分散SNS化の目的はおそらくTwitter本家サーバへの負荷軽減ということなのだろうと思う
負荷をサードパーティTwitter分散SNSサーバへ迂回させたいのだ
ボクの発想は何処か1つのサーバを助けようとするものではなく、Fediverseへ接続する分散SNSサーバすべてが何らかの恩恵が得られるように考えたものだ
例えば、WebTorrentへ対応していない分散SNSサーバからメディアが流れてきても、WebTorrentへ対応した分散SNSサーバは参加するユーザがWebTorrentによってメディアを共有するので、WebTorrentへ対応していない分散SNSサーバも恩恵が得られる
Twitterには、Twitterしか恩恵が得られず、なおかつ、広告が無条件に流れてくるような分散SNSシステムの開発は辞めてほしいなと思わざる得ない
分散SNSサーバ間をBitTorrentで接続する問題は他にもある。データの同一性を担保するのは誰なのかという観点だ
おそらくTwitterが分散SNSサーバ間をBitTorrentで接続するシステムを開発すると、データの同一性を担保するのはTwitterではないかと想定できる
これはつまり結局のところTwitterという中央集権SNSサーバが存在するということに何ら変わりなく分散SNSとして疑念を持たざる得ないシステム構成になってしまう可能性が高い
更にTwitterへ接続するサードパーティ分散SNSサーバが低スペックだった場合ユーザビリティがどうなるのかという懸念もある
分散SNSへ参加するユーザ間をBitTorrentで接続する方式は、分散SNSサーバが低スペックであっても誰か1人のユーザが完全ファイルのダウンロード完了し、かつ、BitTorrentトラッカーが生きていれば、低スペック分散SNSサーバへの負荷を最小限にしつつユーザビリティを損なわないようにできる