序

本稿はSNSの文脈でよく聞かれ、しかし一般的なSNSユーザーにとっては馴染みのない概念であるFediverseについてなるべくわかりやすく、かつ詳細に解説したものである。

これからFediverseの世界に触れてみようという人や、Fediverseの初心者、あるいはFediverseについて理解を深めたい人に適する。

また、なんとなく分かった気になりたい人ではなく、正確に理解したい人に向いている。

前提認識

この記事は長く詳細な解説が続くため、読者であるあなたはこの記事によって何を得ようとしているのかという認識を先に固めたほうが良いだろう。

本稿ではX的なSNSとしてFediverseを利用しようとする人(あるいは、その意味でのFediverseインスタンスに誘われた人)に向けて、「Fediverseの世界に入るかどうかの判断をするため」あるいは「Fediverseインスタンスを利用する前提でそのための準備をしておくため」に必要な情報を提供する。 また、副次的には「既にFediverseインスタンスを利用しているが、現状ではなんとなくのふわっとした認識で利用しており、もっと理解を深めたい」という人にも適している。

いずれにせよ、「あなたはX的なSNSとしてFediverseを利用する」という前提で話を進める。

Fediverseとは

「Fediverseとは〇〇である」という言い方ができれば良いのだが、既存概念として説明するとどうしても誤解がつきまとう。 Fediverseについて正しく理解している人が少ない要因でもある。

まず前提としておきたいのは、「Fediverseというモノはない」ということである。 つまり、「ヨーロッパ」みたいなものだ、という説明をすると適切ではあるのだが、これも「ヨーロッパに含む含まないが割れる国がある」ことを知っていないとピンとこない説明だろう。 だからまずこの言葉が

• 総称として使われる利便性のための言葉である
• 具体的に特定のものを指しているわけではない
• 定義には人によって若干のブレがある

ということを念頭に置いておくと良い。

Fediverseそのものを説明してもその正体は見えてこない。 しかし、周囲のことを知ると自然とFediverseのことは分かってくる。

まずは実装と運用というものを知るところから始めよう。

実装とサーバー

実装とは概念・規格を具体化したものである。 例えば、カローラは自動車の実装だと言えるし、PixelはAndroidスマートフォンの実装だと言える。

そして、ここでいう「実装」はソフトウェアである。 より一般的に馴染みのある言葉にすると「アプリ」のことを指している。

ただし、ユーザーサイドのアプリではなくサーバーサイドのアプリであり、ここがちょっとわかりにくいかもしれない。

サーバーは常時稼働し、他者が利用するためのものだ。¹ 人々に一番馴染みがあるのはウェブサーバーだろう。

Google Chrome, Firefox, Edgeといったウェブブラウザでアクセスできるサービス、サイト、ページは基本的にはウェブサーバーによって提供されている。 「ウェブ」が概念で、「ウェブサーバー」は規格の実装の総称だ。 つまり、「誰かが何かしらのウェブサーバーを動作させ、公開しているからウェブブラウザでアクセスできる」ということである。

例えば、あなたが見ているこのページは(これを書いた時点では)Nginxというソフトウェアを用いて配信されている。 Nginxは非常に人気が高いウェブサーバーで、あなたが普段見るウェブページも多くはNginxが用いられているだろう。

だが、同じNginxであっても、提供している人はそれぞれ違う。 Chienomiは私が運用しているNginxだが、私のNginxが世界中のウェブページを提供しているわけではない。 世界中には無数のNginxが動いており、それぞれのページがそれぞれのNginxによって提供されているわけである。

他の概念で似たものとしては、フランチャイズチェーン店がある。 例えばセブンイレブンだ。 セブンイレブンは多数の店舗がある。いずれもセブンイレブンではあるが、違う店だ。 しかも、セブンイレブンはほとんどの場合、それぞれの店舗がそれぞれの異なるオーナーが所有する店である。ユーザーにとっては「どれも同じセブンイレブン」に見えるが、そのセブンイレブンを経営しているのはそれぞれ別の人。 つまり、セブンイレブン店舗はセブンイレブンの実装であり、オーナーはセブンイレブン運用者であると言える。

そして、そのウェブサーバーの実装はひとつではない。 NginxのほかにもApache, Lighttpd, Caddy, Hiawathaなどいろいろある。

これもコンビニフランチャイズと同じようなものだと言える。 セブンイレブン、ファミリーマート、ローソンといった種類があるのと同じことだ。

SNSの概念

従来のSNSの概念をおさらいしておこう。

例えばTwitter²であれば、Twitterが作ったTwitterの実装を、Twitterが運営する、という形式であった。 つまりは、サービス、実装、運営者が完全に一体であり、「Twitter」と言った場合に通常はそれらを区別する必要はない。

だが、これらは一体でなければいけない、という制約を持っているわけではない。 というより、「第三者が利用できる実装が存在するかどうか」によって話が変わってくる。

第三者が利用できる実装が存在しないとすると、SNSを展開するためにはSNSソフトウェアを自ら開発して展開する必要がある。 そうなると、ソフトウェア実装と運営者は一体になりやすく、必然的にサービスまで一体になる。

だが、公開された実装があり、それを他の人が動作させることができるとすれば、実装開発者と運営者は別になる。

