ActivityPub サーバとクライアントの特殊化のミスマッチ

現状の ActivityPub エコシステムでは、サーバがコンテンツの種類を強く縛りすぎていると思う。

名誉を集約し、楽しみ方をカスタマイズする

ActivityPub では多様なアプリケーション (サーバもクライアントも) が共通のプロトコルを利用して相互に投稿をやりとりできるのがネットワークとしての大きな魅力のひとつだが、その運用を便利にしようと考えるとき、私の考える便利な方向性とは「ひとつのアカウントから多様な情報を発信しつつ、フォロー先の投稿を見るのは情報の種類に特化したクライアントで行う」といったものである。

ここでいう多様とは、たとえばブログ記事、たとえば写真、たとえば中編動画、たとえば短文投稿、たとえば音楽、たとえばソーシャルブックマーク、といったように性質レベルで大きく異なる投稿の種類のことで、旧来であればこういったものは投稿の種類ごとに別々のサーバ、別々の web サービスで扱われていたものであった。 これらの発信源を単一アカウントにすることで、「特定の人が作成した/発信したもの」という発信者 (あるいはクリエイター) のアイデンティティの統合ができるという点で個別の web サービスを使うよりも便利になる。 対してユーザは、見たい投稿の種類ごとに UI 体験が特化したクライアントを用いてタイムラインを眺めることで、全てが雑然と汎用的な形でのみ流れてくる状況を回避できることを望むだろう。 受信に関しては自由度があり、アカウントとサーバを別にしても良いし、サーバサイドで投稿種別ごとにフィルタリングできても良いし、クライアント側でフィルタリングできても良い。 受信さえできていればやりようはある。

端的に表現するなら、「発信者は創造や情報発信の名誉をひとつの名義に集約できるべきで、受信者は受け取った多様なコンテンツの楽しみ方をカスタマイズしやすいべきである」ということになる。

ActivityPub エコシステムの現状

しかし現実の ActivityPub fediverse をいちユーザとして見てみると、私の考える理想とは全く逆方向に機能している。 つまり「多数のアカウントから情報を発信しつつ、フォロー先の投稿を見るのは汎用の (あるいは単一種類の投稿を主に想定する) クライアントで行う」という状況が一般的なようである。

人々は投稿の種類ごとに別々のサーバ実装 (そして当然別々のアカウント) から発信し、フォローと受信は単一のアカウントから行っている。 たとえば短文は Mastodon から、写真は Pixelfed から、長編動画は PeerTube から、ブログは Write.as から、といった具合である。 そして各種投稿のビューの形も、フォロー元アカウントのサーバ実装に特化した形になりがちである。 たとえば Mastodon からフォローしている場合は写真であれ動画であれ音楽であれ長文記事であれ、すべての投稿を「短文投稿 SNS 上での投稿」の形で閲覧することになる。

サーバは投稿種別に中立であることが望ましい

思うに、このような逆転が発生している原因は「サーバ実装が (発信、受信ともに) web UI と強く紐付いている」ことにある。 発信側サーバが特定の投稿種別に特化した web UI を (あるいはそれに加えて内部的な実装を) 持っていると、他の形式の情報を同じアカウントから発信しづらくなる (あるいはそもそも発信できなくなる)。 そして受信側サーバが特定の投稿種別に特化した web UI を (あるいはそのようなクライアント API のみを) 持っていると、「アカウントは同一だが異なるクライアントを目当ての投稿種別ごとに使い分ける」という利用法が成り立たない作りになりやすい。

このような問題を解決するためには、サーバが送受信いずれにおいても特定の投稿種別を前提としたりそれに特化したりせず、内容に中立なまま投稿の送受信とクライアントへの伝達に注力することが望ましいだろう。 そして可能ならもうひとつ、投稿・閲覧のための web UI を用意しないこと、あるいは用意するとしても特定の利用方法を前提にした味付けをしないことが望ましい。 サーバは用途不定のネットワークの一部としてコンテンツに対して中立であれということである。 投稿やそのインターフェースを味付けするのはクライアントが専任であるべき仕事だ。

とはいえこれは ActivityPub の server-client API のように中立なプロトコルがサーバ–クライアント間でも一般的にならないと難しいような気もするが。 そんな日が来るのだろうか？