Mastodon
読み:ますとどん
外語:Mastodon

 オープンソースによるインスタントメッセンジャーマイクロブログサービスを提供する実装の一つで、Fediverseによるソーシャルネットワークを実現する手段の一つ。
目次

概要

標準技術で作られたTwitterの後継
 標準化団体によって定められた標準的な通信プロトコルを用いた「Twitterの後継」を、オープンソースかつ分散型として実現させようとする実装である。
 サーバー間の通信プロトコルは、W3C勧告のオープン標準、ActivityPubを採用している。
 Mastodon世界には、全体のルールのようなものはない。ルールは、各サーバー(インスタンス)ごとに決められ、その各サーバーを繋ぐことで、分散型SNSを実用化したことが大きなブレークスルーとなっている。
 また仮にどこかのサーバーが都合により運営終了となったとしても、他のサーバーに引っ越すことは可能で、Mastodonというシステム(より正しくはActivityPubプロトコルにより提供されるネットワークシステム)は末永く維持されるため、末永く使い続けることができる。

目的
 Twitterの場合は、Twitter社のサーバーで全てをやりとりする。言い換えれば、Twitter社のサーバーにアクセスしなければ友達と話すことができない。しかしながら、Twitter社は政治的にも思想的にも非常に偏った存在であり、極めて不健全な運用を公然と実施している。このような存在を情報発信の基盤とすることは安全ではなく、望ましくもない。
 そこで誕生した考え方がFediverse(フェディバース)である。Fediverseとは、マイクロブログサービスをそれぞれインターネットで繋いで連合させ、サーバーを超えた友達と話せる機能を実現するものである。
 つまり、企業なら各社ごと、省庁なら各省庁ごと、政治家なら各人または各政党ごと、優れた技術者やサーバー運用できる人ならその個人ごとにそれぞれサーバーを用意して運用し、そこにユーザー登録されたアカウントから情報を発信しつつ、それぞれのサーバーをインターネットで繋いで(電子メールがそうであるように)異なるサービス間でも相互に交信できるようにした。サーバーは一極集中のTwitterのような大規模なものは必要なく、その利用者の数に応じた小規模なもので充分であり、このため運用費用もそれほど高額になることはない。情報は分散されることによって一極集中の弊害をなくすことができ、なおかつ検閲にも強くなる。そういったFediverseの考えに基づいたものの一つが、Mastodonである。
 こうした場合、サーバーの運用はそのサーバーを管理する人の意向とその国の法律に従う。Twitter社のような反社会的組織の都合に合わせる必要はなくなる。
 結果として、自由に、そして情報発信したい人の考えが検閲されることなく、全世界にそれを発信したり全世界から受信したりできる。

由来
 2017(平成29)年6月7日、Interop Tokyo 2017のトップを飾ったMastodonの作者オイゲン・ロッコ氏の基調演説で、現在のSNSの現状と、その打開策として作られたMastodonとは何なのか、について端的に語られた。意訳で、次のような内容である。
 何年か前に、友人から連合(federated)ネットワークのアイディアを聞いていた。その時はピンと来なかったものの、2016(平成28)年5月あたりからTwitterは些細ではあるが不人気な仕様変更を始めて、以降は誤った判断を下し続けていた。そんな折に以前聞いていたアイディアを思い出して、GNU socialを発見した。
 当時はGNU socialへのコントリビュートもしていたが、コードを読んでいるうち、自分でも書いてみたくなった。「Twitterのようなもの」を、「ユーザーの手に取り戻したく」なった。ユーザーインターフェイスはTweetDeckに似せることにした。
 Mastodonを作るにあたりTwitterが失敗した原因を考えたところ、それはTwitterだけが悪いわけではなく、それが営利企業であり、かつまた中央集権的な会社なためだと結論づけた。そして、広告の方法やマネタイズについても運営企業とユーザーとの間には考え方への隔たりが大きい。
 そこで、脱中央集権的な仕組みにしてみようと考えた。Twitterには巨大なデータセンターが必要だが、Mastodonなら(一つのインスタンスに)1・2台のサーバーがあれば充分だ。
 コミュニティー内のルールも自分たちで決められる。日本にいるのにシリコンバレーのルールに縛られる必要はない。それは(自分の住む)ドイツや、英国などでも同様だ。
 理路整然とした分かり易い内容で、確固たる信念に基づいて作られていることも分かる。
 「Twitterの運営がおかしい」→「GNU socialがあった」→(ソースを見て)「自分でも作ってみよう」を切っ掛けとし、次に目的として「Twitterのようなものをユーザーに取り戻そう」となり、それを達するための方法を検討し、なぜTwitterがおかしくなったかを分析し、中央集権的でシリコンバレーのルールを無理に全世界に適用させているためだとの結論に至る。
 これらの問題を解決するため、脱中央集権的な仕組みにし、ルールも各々のサーバーで決めれるようにする。こうして、分散型SNSとしてのMastodonの方向性は決まり、そして実用化されたのである。