代表例としてはMastodonがある。 MastodonはGPLv3によってライセンスされる自由なソフトウェアで、これを使ってSNSを運営することができる。 Twitterが1店舗しかない巨大デパートなら、Mastodonはコンビニフランチャイズだ。「色んな人が運営する色んなMastodon」が存在できる。

実際はもう少し複雑な例もある。 例えばBlueskyはBluesky Social PBCが開発するSNS実装であり、Bluesky Social PBCは<bsky.app>{rel=“external”}を運営してもいる。 が、Bluesky自体はMIT/Apache 2.0のデュアルライセンスで公開されていて、他の人が自分のBlueskyを運営することも可能だ。 Blueskyの場合はもっと複雑な要素もあるが、それは本筋とは関係ないので割愛する。

こうした「形態の違い」があることを理解していないと、Fediverseの理解は進まない。 直営店という概念しか知らない状態ではフランチャイズチェーンを理解できないのだ。 逆に言えば、こうした形態の違いが理解できればあとは難しい話ではない。

分散SNS

自由に利用できるSNS実装があり、それを様々な人が運営するということはつまり、無数の小さなSNSが誕生するということである。

だが、多くの人はSNSを「人がいる」ことを価値として選ぶだろう。 自分一人だけが投稿し、自分一人だけが読むSNSに魅力を感じる人は少ないだろうし、それならばインターネット上に置く意味もない。 小さな仲間内だけのSNSもそれはそれで需要はあるだろうが、用いられ方としてはかなり限定的だ。 結局のところXやFacebookのように大きな存在にはなりえないということになる。

そこでその活用の幅を広げるための方法が「連合」である。

そのMastodonが他のMastodonの投稿を読むことができ、自分の投稿もまた他のMastodonから読まれるという状態になれば、世界中無数の小さなMastodonからなるひとつのSNSのように振る舞うことになる。

さらに、これがMastodonに限らず他の実装ともやりとりすることができれば、実装に閉じたネットワークではなく、さらに大きなSNSを形成できる。

このとき、SNS全体を見れば「無数の小さなSNSの集合」と見ることもできるし、ある特定のSNSを見れば「大きなSNSを構成するもののひとつ」と見ることもできる。

さて、こうなると困るのが呼び方である。 この集合はもはやMastodonだけでできているわけではないから、Mastodonと呼ぶわけにもいかないし、仮にMastodonだけの集合だとしてもMastodonと呼んだときに全体を指しているのか、実際に動いているサーバーのひとつを指しているのか、あるいはソフトウェアのことを指しているのかがとてもわかりにくくなってしまう。

そこでこのようになる

• Mastodonというソフトウェア -> Mastodon
• 動作しているMastodonのサーバー -> Mastodonインスタンス
• 特定のMastodonインスタンス -> (そのMastodonインスタンスの固有名詞)
• 連合によってやりとりしている集合の総称 -> Fediverse

ActivityPubとFediverseの全体像

ActivityPub

Mastodonだけの集合ならMastodon独自の方式をとればよいが、異なる実装ともやりとりしようとすると共通言語が必要になる。 Mastodonの場合はActivityPubという規格によって外部とやりとりをする。

ActivityPubはW3C³が定めた由緒正しいプロトコルである。

Fediverseを「ActivityPubでやりとりするSNSの集合」というように説明される場合もあるが、これは2つの点であまり正しくない。

まず、ActivityPubでやりとりできるのはSNSに限らない。 Mastodonのように「Twitterっぽいやつ」が多くはあるが、InstagramっぽいやつやYouTubeっぽいやつもあるし、ブログやニュースもある。

そしてもうひとつは、ActivityPubにも限らないということだ。 ActivityPub「でも」やりとりできるというソフトウェアが存在し、これを通じてさらに他の規格でやりとりしているサーバーとも間接的につながっている。 ActivityPub以外で使われているのは、Zot, Distopia, DFRNなどだ。

ただし、こうした事情も含めて、「Fediverse全体をひとつのものとして捉える」ことはできない。

プロトコル

ActivityPubでやりとりをするサーバーとZotでやりとりするサーバーがあったとして、両者は同じ言葉で話さないので直接やりとりをすることはできない。 だが、ActivityPubとZotの両方を話すサーバーは、そのどちらともつながることができる。

しかし、これはそのままActivityPubのサーバーが両方を話すサーバーを通じてZotのコンテンツを取得できるという意味にはならない。 両方を話せるサーバーにとって「中継する」という機能は、全く別の話だからだ。

だからFediverse全体がつながっているというのは全体像を言えばそうなのだが、実質としては特定のプロトコル同士で結びついている。 そして、現実的にはそのほとんどはActivityPubでつながっている。

さらにこれはFediverse自体の定義にも関わってくる。 例えばAT protocolだけでつながっているBlueskyはFediverseの一員とみなさないことが多い。 これは結局のところ、間接的であってもActivityPubのネットワークにつながっているかという視点にもなっている。

よって、ActivityPubサーバーのみをFediverseとして認める、という立場も成立するわけだ。

方言

ではActivityPubサーバーだけを一体とみなせば済むかというとそうもいかない。 まず実装間の断絶というものがある。

各ActivityPubサーバーはActivityPubを話しはするが、そのサーバー自体の性質によってサポートしている機能というのはある程度限られる。 加えて、ActivityPubがあまり網羅的でないということもあって、各サーバーは独自に拡張していたりもする。 (仕様的に拡張できるようになってもいる。)

これにより、拡張部分での意思疎通ができないということが発生する。

その拡張部分でも他の実装と協調する姿勢で実装されていることもあれば、既存の実装が存在するにも関わらず独自の仕様で拡張することもある。

割と各実装はそれぞれの強めの思想を持っているため、相容れない部分がある。 これにより方言による乖離というのはどうしても発生し、ある程度の断絶が発生しやすい。

ちなみに、ユーザー間でも「違う実装は違う機能・挙動を持っている」ということを理解せず、他実装のユーザーに対して攻撃的に振る舞うということが見られたりするため、実装でうまくやりとりできるかどうかとは別に、ユーザーの間でも亀裂を発生させたりもする。

現状、最も「方言に強い」のはMisskeyであり、他実装の多くの拡張を受け入れることができる。 一方で最も「方言が強い」のもMisskeyであり、Misskey同士でないとうまく機能しない部分というのもかなりある。

運営ポリシー

連合によってFediverse全体をひとつのSNSとして扱えるといっても、投稿先は特定のインスタンスになる。 そして特定のインスタンスは、それぞれの運営者のポリシーによって運営されているというのも問題になる。

運営者は自身が運営するインスタンスに利用規約を定め、ユーザーに対しその遵守を求めることができる。 しかし、外部のインスタンスに対してはその力が及ばない。 これは例えば、性的コンテンツを禁止しているインスタンスと許容しているインスタンスの摩擦などがある。

これに対する対応はどの実装を使っているかによってもできることが変わってくるが、基本的には「拒絶」である。 つまり、受け入れられないコンテンツが自身のインスタンスに入ってこないようにする。

このため、技術的に疎通可能なサーバー同士であっても、運営ポリシー上の理由で制限される場合もある。

疎通不安定

これらとは全く別な問題として、ActivityPubサーバーが期待と異なる振る舞いをする、ということが結構ある。 サーバーを運営していてよくあるのは、投稿やユーザーを取得しようとすると公開なのに404を返してくるとか、そもそも応答しないといったものが多い。

基本的にはこういったことは相手側起因なのでどうすることもできないのだが、同じ相手に対しても発生するサーバーと発生しないサーバーがあったりする。 こうしたことから、サーバー間の「相性」のような問題でうまくやりとりできない問題があったりして、こういったことでも自分が所属しているサーバーを意識するタイミングは存在する。

実装を知る

実装を選ぶ

Fediverseの世界に参加するには、Fediverseに属するインスタンスにアカウントが必要である。 より正確な言い方をすると「アクターを持つ」になるのだが、その言い方をすることはほとんどないので気にする必要はない。

Fediverseにアカウントを作成する上でどのインスタンスを選ぶかの判断材料のひとつとして、インスタンスが使用している実装がある。

Mastodon

代表的なActivityPub実装である。

基本的に機能は保守的で、意図的に制限されている。 例えば、引用⁴、絵文字リアクションといった機能がない。 また、ブースト⁵やお気に入りの数も表示されない。これはサーバー側で回答しないようになっているため、サードパーティアプリを使った場合で表示されない。

これらは単に実装していないというレベルではなく、Mastodon開発者の意思により拒否しているものである。 このことから、他の実装の機能に対しても非寛容である。

Mastodonが最も最初に有名になったことからMastodonをリファレンスとみなす人も少なくないが、実際のところ「ActivityPubの素直な実装」であるとは言い難く、まして「Fediverseの素直な実装」とはほど遠いのが実情である。 (そして、「素直な実装」などというものは存在しないのだ)

Misskey

実は初リリースはMastodonよりも早いActivityPub実装である。 初リリースは2014年、ActivityPub実装となったのは2018年である。

Misskeyは非常に多彩な機能を持っていることを特徴としている。 このことは他実装とのやりとりにおいて広く受けられるというメリットを持っている一方、Misskey側の機能が他実装で非互換ということが発生しやすく、Misskeyユーザーの感覚が他実装と齟齬を発生させることが多い。

Misskeyの機能はおよそ

• ActivityPub準拠、もしくは暗黙の了解となっている拡張であり、他実装ともやりとりができる
• Misskey固有の機能で、Misskey同士のみで有効である
• Misskeyのインスタンス固有であり、外部のサーバーからは不可視である

の3種類の機能に分けられる。

投稿関連の機能で言うと、

• 引用
• アンケート
• 絵文字リアクション⁶
• カスタム絵文字⁷
• カスタム絵文字リアクション⁸

などかなり多彩な機能を持っている。 一方で、いいね機能がない(v13以降、絵文字リアクションに統合)。

また、絵文字リアクションはつけられるものが同一ユーザーから一種類で、他実装の投稿に対してつける場合でも、あるいは他実装からMisskeyサーバーの投稿につけられた場合でも、同一ユーザーが最後につけたものに置き換えられるようになっている。 このほか、他サーバーのカスタム絵文字リアクションに+1することはできない。 これはMisskey固有の制限だが、Misskeyユーザーはこのあたりを誤解することが多々あり、摩擦になりがち。

Misskey固有の機能は非常に多いので、ここに一部列挙する