機能

個別の閲覧制限
 Mastodonは、各投稿(トゥート)ごとに細かく閲覧制限を設定できる。
 18歳未満の閲覧に不適であったり、飯テロ画像の自粛などの場合、閲覧までにワンクッション置く機能がNFSWである。簡単な注意文を記載できるCWと併用もできる。
 公開範囲については詳細後述。

ディレクトリ
 Mastodon 2.7から導入され、この当時は専用画面で表示できた。設定で「ディレクトリに掲載する」をONし、なおかつ10人以上のフォロワーを持つユーザーに限られており、このためあまり役に立っていなかった。ハッシュタグでユーザーを絞り込む機能も存在した。
 Mastodon 3.0からは大きく仕様変更された。「ディレクトリに掲載する」をONしたユーザーという条件は同様だがフォロワー人数の制限は撤廃された。既知の連合から得られたユーザー(一般的には、そのサーバーのユーザーにリモートフォローされているユーザー)の情報も合わせて表示可能になり、タイムラインと同様にペイン内に情報が表示できるようになった。ハッシュタグでユーザーを絞り込む機能は廃止された。

由来と沿革

作者
 開発者はドイツ人のEugen Rochko(オイゲン・ロチコ)。
 アカウントは@Gargron@mastodon.socialである。

開発
 Mastodonはプログラミング言語としてはRubyで書かれており、WebアプリケーションフレームワークとしてRuby on Railsが使われている。
 国際的な共同開発のためにGitHubが使われており、Mastodonのリポジトリmastodon/mastodon/である。
 ライセンスはAGPLで、誰でもダウンロードして無料で使うことができる。但しAGPLなので、改造した部分はGitHub等で公開する必要がある。

大きな動き

Twitterの問題
 これまで、マイクロブログサービスはTwitterにほぼ一極集中していた。
 それでもあまり困ることはなかったが、ただ、Twitter社の恣意的な運用、大反対を押し切ってのシステム改悪の強行、独自クライアントの規制、内容を確認もせずに機械的にアカウントの規制や凍結をする、その際に利用者が同じ別アカウントにまで規制を掛けるなど、サービスは不便になる一方で改善は何もなく、運営とユーザーとの乖離は日に日に激しさを増していった。
 なぜなら、ユーザーはFacebookやInstagramではない世界を求めていたにもかかわらず、運営はFacebookやInstagramになりたがっていたからである。理由は簡単で、Twitter運営はTwitter「なんか」は使っておらず、日々Facebookを使っているからである。これでTwitterが良くなるはずはなく、当然Twitterはどんどん劣化していった。
 そして2018(平成30)年8月にはUser Streams APIを停止させ、さらに独自クライアントの作者に膨大な額の金銭を要求したことから、Twitterで独自アプリを作っていた作者らのうち個人レベルでの開発者らはMastodonへと移住することになった。また2023(令和5)年1月19日には完全な排除を実施したため、企業レベルでの開発者らもMastodonへと移住することになった。