ドライブ (インスタンス固有)

ユーザーがアップロードしたファイルを管理する機能。 この機能により、ユーザーは投稿したファイルを再利用できるほか、管理者はユーザーがアップロードできるファイルの容量を制限することもできる。

ロール (インスタンス固有)

ユーザーに付与する権限機能。 単に管理者/モデレーターを指すものに限らず、制限の強化/緩和に使用することもでき、ペナルティや課金機能を実現しやすくしている。

引用の通知 (Misskey同士)

引用はActibityPubの標準機能がなく、引用投稿は引用元ユーザーに通知する仕組みになっていない。 このため、SoapboxやAkkomaなどでは「引用時、メンションを付与することで引用元ユーザーへ通知する」という方法でカバーしているが、MisskeyはMisskey同士であれば引用したことを通知する仕組みを持っている。

チャンネル (インスタンス固有)

インスタンス固有で独立したタイムラインを構成する機能。 特定のトピックを扱うスペースとして使うことができ、Discordのチャンネル機能と似たような使い方が可能。 チャンネル機能が他インスタンスにとって不可視なだけでなく、チャンネルへの投稿は自動的に非連合となる。

アンテナ (インスタンス固有)

サーバーが受信した公開投稿⁹の中から条件に一致するものを抽出してタイムラインを構成する機能。 自身が見るためのもので、インクリメンタルな検索機能のように使うことができる。Misskeyにおいては検索よりもアンテナのほうが強力なので、なにかに対する言及を追跡したい場合などは検索よりもアンテナを使うほうが有効。

ギャラリー (インスタンス固有)

自インスタンス内に公開可能な画像コレクション機能。

ページ (インスタンス固有)

Wikiのような文章コンテンツ。自インスタンス内の投稿は一覧に表示され、検索することができる。

ゲーム (インスタンス固有)

バブルゲームとリバーシが実装されている。

チャット (インスタンス固有)

インスタンス内のユーザーとやりとりする機能。古いMisskeyではダイレクト投稿をチャットとして表示する機能があるが、新しいMisskeyにあるものはPleromaと同じようなインスタンスに閉じた固有のものである。

さらに公式クライアントもかなり高機能であり、公式でマルチアカウントをサポート(自インスタンス内のみ)。 ビューもデフォルト/クラシック/デッキ(マルチカラム表示)という3モードをサポートしている。

一方でこの機能の多さとAPIが独自であることからMisskeyのサードパーティクライアントはかなり苦労が多いようだ。

Misskeyは日本ではX(Twitter)絡みでバズったことがあり、これにより最大のインスタンスである<misskey.io>{rel=“external”}が非常に有名でユーザー数も多い。 これが、実装であるMisskeyとインスタンスであるmisskey.ioの混同を生じることにもなっている。

また、Misskey自体が大規模なmisskey.ioを見て開発されている側面もあり、小規模インスタンスへの適性はやや低い。

Pleroma

Pleromaは軽量なActivityPub実装である。

Pleromaの基本的な機能はMastodonに準じているが、近年のアップデートで引用投稿、カスタム絵文字リアクションなどをサポートした。 Pleromaの引用/カスタム絵文字リアクションはAkkomaがforkしたより後に追加された機能で、仕様が異なる。

特徴的な機能として「チャット」と「Shoutbox」がある。 どちらもインスタンス内でのコミュニケーションに利用できるものだ。

また、ユーザーに露出しづらい部分であるが、管理機能としてStatusesとMRFというものがあり、これらによってインスタンス内の悪質なユーザーや、ポリシーの異なるインスタンスの投稿に対する防衛能力が高い。

Pleromaの大きな特徴として、「サーバーとクライアントが分離している」ということがある。 ただ、これ自体はSPAを採用している実装は他にもあるし、リポジトリが分かれていることはユーザーにとってのメリットとしては感じにくい。 どちらかといえば重要なのはそれに合わせて「機能におけるクライアントの比重が大きい」ということだ。 例えばミュート機能もクライアント持ちになっている。 基本的には純正クライアントであるPleroma-FEが最も多くの機能が利用できるが、それ以外の機能も含めて機能が利用できるかどうかはクライアントによって大きく異なる。

そのクライアントだが、PleromaにはMastoAPIというMastodon互換APIがあるため、Mastodonアプリが利用できる――――かのように見えるが、実際はPleromaのことを一切考えていないMastodonアプリが動作する可能性はだいぶ低い。 一方、サーバー側はPleroma-FE以外が使われることを前提として想定しており、設定でPleroma-FE以外をデフォルトに設定することもできる。このため、サードパーティアプリをインスタンスの標準クライアントとして提供した場合も比較的親和性が高い。

GoToSocial

GoToSocialは軽量なActivityPub実装である。 一人用、あるいは少人数用にフォーカスし、リソースも運用負荷も小さく設計されている。

特徴的な要素として、サーバーはフロントエンドを提供せず、純正クライアントも存在しないということがある。 その代わりGoToSocialはMastodon互換APIを提供しており、「お好きなMastodonアプリをお使いください」方式となっている。

インスタンス運営者がなんらかのMastodonウェブフロントエンド(例えばElkやPinafore)を提供していればそれをデフォルトのクライアントとして利用することもできるが、こうしたものを用意していなければユーザーが好きなアプリで利用するサーバーになる。

加えて、そもそもが一人用を想定しているサーバーであるため、既存のサーバーに登録して利用するというよりは自分でサーバーを運用するのがメインとなる。

また、GoToSocialは単純にMastodon互換サーバーとして利用できるわけではない。 Mastodonの機能でも実装していないものは多く、単にユーザーがアプリから利用するという面でも、検索やリストがエラーを返すなど違和感を持つ場面は多いだろう。

加えて非常に大きな問題として、GoToSocialはGETであっても署名を強制するが、MisskeyやPleromaはデフォルトではGETに署名をつけないため、多くの非Mastodonインスタンスと連合できないというものがある。 これはGoToSocial側の思想的な要素であり、今後も解消はあまり期待できない。

Fedibird

FedibirdはMastodonのforkであり、非常に多くの機能を追加した多機能なサーバーである。

追加されている機能としては投稿に対しては

• 参照/引用
• カスタム絵文字
• 絵文字リアクション
• カスタム絵文字リアクション
• 公開期間設定
• 投稿単位の検索性設定

などがある。

参照と引用の違いだが、参照はMarkdownの形式で自インスタンス内のURLを埋め込む。 引用はこれに加え、リモートのURLの記載とMisskey互換形式の引用を行う。 これは相手側Misskeyインスタンスに対して通知される。

設定から見える機能は非常に多彩。 しかも、Fedibird固有の機能にはFedibirdというタグがつけられていて識別しやすい。

Akkomaとの間でもうまく疎通でき、完璧ではないが、相互に返信・引用・カスタム絵文字リアクションが認識される。

一方で意図的に消されている機能として、インスタンスのタイムライン(ローカルタイムライン)がある。 このため、Fedibirdは基本的に誰かをフォローして利用するスタイルが前提。

公式インスタンスとして<fedibird.com>{rel=“external”}がある。

Akkoma

AkkomaはPleromaのforkであり、主にMisskeyとの互換性(Misskeyの投稿フォーマットであるMFMへの対応と、カスタム絵文字リアクションのサポート)を進めたもの。 それ以外にも細かい機能を強化・追加している。

現在はAkkomaがPleromaから分岐してからPleroma側がだいぶ変わったこともあり、Pleromaとの差異は意外と大きい。

Pleromaから追加されたものとして引用機能があるが、この引用機能はMisskeyとの間に互換性がない形式である。 ただし、MisskeyはAkkoma形式の引用を理解できるし、AkkoamはMisskey形式の引用を理解できる。 が、Misskeyの引用通知機能は働かない。

また、カスタム絵文字リアクションの仕様もMisskeyと異なり、Misskeyが「いいね」機能であるLikeの拡張であるのに対し、EmojiReactという固有のメッセージを使う仕様になっている。 これもMisskeyとAkkomaはお互いを理解できるものの、EmojiReactをサポートすることをしていないサーバーには無視される(Misskeyの場合は「いいね」扱いになる)という挙動の違いを発生させる。

Pleromaとの差異で言うと、まずAkkomaとしてforkした後にPleromaに搭載された引用とカスタム絵文字リアクションは仕様が違う。 また、絵文字パレットも仕様が違う。

私のAkkomaインスタンスは純正クライアント以外のフロントエンドも利用可能なので、折角であるしそのスクリーンショットを示しておこう。

ActivityPubサーバーによくある概念

タイムライン種別

Xにも「ホームフィード」「フィーチャードフィード」という概念があるが、だいたいのTwitter型ActivityPub SNSはタイムラインに種別を持っている。

ホームタイムライン

フォローしているユーザー(と自分)のタイムライン。 リプライが表示されるかどうかはクライアントと設定による。

サーバーによってはハッシュタグをフォローすることもできる。

ローカルタイムライン

そのインスタンス全体の公開投稿が掲載されるタイムライン。 新し目のMastodonではリアルタイムフィード/このサーバーという名前になっている。

Fediverseへの参加時に接点を広げるポイントでもある。 また、インスタンスの性質によってはローカルタイムラインでのチャットがメインになっているインスタンスもある。

ソーシャルタイムライン

Misskey固有のタイムライン。 ホームタイムラインとローカルタイムラインの合成。

連合タイムライン / グローバルタイムライン

そのインスタンスが取得しているすべての公開投稿が掲載されるタイムライン。

古いMastodon, Pleroma, Akkomaでは連合タイムライン、新しいMastodonではリアルタイムフィード/すべて、Misskeyではグローバルタイムラインと呼ばれている。

基本的にはインスタンス内でリモートインスタンスのユーザーをフォローしていると、そのフォローしているユーザーが投稿したときにサーバーに届くため、取得されることになる。 また、リプライなどそのインスタンスに向けて送られた投稿も取得することになる。 こうしたものの中で可視性が公開であるもののすべてだ。

バブルタイムライン

Akkoma固有のタイムライン。

連合タイムラインの中で、管理者が指定したインスタンスのものを抽出したもの。

リアルタイムフィード/ほかのサーバー

Mastodon固有のタイムライン。 /すべてから自インスタンスを除いたもの。

リスト

指定したユーザーの投稿で構成されるタイムライン。 どの可視性まで含むかは実装による。 おおよそXにあるのと同じ機能。