Mastodonの普及
 遡ることMastodon誕生前、Twitterは運営が愚かであり大赤字のまま改善の見込みもなく、にもかかわらず利用者に敵意をむき出しにしていた。この泥船Twitterからの脱出先となる「代わり」も渇望されるようになってきた。
 これまでは、Twitter社の一存によって投稿は容易に削除、改変、監視などの検閲を受けていた。後からのルール変更で、ルール変更前の投稿にまでけちを付けてはアカウントをロックするなど、法の不遡及つまり事後立法を無視した中世のような支配を実施するに至った。
 もはや使い物にならなくなったTwitterであるが、しかしこれは代わりに別の会社が同様のサービスを始めたとしても状況は変わらない(検閲は受け続ける)ということを意味していた。これに対抗するには、利用者全員がサーバーを持ち、互いを連携すれば良い。しかし現在は、IPv4アドレスの枯渇、NATなどの技術的事情や、セキュリティ、および日本の法規制などにより、サーバーを設置することは難易度が高い。つまり、サーバー運用にはコストが掛かり、かつ高度なスキルも必要になる。それでも、出来る人から始めれば良いということでMastodonが開発された。
 これは、Web 3.0の流れでもあり、今後ますますこの流れに進んでいくものと思われる。

日本での流行
 こうしてMastodonは日本で大流行し普及した。
 日本だけでも膨大な数のサーバーと会員数があるが、これだけで本家(mastodon.social)の規模を軽く超えてしまっていることからも分かるように、日本以外では当初はそれほど流行ってはいなかった。
 ただ、これは別に問題ではない。Twitterも全利用者中に占める日本人の割合はかなり高いし、そのTwitterですら日本人が会話する相手はほぼ100%日本人なのである。かつ、別に日本国内で閉じているわけではなく世界にも広がっているのはどちらも変わらないのだから、将来的に海外でもMastodonが普及すれば問題は自ずと解決されるのである。
 実際、Twitterがイーロン・マスクの手に落ちてからは英語圏などでもMastodonへの大規模な移住が始まり、無事にイーロン・マスクが敵視する最強のライバルの座を掴み取った。

投稿の傾向と変遷
 Mastodonでは、殆どのサーバーで、政治的なトゥートは好まれないことが多い。
 ノンポリしかいないという訳ではなく、本人の思想の左右を問わず政治的なトゥートはあまりしないということである。そういった話題は基本的に揉めること、Twitterでのそういった「戦い」に疲れた人が移住する傾向にあるためだろうが、理由は不明である。
 結果、政治家の名前や政治的な単語をミュートしている人が多かったり、政治的な話はCWで隠している事が多い。これは日本に限らず、海外でも同様の傾向である。但し、昨今ではTwitterの終焉もあって、Twitterに愛想を尽かしてMastodonに移り住んだ保守派またはパヨクの流入も多くあり、以前よりは政治トゥートの流量も増えているようで、さらには保パともに政治を主に据えたサーバーも増えてきた。

特徴

良さ
 他のSNSの失敗から学び、SNSが誤った使われ方をされることがないような設計が目指されている。
 また、他のSNSにある理不尽な制限も改良されている。
 SNSとしての改善点は別に後述する。

用語
 用語はサーバーごとに変更可能なため、サーバーによっては雰囲気に合わせて変更していることがある。
 例えば、friends.nico(既に閉鎖)ではお気に入りを「ニコる」と呼んでいたり、ますとどんちほーではトゥートが「がおー」、ブーストが「たーのしー」、お気に入りが「すごーい」など、けものフレンズの用語(先の3つはサーバルちゃんのセリフ)に置き換えられているなど、サーバーごとに特色を持たせていることがある。

投稿

トゥート
 Twitterの場合は「ツイート」(ぶつやき)であるが、Mastodonの場合は「トゥート」(吠える)で投稿する。
 これは、Twitterのマスコットが鳥であるのに対して、Mastodonは象やマンモスに似た古代生物Mastodonなためと思われる。
 ただ開発陣による、普及のためにより一般的な用語を使用するという新たな方針によって、Mastodon 4.0以降では標準が「投稿」(Publish)に変更されている。
 また、次に説明する返信(リプライ)ではない、相手先を指定した投稿を「メンション」という。