リストの中に含められるのはサーバーが取得している投稿だけである。 このため、基本的にはフォローのなかからサブセットを作ることになる。 Misskeyはリストに入れたとき代理フォローが可能で、この機能が有効になっていればフォローしていないユーザーのリストでも機能する。

ハッシュタグタイムライン

ハッシュタグのフォロー機能があって、かつハッシュタグのタイムラインが独立するようになっている場合のもの。 MastodonやPleromaにある。

アンテナ

Misskey固有のタイムライン。

サーバーが取得している投稿の中から条件に一致するものが追加されていく。

チャンネル

Misskey固有のタイムライン。

インスタンス固有でトピック分けされた非連合のタイムライン。

CW

Content Warning. ネタバレ防止。

一般的な実装では警告句を表示し、その上で開く動作をしたときに表示されるという振る舞いになる。 このため、投稿時は警告句を書くための欄を伴う。Pleromaなどでは単純に警告句を入れた場合に自動的にCWになるという振る舞いをする。

環境(クライアントまたはサーバー)によってはCWにすることによって添付ファイルにNSFWも付与される。

主に、公開対象のすべての人にとって直接目に触れることが適切でない内容に対して使用する。 配慮手段だが、インスタンスによってはルール化されている。

NSFW

Not Safe For Work. 不適切コンテンツ。

基本的に添付ファイルに対して付与する。 仕様的には添付ファイルごとに付与できるが、実際は投稿ごとの全添付ファイルに対して付与するのが一般的。 また、多くのクライアントは画像に対してしか機能しない。

だいたいの場合はセクシャルなコンテンツに対して付与するが、虫の画像など嫌悪される可能性があるコンテンツ全般に適する。 配慮手段だが、インスタンスによってはルール化されている。

投稿可視性

投稿が誰に見えるか、という設定ができる。 仕様通りであれば、尊重されるはずだ。

公開投稿

公開投稿は、可視性を制限せず、対象となるすべてのタイムライン(例えばローカルタイムライン、フォロワーのホームタイムライン、リスト、他インスタンスの連合タイムライン)に掲載される。

未収載投稿

最近のMastodonでは「ひかえめな公開」、Misskeyでは「ホーム」と呼ばれている。

unlistedな投稿は公開投稿のタイムライン(例えばローカルタイムライン、他インスタンスの連合タイムライン)には掲載されない。 ただし、リストや検索などに載るかどうかは実装による。

多くの場合、ローカルタイムラインへの掲載を避けたい場合に使用する。 また、拡散された場合も基本的には拡散したユーザーのフォロワーに届くことになるため、広がり方がやや抑制される。

フォロワー限定投稿

投稿者のフォロワーのみが見られる限定公開投稿。 未収載と違い、こちらは可視性が明確に制限されており、公開ではない。

引用してしまうと可視性が「引用したユーザーのフォロワー」にすりかわってしまうことから、引用はできないようになっているのが一般的。また、通常は拡散も制限される。

Xの鍵アカウント投稿に相当するものだが、フォローを承認制にしていないと任意のユーザーが「フォローして読む」ことが可能になってしまうので注意。

ダイレクトメッセージ

メンションした相手のみが見られる限定公開投稿。 最近のMisskeyでは送信先は別途選ぶようになっている。 また、最近のMastodonでは「非公開の返信」という呼び方をしている。

一般的なSNSのDMと同じようなものだが、やりとり専用の画面をもっているのは古いMisskeyくらいである。

非連合

外部インスタンスに対して投稿を送信しない。 つまり、たとえフォロワーであっても別のインスタンスのユーザーのタイムラインには載らない。

これは通常の可視性とは異なるレイヤーのものである。

Mastodon, Pleroma, Fedibirdには非連合の投稿という概念がない。

Akkomaは「ローカル」という名称で、可視性は公開、かつ非連合になる。

Misskeyの場合は、可視性とは別に「連合なし」という属性を付与できる。

用語差異

同じ機能でも各実装で呼び方が違ったりする。

Fediverseをはじめる

登録するインスタンスを選ぶ

まずは実装、ルール、運営者、運営ポリシー、運営体制などから自分に合ったインスタンスを選択する。 インスタンスによっては招待制であったり承認制であったりする場合もある。

これら、特に利用規約とインスタンスルールは入念に確認すべきである。 また、利用規約に沿った運営が実際になされているかについても意識したほうがいいかもしれない。 Fediverseインスタンスは個人運営である場合が多く、特に利用規約があまり厳密でないインスタンスは管理者やモデレーターの裁量と判断による運営がなされている場合も多い。

また、ローカルタイムライン重視かどうかというのも重要なところ。 ローカルタイムライン重視のインスタンスはローカルタイムラインの空気が合うかどうかが重要になるし、フォロー関係とのやりとりを中心にしたい場合ローカルタイムライン重視のインスタンスでは公開投稿がインスタンスのノイズになってしまってやりづらいということが発生する。 このあたりは自分の使い方に合わせて選ぶのが良い。

フォロー

ローカルタイムライン重視のインスタンスでは必ずしもフォローは必要ではない。 逆に、ローカルタイムラインが無効なインスタンスではフォローしなければ何も始まらない。