返信
 ある人の「吠え」に対して、「吠え」で返信することも出来る。返信は、英語でReplyであるためカタカナで「リプライ」とも呼ばれる。
 返信する元の「吠え」を指定して操作するか、相手のプロフィールからも送信できる。画面上には、原則として元発言者のユーザー名が、自サーバー内であれば「@username」の形式で、他サーバー内であれば「@username@servername」の形式で表示される。
 返信は、未収載(後述)の扱いとなり、ローカルタイムラインにも連合タイムラインにも表示されない。

公開範囲
 MastodonにもTwitterと同様にダイレクトメッセージ機能があるがより高性能で、これをトゥートごとに細かく設定ができるようになっている。
種類機能範囲
連合TLローカルTL非フォロワーフォロワー指定アカ
公開誰でも閲覧可能
未収載誰でも閲覧可能、TLには流れない××
非公開フォロワーのみ閲覧可能×××
ダイレクト指定ユーザーのみ閲覧可能××××
 これを著している時点では、ローカルTLに限定したトゥートをする機能は公式には実装されていない(改造されたサーバーでは可能なことがある)。
 ダイレクトメールは独立した機能ではなく「相手にしか見えないリプライ」という構造で実現されている。従ってセキュアではないので、利用には注意が必要である。

分散型SNS

分散について
 Mastodonは分散型SNSである。Mastodonと呼ばれるシステムが動くサーバーが世界中に無数にあり、それぞれが緩く連携している。
 こういった仕組みをFediverse(フェディバース)という。詳細はそちらを参照のこと。

サーバー(インスタンス)
 Mastodonが実際に動作するコンピューターをサーバーという。以前は「インスタンス」と呼んでいたが、開発陣による、普及のためにより一般的な用語を使用するという新たな方針によってサーバーに変更された。
 サーバー(インスタンス)は幾つあってもよい。
 分散型とはいえ基本的にはサーバー内に閉じていて、必要に応じて外部に転送する仕組みになっている。従って、特定の趣向に合わせてサーバーを作るのが理想的であり、実際にそのようにサーバーは林立している。
 Twitterでも、「クラスター」という目に見えないしシステムにすらもない狭い範囲内でフォローし合い交流し、時々クラスター外の有名人をフォローしたりするのが一般的である。Mastodonの場合、このクラスターごとに本当にサーバーを分けた、と表現できる。つまり、Twitterでいうクラスターが、Mastodonでいうサーバーである。
 そして、サーバー間を相互に通信プロトコルで繋ぐことで、異なるサーバー間での通信を可能としている。これが「分散型SNS」である。
 ローカルタイムラインの雰囲気は重要な要素であるため、Mastodonを使いたい人は、自分が気に入ったサーバーに入会しアカウントを作って使うことになる。

サーバー間通信
 誰からもフォローされていないアカウントがトゥートしても、おそらくそれはそのサーバーに留まり、外へは流れない。しかしリモートフォローなど特定の条件を満たすと、そのトゥートは他のサーバーにも転送される。この手法によってサーバー間での交信が可能となる。
 こうして、そのサーバー内でのタイムラインは「ローカルライムライン」、リモートフォローなどによって他のサーバーから受信したトゥートも込みのタイムラインは「連合タイムライン」として、分けて表示されている。

連合
 ローカルタイムラインに加え、他のサーバーの一部ユーザーも見えるのが連合タイムラインであるが、ではこの連合とは何でありどのような仕組みなのか。
 MastodonはMastodonは脱中央集権を目指しているため、どこかに中央サーバーがあってそこで各サーバーの情報が交換されていたりするわけではない。Mastodonはサーバーを超えたフォローをすることができるが、このフォロー行為のみによってゆるい「連合」が形成される。
 自分の投稿や自分がブーストした投稿は、自分をフォローしている人に配信される。それが他のサーバーであれば、他のサーバーにその投稿が届く。こうして集まってきた他のサーバーの投稿とローカルタイムラインを足したものが連合タイムラインである。
 もう少し簡単に言うと、そのサーバーにいる全ユーザー、およびその全ユーザーがフォローしている他のサーバーのユーザーのトゥートのうち、公開範囲が「公開」になっているもの全てが流れていくタイムライン。それが連合タイムラインである。
 Mastodonにある「トレンドタグ」機能などはこの連合タイムラインから生成されるが、一箇所に全てを押し込むTwitterは違い必然的に対象となるトゥートの範囲が限られるために、狭い範囲内での「内輪ネタ」ばかり入ることになるために、あまりおもしろい結果にはならない。故にサーバーによっては管理人の意向によりトレンドタグ機能がOFFにされていることも珍しくない。

他のサーバーの投稿へのアクセス
 Fediverseは、投稿の大本は大本のサーバーにあるが、それは全世界に隈なく配信されるわけではない。
 他のサーバーに気に入ったアカウントがあってフォローしたとしても、自分のサーバーにそのアカウントの投稿が届いてるとは限らず、届いていない場合はリブートもお気に入りの追加もできない。その場合、その投稿のURLをまず得る。
 それがMastodonでもMisskeyでも、大抵は「●●時間前」などの表示のリンク先が投稿のURLであるので、それをクリップボードにコピーする。
 次に、検索機能でそのURLを入力して検索する。すると、その投稿が自分のサーバーに読み込まれる。それに対し、リブートやお気に入りの追加をすることができる。

どのサーバーを使うか
 既にあるサーバーを使わせてもらってもよいし、自分でサーバーを立てることもできる。この辺りの詳細はFediverse(フェディバース)の項を参照のこと。
 別に何ヶ所のサーバーに登録しても良く、用途に応じて分けるのが理想的である。専用クライアントソフトでは複数のアカウントを管理できるものが一般的なため、必要なだけアカウントを作って適当に使って安住のサーバーを選ぶのが現実的である。
 あまりアカウントを増やさずやりたいという場合は、どこか一つないし少数に絞る必要が出てくる。
 日本での主流サーバーは数ヶ所で、それ以外は過疎である。ただ考える必要があるのは、人が多く賑やだからといって自分の趣味趣向に合う人が多いとも限らないこと。人は少ないが他の小規模な専門サーバーの方が趣味に合う人が多く話が弾む可能性もある。結局のところ、どのサーバーを使うか(≒どのクラスターに属するか)悩むというのが、Mastodonにおける一番の問題であると言え、これをどのように解消するかが今後の課題だろう。
 サーバーによって住人は違うので、自分の肌にあったところを使えば良い。但し、事前にローカルタイムラインを確認できないサーバーも多い。

主なサーバー
 サーバー(インスタンス)の一覧をまとめているWebサイトは幾つかある。
 日本のサーバーは「マストドン日本語ウィキ」などに情報が多い。
 サーバーは膨大な数あるため、信頼でき、趣味に合うものを任意に選択すればよい。

現行サーバー(日本人向け・日本人も利用可能)

現行サーバー(その他)

過去のサーバー
 閉鎖されたもの。

分散型SNSという弱点
 Mastodonは分散型SNSであることが利点であり特徴だが、それ自体が弱点でもある。
 分散型SNSは、中央集権がない代わりに、そのアカウントが本人である保証をする機関を作れない。つまり「なりすまし」が容易である。技術的にこれが解決できるのかどうかは未知数である。
 ただこれはあくまでメカニズムの問題であり、例えば企業が自社ドメインでMastodonサーバーを運用するなら、それは真正性を保証するという点においては何にも勝っており、MastodonはTwitterより優れているとも言える。待てど暮らせどもらえないTwitterの認証マークより、企業ドメインのサーバーのアカウントから発信する方が早いし信頼性も高い。
 また後述するが、個人レベルでも権威を利用しない認証を含め、いくつかの認証が実装された。

SNSとしての改善点