特にリモートユーザーの場合、自分がいるインスタンスの誰もフォローしていないと投稿もユーザー情報もインスタンス内にない状態になるため、そもそも目にする機会すらない。 投稿を読みたいユーザーは積極的にフォローしていこう。 ユーザーをフォローすることで、そのユーザーが拡散したりリプライしている投稿を目にする機会ができ、連鎖的にフォローを増やしていくことができる。

逆に、フォローしたいFediverseがいない状態から始めるのであれば、ローカルタイムラインがあり、比較的ユーザー数の多いインスタンスから始めることで、ローカルタイムラインからフォローするユーザーを発見し、そこからフォローを広げていくことが可能だ。

投稿する

日本人の多くはMastodon, Misskey, Pleromaといったマイクロブログ型のSNSをXのように短文かつ日常的な内容で使っている。一方、日本以外のユーザーはFacebookのように比較的長文で自身の意見や主張を投稿する人が多い。

どのような投稿をするのが良いかは、ある程度空気を読みつつ好きにすれば良い。 ただし、インスタンスのルールは遵守すること。

CWやNSFWに関してはルールで明文化されていることも多いが、基本的に「嫌がる人がそれなりにいそうな内容」であるならばCWにしたほうが安全だし、公共で提示されるのに適さないコンテンツならばNSFWにしたほうが良い。

意識したほうが良いこと

可視性とブロック

まず、ブロックという概念が実装により異なり、絶対に尊重される保証もない、ということを知っておく必要がある。 インスタンス内ならある程度期待するように動くのだが、それでも限定的。Misskeyに至ってはブロックはユーザーが期待するようにはそもそも動かない。

加えて、外部インスタンスの存在がある以上、ブロックというのは実効性はほとんどない。 関係を遮断する表明としてはある程度機能するのだが、Fediverseにおいては「何者かに観測されたくない」という希望を通す方法はないと思っておいたほうが良い。

唯一の方法としては、最初から常にフォローを承認制にし、投稿はフォロワー限定またはダイレクトのみで行うというのがある。 ただし、これもブロックあるいはフォロワー解除¹¹をしたところで過去の投稿は見える状態のままである可能性が高いので過去の分までどうこうしようというのは無理がある。

また、投稿を受け取ったインスタンスがその投稿をどう扱うかは実装依存であり、そもそもインスタンス管理者はダイレクトの投稿であっても見ることができるものなので、Fediverse上での連合されたやりとりに気密性はないものと考えるべきである。

なお、ミュートは自分側で表示しないというだけのものであるため、だいたいの場合望むように機能する。

投稿の保存

Fediverseにおいては、インスタンスに届いた投稿はそのインスタンスが扱えるようにコンテンツを保存する。 このため、一度投稿した内容は基本的に無数のサーバーにコピーが保存され、オリジナル投稿を削除あるいは編集してもその効果は限定的である。

また、フォロワー限定投稿に関しても、基本的にはその投稿が投げられた瞬間にフォロワーであるかどうかだと思ったほうが良い。つまり、フォロワーを解除させても投稿が見えなくなる保証はない。

こうしたことから、投稿を隠す、あるいは取り消すことは中央集権型のSNSよりもずっと難しく、正確でない、ということを意識する必要がある。

実装とルール/文化の違い

外部インスタンスは異なる実装である可能性があり、そのインスタンスに固有の利用規約と文化を持っている。 さらに言えば、ユーザーが使っているアプリによっても挙動が違ったりする。

このため、特にリモートユーザーは不可解なやり方をする可能性があるし、自分が所属するインスタンスでは許されていないような振る舞いをする可能性もある。

だが、実装が異なる以上そういう差異はどうしても出るものだ。 そして、外部インスタンスは外国のようなもの。自インスタンスのルールの遵守を要求することはできない。

こうした違いや不可解さに対しては寛容であり、必要であればミュートする等で自衛する必要がある。 実装による挙動の違いに関しては、寛容な振る舞いをする実装(例えばFedibird)に登録することである程度緩和できるだろう。

対ローカルと対リモート

空リプをする人の投稿が文脈がつかめなくてもやもやする、というようなことはXでも起きることだが、そういうことはしないような人であってもFediverse上ではそうした問題を生じることがある。

というのも、ローカルタイムラインでの会話はチャットに近いため、メンションをつけたりリプライにしたりすることはほとんどない。 会話の流れは公開されているローカルタイムライン上で追えるのだが、リモートのフォロワーにとっては文脈の見えない空リプを延々としているように見えてしまう。

これは避けがたいことなので、そういうものだと認識しておいたほうが良い。 可能であれば、自分がやるときは配慮したい。

ミュートは基本機能

Fediverseの性質上、「見えないようにする」というのは難しく、自分好みのタイムラインを構築するのもコツが必要だ。 そしてもちろん、他の投稿者を制限しようとする考えとは相容れない。

だからこそ、Fediverse上ではミュートは重要な機能であり、ミュートによる選別は当然行うべきことであるとみなされる。

人に文句を言う前にミュートで自衛する。それがFediverseでの暮らし方だ。

投稿の見られやすさ

「あなたがインスタンスAにいて、インスタンスBのユーザーXの投稿に反応したとき、インスタンスCにいるXのフォロワーにどう見えるか」というような意識が若干必要になる。