過去を検索しての炎上の排除
 Mastodonは、本文検索機能は公式には搭載されていない。機能自体はあるが、標準では無効化されている。これは意図的に機能が封じられているためである。
 Twitterでは、過去のツイートを漁って晒し炎上するような事件が稀によく発生していたが、こういったトラブルをなくすため、Mastodonでは標準では検索機能を有効にしていない。タグ検索機能はあるため、必要なものはタグを付けてトゥートすれば後からでも検索できる。
 ただし、トゥート自体は公開情報なのでこれをまとめて検索機能を提供するサービスは存在し、かつてあったアプリTootdonでは独自にトゥートを収集してのトゥート検索やタイムライン生成を可能としていた。

人気コンテストの排除
 Twitterでは、ツイートのリプライ数、リツイート数、ふぁぼ数などが表示されるだけでなく、いつの頃からかこれがリアルタイムに反映されるような機能まで搭載された。Mastodonへの移住が盛んになった2022(令和4)年12月には、承認欲求モンスターの繋ぎ留めのためか、表示数まで表示されるようになった。Twitterはツイートの人気コンテストを公式に支援、というよりむしろ積極的に「煽って」いるということになる。
 しかしこれは、特定のツイートをひいきしたりするもので、必ずしも健全とは言い切れない。なぜなら、同じような内容の投稿は多数の人がしている可能性があり、情報価値として等しいならそれらは平等に扱われてしかるべきであるし、そうでなくとも良い投稿は人気の有無にかかわらず良いものとして評価されるべきである。
 そこでMastodonでは、こういった人気コンテストを公式には「しない」方針とした。3種類あるタイムラインでは、いずれもブースト数、ふぁぼ数は共に表示されない。バージョン2.5.0以降ではリプライ数は出るようになったが、0、1、1+の3種類しかない。リプライ数によって人気コンテスト(人気のバロメータ指数)になることを避けるため、0か1か1より多いかしか表示しない方針になっている。
 但しこれはWeb UIの表示コンセプトであり、リプライ数/ブースト数/ふぁぼ数は公開情報なので、対応するMastodon用クライアントを使えば全て表示することができる。

認証に権威を排除
 そのSNSのアカウントが「本物」なのか「偽物」なのかを判断することは、とても難しい。
 Twitterの場合はTwitter社が真贋を判断し、本物には「公式マーク」を与える権威となっているが、Mastodonでそれを実現することは難しい。真贋を判断する権威はないからである。
 仮にMastodon開発者であるEugen Rochko(オイゲン・ロチコ)氏らが真贋を判断するようなシステムにしてしまうと、Mastodon全体がオイゲン氏らなしでは活動できなくなり、オイゲン氏らを中心とした中央集権SNSになってしまう。これはMastodonの思想に反するものである。
 サーバー管理人にその権限を与えても上手くは行かない。あるサーバーで「公式」があったとしても、他のサーバーで偽物が大量発生する可能性はあるし、自分でサーバーを建てて自分で自分を認証してしまえば偽物が公式マークを持つことが可能になってしまう。
 初期にはいわゆる「お一人様」サーバーを運用するのが最も現実的な公式の表明であったが、Mastodon 2.6からはプロフィールから認証が可能になった。
 使い方は簡単で、自サイトにMastodonアカウントへのリンクを付け、その際にrel="me"属性を付けておく。その後、Mastodonのプロフィール画面にその自サイトのURLを書き保存すれば、その部分が緑色に囲まれて表示される。真贋の証明と言うにはやや大げさで、相互リンクされていることを表わすに過ぎないが、この仕組みはMastodonの思想をよく表わしていると言える。
 プロフィールにURLを書けるのは本人だけであるし、自サイトにMastodonへのリンクを付けられるのも本人だけであるので、相互リンクされているということは、両者は同一人物が実施したという証明になる。
 またMastodonで複数のサーバーにアカウントがある場合も、相互のURLを書いておけば、それぞれ認証され緑色で囲まれる機能もある。
 リンク元となるWwbサイトやブログ等まで偽物を用意されたら意味が無いとは言えるが、個人で可能な範囲での認証はこれでも充分なレベルで実現できるだろう。

認証に権威も採用
 Mastodon 2.8.0からは、SNSなどと連携できる公開鍵基盤Keybaseによる認証にも対応した。
 利用しているサーバーの運営がまず対応する必要があるが、それが済めば、そのサーバーでKeybaseの認証が可能になる。
 ただしこの機能も、利用者が少なかったらしくMastodon 3.4頃にいつの間にか機能が削除された。

長文は畳む
 Mastodonは500文字まで投稿できることが特徴であるが、これはMastodon独自の仕様であり、使用しているActivityPubプロトコルの制限というわけではない。このため他のActivityPub実装や、あるいはMastodonでも改造されたサーバーではそれを超える長文を投稿できる場所もある。
 そこでMastodonでは、500文字または指定された文字数を超える投稿は自動で畳まれ、「続きを読む」をクリックすると全文表示される仕様となった。

技術

通信プロトコル
 Mastodonは、StatusNetからGNU socialへ続くオープンソースSNSの流れを汲んでいる。
 バージョン1.5までのサーバー間の通信プロトコルはGNU social(旧StatusNet)と同じOStatus、バージョン1.6以降は新プロトコルActivityPubが採用された。これらはともにW3C勧告であり、仕様が公開されている。また文字の符号化にUTF-8を用いているため言語の縛りもない。
 投稿は各サーバーごとのWebサイトからの他に、公開されたAPIを用いた様々なアプリケーションから可能となっている。
 APIは、Twitterと同様にRESTが採用されており、OAuth 2.0で認証をする。

RSSフィード
 MastodonはトゥートをRSSのメタデータとして取得することができる。RSS 2.0形式に対応している。従来はatom形式にも対応していた。
 具体的には、次のどちらかのURLで、RSS 2.0形式のフィードを得ることができる。
 従来はrssの代わりにatomとするとatom形式を得られていたが、Mastodon 3.0から廃止された。
 例えばMastodonの公式アカウント@Mastodon@mastodon.socialなら、RSSを得るURLは https://mastodon.social/users/Mastodon.rss などということになる。
 RSSリーダーで読むこともできるし、得たフィードをTwitterに転送するプログラムを用意すれば、まだオワコン(Twitter)に残っている人たちにもトゥートを見えるようにして移行を促す切っ掛け作りにもできるだろう。

オープンソース
 オープンソースなので改造も可能である。各サーバーごとに、独自の色を出すことができる。そういったサーバーを利用するかどうかは、その管理人の信頼性を確認する必要がある。
 改造にも様々あるが、例えばLaTeXで数式を書けるmathtod.onlineのようなサーバーがある。
 なお、MastodonのライセンスはAGPLなので、改造したサーバーを運用する場合はその改造部分を公開せねばならない。そのため、この改造が本家に取り込まれ仕様となったものもある。

バージョン
 更新履歴はGithubのtootsuite/mastodon/releasesにある。
 バグ修正以外の仕様変更点などを記載。日付は原則として現地時間。

技術的な欠点など
 MastodonはTwitterより優れているが、欠点がないわけではない。バージョンアップによって、欠点の幾つかは改良されている。

OStatusという欠点(改良済)
 Mastodonは、バージョン1.5まではOStatusというプロトコルを用いていた。これは、かつてのStatusNet(現在のGNU social)が提唱したマイクロブログの更新通知のためのプロトコルである。
 GNU socialの前身であるStatusNetは2010(平成22)年より開発が始まったが、主流にはならなかった。Mastodonはその主流になれなかった実装が用いたものと同じプロトコルを用いていたことになる。
 Mastodon 1.6.0rc1からは新しいプロトコルActivityPubが採用され、Mastodon 3.0でOStatus対応が廃止された。
 この動きに対応するため、GNU socialもActivityPub採用が進められることになった。

Ruby on Railsという欠点
 利用面での問題点は、StatusNetがPHP、MastodonはRuby on Railsで実装されており、このため運用にはWebサーバーの運用と同等レベル以上のスキルが必要となるため敷居が高い点である。
 そうなると、個人で気軽にサーバーを運用することは難しく、誰かが運用しているサーバーを使わせて貰う、というTwitterと同様の手順に至ることになる。ここでの問題点は、そのサーバーの運用者が不正を働こうとすれば簡単にできるということである。例えば、その管理者はメールアドレスとパスワードのペアを大量に入手し、それで不正を働くことも簡単ということである。従って、身元不明サーバーのMastodonは絶対に使ってはならない。