基本的には最も取得されやすいのは固定投稿(ピン留めした投稿)である。 というより、インスタンスが新規ユーザーを認識したときに取得されるのは固定投稿だけなので、固定投稿はとても重要。 自己紹介など自身を表現するのに適した投稿を固定しておくと良いだろう。

固定できる数はインスタンスによって異なる。 数多く固定することが可能なインスタンスもあるが、非常に強いノイズになるため嫌がるユーザーもあるし、インスタンスが受け入れる固定投稿の数に上限があったりもするから、ほどほどにしておこう。 安全な数は1である。

そして強いのが返信である。 返信は投稿を取得するとき、投稿に対する返信として一緒に取得される。 自分からできるアクションとして露出機会を増やすには、投稿がほとんど唯一の手段。 あとは拡散される機会を増やすくらいしかない。

対して、引用はそもそも引用の扱いが実装によって異なり、表示されなかったり取得されなかったりということが起きるのでXほど積極的な効果を持たない。 Soapboxなどは引用をリプライの形で行うため見えやすいが、これを嫌うユーザーも少なくない。

なので、返信と拡散(ブースト/リノート/リピート)を中心に使っていくといいだろう。 とはいえ、自分の露出を増やすために関わりのない人にむやみに返信するようなことは当然避けよう。

向いている人/向いていない人

Fediverseに向いているのは、

• いろんな違いに寛容でいられる
• 「きっとそういうものなんだろう」で納得できる
• ミュートでの自衛など「自分がとれる選択肢」で制御することができる
• 人とはゆるくつながりたい

一方向いていないのは

• 他者に自分が望む通りの振る舞いをしてほしい
• 異なる流儀、挙動、あるいは不可解な振る舞いが許せない
• 「自分がいるのとは違う環境やルールがある」ということが認識できない
• 自分の投稿が見える範囲を厳密に制御したい
• 自分の投稿がインターネット上に残り続けることが許容できない
• 自分が望む限られた人とだけ交流したい
• 利用規約を読み、それに従って行動することができない

という人である。

余談: 運用者観点の実装に対する印象

私が現状本番運用しているのはAkkomaとMisskey、検証運用しているのはPleroma, Pixelfed, Peertubeだが、Pleroma/Akkoma/Misskeyに関して言うと、まずPleromaとAkkomaで言うのならばAkkomaが良い。

そもそもはPleromaに引用がないことが私の要件を満たさなかったという問題があってのことだが、現在に至ってもPleromaは「ちょっとそれは⋯⋯」という仕様が多い。 AkkomaはCWのon/off機能であったり、リンクの認証機能だったり、絵文字パレットの使いやすさであったり、細かいところを含めてPleromaよりも使いやすく、ここに慣れてしまうとPleromaを使ったときに「あれっ」となりやすい。

そしてAkkomaとMisskeyで言うと、基本的には運用安定性はAkkomaのほうが優れているし、リソース消費もAkkomaのほうが少ない。 他にも、カスタム絵文字を追加する手間がAkkomaのほうが圧倒的に小さい、自インスタンスの投稿をリストする管理機能がある、MRFが非常に強力で防衛しやすいといった理由で運用負荷は比較にならないほどAkkomaが小さい。

だが、Akkomaは「なんで発生しているのかわからない」類の動作不良が比較的多く、外部から投稿が取れないみたいなことが割とよくある。 あと、稀にキューワーカー(Oban)を手動で面倒を見てあげないといけないことがある。

対して、運用を始めたころはMisskeyはかなり不安定で手間のかかる子だったが、最近はほとんど放置で問題が発生しないくらい安定しており、意味不明な挙動に悩まされることも非常に少ないので、最近はかなり良い実装に感じている。

環境に対する敏感さは似たようなものなのだが、MisskeyはTypeScriptで書かれていてnvmで環境を固定できるため、Misskeyのほうが楽。 Akkomaのほうが問題になる頻度自体は少ないのだが、ホストネイティブ環境になっているとErlang&Elixirの環境を固定する方法がasdfとかになってしまうのでなかなかしんどい。

インスタンス管理業務に関しては前述した通りAkkomaのStatuses(投稿一覧)とMRFが極めて強力なのでAKkomaのほうが楽なのだが、webhook機能やコミュニティ関連機能などMisskey固有の良いところもある。 Misskeyの、「管理アカウントで公式クライアントにログインする」というのを定期的にしないと登録がオフになってしまうのは設定できるようにしてほしいと思っている。

おまけ: 私が管理する公開登録のインスタンス

• 宇宙庭園
• Cafe&bar Stellanaut

宇宙庭園は一般用途/メインアカウント向けのAkkomaインスタンスである。 「テキストでの会話・発信」をメインに据えており、メディア投稿やリピートに対してやや制限がある。

非常に珍しい要素として複数のウェブフロントエンドを持つAkkomaインスタンスであり、Soapbox, Mangane, Enafore, Glitch Lilyが用意されている。 過去にはElkやKenomaもテストされていた。

Cafe&bar Stellanautはローカル向けのMisskeyインスタンスである。 「お上品な振る舞い」を強く要求しており、荒れ狂うFediverseの世界に疲れたときに立ち寄るのに適している。

どちらもしっかりとした運営を強みにしている。 ルールも明確・厳密だ。