改善の方法
 それ以外にも、細かな欠点と思う部分は、利用者それぞれが思うことがあるかもしれない。Mastodonはオープンソースなので、不満があれば自分が開発に参加できる点がTwitterとの大きな違いであると言える。しかし問題点を技術的に改善するのは難しいことが多い。
 遡ることMastodonから約10年、2003(平成15)年頃には既に、Winnyのネットワークを使ったWinnyBBSなどが試みられていた。データはP2Pメッシュネットワークに点在しているため力による検閲には強いという利点はあったが、弱点も多々あった。
 Winnyに限らず、当時のP2Pメッシュネットワーク実装はどれも非公開のプロトコルとソフトウェア実装となっており、自由度が低く、このため普及もしなかったのである。
 Mastodonはオープンソースでありプロトコルも公開されているため、実装自体は第三者による改良も期待はできるものの、各サーバー(≒ノード)の信頼性を担保することまではできず、持つ欠点はP2Pメッシュネットワーク実装の時代とあまり変わっていない。

補足

「Mastodon陣営」という表現
 Mastodonは、Eugen Rochko(オイゲン・ロチコ)氏以下ボランティアによって開発されているソフトウェアである。オイゲン氏も、その法人Mastodon gGmbH.(joinmastodon)も、個人的な「声明」を表明することはある。
 その際に報道では「Mastodon陣営」などの表現が使われることがある。
 外部からは分かりづらいのは事実であるし、joinmastodonの態度も紛らわしい部分があるのも事実であり誤解されても無理はないが、しかしFediverseのためのシステムであるMastodonにおいて、「Mastodon陣営」というものは、非常に成立しにくい概念である。その理由を次に述べる。

FediverseとMastodon
  1. Fediverseは、独立性を保ったまま(インターネット等で)相互接続されたサーバー群である。
  2. ActivityPubは、Fediverseに使われるプロトコルの一つである。
  3. Mastodonは、AGPLでライセンスされたソフトウェアの一つである。
  4. joinmastodonおよびMastodon gGmbHは、Mastodonの開発元である。
  5. Mastodon gGmbHは、独自のブランドを守るためにMastodonの商標やロゴ、公式サイトなどを保持しているが、各サーバーの運営には介入できない。
  6. Mastodonを使って運用されている各サーバーは、独立性を保ったサーバーである。joinmastodonとも独立している。
  7. 各サーバーは通信プロトコルによって相互接続し、またMastodonのAGPLライセンスを守っているが、他に制約を受けない自由な存在である。
 以上のように、Mastodonは自由に使えるように配布されているソフトウェアでしかなく、それを使って運用されるサーバーの運営には開発メンバーでも介入しないし、できない。
 また同様に、ある日突然誰かが何かしらのMastodon関係の団体を立ち上げたとしてもそれがMastodon全体に影響を及ぼすようなことはない。

開発に携わっている人たち
 Mastodonの開発者、翻訳者などの貢献者は、GitHubにあるmastodon/mastodonリポジトリに、ソースコード一緒にAUTHORS.mdというファイルにまとめられている。
 https://github.com/mastodon/mastodon/blob/main/AUTHORS.md
 軽く流して見るだけでも膨大な人たちが関わっていることが分かる。
 貢献者つまりプログラムを書いている人たち(ソースコードにコミットしている人たち)については、GitHubの情報でより詳細に把握できる。
 https://github.com/mastodon/mastodon/graphs/contributors
 botは省くとして、上位10人を挙げると、Gargron(Eugen)氏、ClearlyClaire氏の二名がコアメンバーであり、ここにykzts氏、akihikodaki氏、mjankowski氏、unarist氏(=うなし)、noellabo氏(=のえる氏)、abcang氏、tribela氏、mayaeh氏、と並んでいる。
 基本的には個人単位での参加ではあるが、国際的に協力して作られていること、日本人の参加もかなり多いということは覚えておくべきである。

再検索