gnusocial や mastodon の哲学

長い文章を読みたくない人のためのまとめ

でも、できれば本文も読んでほしいです。

• Mastodon や GNU Social などでは、どこか信頼できる運営者のインスタンス(サーバ)にひとつアカウントを作って、そこから他のインスタンスのアカウントをフォローすることができます。 (インスタンスはグループのような意味を持つものではなく、単に自分の情報がどこで管理されるかを決めるものにすぎません。) 無理して複数のインスタンスにアカウントを取る必要はありません。
  • 自分用のインスタンス(サーバ)を立ててそこに自分のアカウントを作るのが、一番安心かも。 これならインスタンス管理者による情報の悪用等を心配する必要もありません。
  • 個人の(自分の)インスタンスで他人の登録を受け付ける必要はありません。 自分のアカウントだけ置いて使うことができます。
• Mastodon や GNU Social では、自分のサーバ (VPS 、自宅サーバ、 etc...) にサービスを立てることができます。
• Mastodon や GNU Social などが重視しているのは、ユーザの自由です。 これが twitter 等との大きな違いです。
• IRC に似ていますが、大きな違いとしては notice がすべてサーバに保存されることです。 IRC はクライアント(や proxy) にしかログが残りませんが、 GNU Social や Mastodon はマイクロブログサービスなので、サーバ側にデータを保存する仕組みになっています。
• その他の疑問についてはよく見る質問を参照してください。

twitter の問題

twitter には、以下のような問題がある。

• twitter が落ちるとみんな死ぬ
  • 仕組みからして仕方ないけど、そうは言っても致命的
• ツイートのデータが(基本的に) twitter 社のサーバにしか残らない
  • 外部サービスでの保存や自分のツイートのダウンロードはできるが、「昔TLに流れてきたはずのあのツイートが見付からない」という事例には無力
• 悪意ある第三者により、アカウントの凍結やツイートの削除の強制などの制限や弾圧を受けることがある
  • えっちな絵を書く人たちが「ツイレディ」と呼ばれる過激派にスパム報告されまくって凍結される事例とか
  • 違法ではないはずの画像の投稿でも規約違反扱いされたり
  • 運営者による検閲や規制があったら、避ける手段は存在しない
• 仕様が twitter 社の一存で決まる
  • ユーザの意見は(おそらく、普通は)取り入れられない
  • 開発者は黙って追従するしかない
  • なんならサードパーティのクライアント開発者を締め出したりもする
• 仕様のみならず、実装(ソースコード)も公開されない
  • 会社なので仕方ないところもあるが、そうはいってもプロプライエタリ
  • たとえば公式の twitter に問題があったとき、ユーザが修正する手段はない
  • 無論改造もできない

これらの問題は、つまるところマイクロブロギングサービスがtwitter という単一のサービスに依存しているところに原因がある。 プラットフォームを単一の運営者が管理していて(中央集権)、逆らえないため、自由が制限されているのである。 そういった自由を SNS のユーザが取り戻すための思想が、 federated social web だ。

Federated social web はどう問題を解決するか

federation とは「連合」である。 federated social web ^[0] とは、 SNS のサーバを各々が持ったり複数用意することで不要な制約を受けないようにし、それでいてサーバ間で連携することで巨大なひとつの SNS として利用できるようにするという思想であり、またその思想が目指すネットワークサービスのことである。

この思想は、先に挙げた twitter の問題を以下のように解決する。

GNU Social とは、 Mastodon とは何か

GNU Social や Mastodon は、 OStatus や ActivityPub などのプロトコル(通信やデータの規格)を実装した、 federated social web のための web サービス、またそのためのアプリケーションである。

OStatus や ActivityPub はオープンな(公開された)仕様であり、 twitter のように運営者の一存で仕様が変化したりはせず、また隠された仕様なども存在しない。 よって、これらのプロトコルを実装したアプリケーションは誰でも開発することができる。

Mastodon は A GNU Social-compatible microblogging server と説明されている^[1]が、つまりこれは OStatus を実装しているということである。 ただそれだけであるが、つまり公開された仕様によっているということなので、全く別で開発された互換サービスと連携できる。

巷の記事、紹介

その他の実装など

おまけ: 言葉の違い

同じプロトコル (OStatus) を使っているのに、何故かサービス毎に使っている用語が違ったりするので、比較表を載せておきます。

なんだかなぁ。

おまけ: 自前のサーバにインスタンスを立てるなら

• 楽したい人には Mastodon の方がおすすめ。
• ユーザの登録機能は無効化した方が良い。 個人で見ず知らずの他人の投稿に責任を持ち管理するのは流石に面倒すぎる。

参考になりそうなリンク

• ポストTwitter？　急速に流行中「マストドン」とは - ITmedia NEWS

  • Mastodon の紹介記事。

• ポストTwitter有力候補？　500文字まで書き込めるオープンソースSNS「マストドン」が脚光浴びる - ねとらぼ

  • Mastodon の紹介記事。

• Mastodon は自分のドメインでIDを持つことが大事。「リモートフォロー」の価値を最大化するべし。 ｜ 諸多日記

  • 個人や所属組織でインスタンスを立てるのが良いのだという話。

• 小規模Mastodonインスタンスを運用するコツ – potproject.net blog

  • 個人用レベルの小規模インスタンスを運用するとどんな様子なのか紹介されている。

• マストドンと北朝鮮危機にみるインターネットの本質的価値 - さくらインターネット創業日記

  • さくらインターネットの創業者の記事。 web サービスだけでなく、そもそもインターネット自体が分散と連携という思想と仕組みの上に成り立っており、それを回線等のより物理に近い面からどのように支えていくか等も語られている。

    インターネットの本質的な価値とは、核攻撃などで部分的に壊滅的な被害を受けようともネットワークが維持されるというもので、完全に分散していることと、一つのネットワークであり続けるという、一見矛盾したことを両立させているところにあります。

• マストドン（OStatus）による防災情報の配信をはじめました ｜ 諸多日記

  • 災害情報や緊急時情報などを、 OStatus で発信することで、 Mastodon や GNU Social で受信・伝達できるようにしたという記事。 twitter 等とは違い、 Mastodon であれば、どこかのインスタンスが落ちてもそれ以外のインスタンスへの情報の伝達に影響が出ないため、分散プラットフォームの利点をとても有効に活用できている良い事例。

• OStatusの仕様をかいつまんで適当に和訳するよ - hito_asaの日記

  • OStatus の仕様についての解説。

• GNU socialのインストール - Akionux-wiki

  • GNU Social のインストールについての記事。 GNU Social の概要について説明あり。

• GNU Social のボットを C++ で作る | 墓場一夜 (WordPress.com)

  • GNU Social や Qvitter plugin の概要について説明あり。 ちなみに "We have 1 simple rule" というのは、一時期 freezepeach.xyz というインスタンスで「マイクロブロガー連合は道徳と団結を大切にして、中央集権化された資本主義なサービスからの離脱を目指しています。」という定型文の代わりに表示されていたメッセージ。

• Federated Social Web Community Group

  • 非営利の国際標準化団体 W3C の、 federated social web 関連の仕様策定のためのグループ。 最近活動の形跡が見えないので超心配だが、たぶん Federated Identities for the Open Web Community Group の活動が優先されているのだと思う。 そう信じたい。

• 本の虫: そろそろマストドンについて語っておくか

  • GNU Social や Mastodon (というより、そもそも OStatus) の設計が、(理想の実現のためには)技術的にイケてないという話。 思想からすると、すべての個々人がサーバ(や、同等の動作をするアプリケーション)を持ってネットワークに参加するべきだが、難易度やコストからそれは現実的ではない。 P2P はもう少し理想に近いが、それでさえ BitTorrent 以外のプロトコルは廃れてしまった。 ままならないものだ。

• 私の GNU Social の投稿

  • 暇ならリンク先の notice から始まる conversation を読んでみてください。

    • 他のインスタンスの notice を repeat するにはちょっとした条件があるという話
    • 自前のインスタンス立てるといいよねという話

    • gnu socialの鯖、自分で立てないと結局twitter社に依存するかGS鯖缶の思想と運用に依存するかしかなくなるので、dockerとか使って自前でどうにかできるのが最適だし、是非自前鯖に乗せるべき

よく見る質問

twitter やはてブ等でときどき見掛けた疑問や意見に答えます。 間違い等あれば @lo48576@mastodon.cardina1.red までおしらせください。

投稿がフォロワーのインスタンスに配信・複製されてしまうということは、投稿が一度放流されたら消せないの？

消せないと思ってください。 これは悪いことばかりではありません。

• 発信者や運営者が意図的に投稿を「削除」した場合
  • 自分のインスタンスからは、消せます。
  • 他のインスタンスからは、実装によります。 基本的に消えないものと思ってください。
• 発信者がアカウントを消したり、インスタンスが死んだりした場合
  • 他のインスタンスからは消えずに残るはずです。

まず、発信者のインスタンスから消せるというのは当然なので良いでしょう。

他のインスタンスについてですが、まず発信者が投稿を削除すると、「投稿が削除された」というメッセージが(通常の投稿と同様に)フォロワーのインスタンスに配信されます。 それを受け取ったフォロワーのインスタンスがその後どうするかは、インスタンス次第です。 私が複数のインスタンスで試してみたところ、 GNU Social でも Mastodon でも、他のインスタンスでの削除が反映されない場合がありました^[5]。

イメージとしては tumblr のリブログのようなものでしょう。 あなたが投稿を放流した時点で、その投稿はあなただけのものではなく、それを読みたがった受信者たちのものでもあると捉えてください。 この仕様は、あるユーザのいたインスタンスが止まったり永久になくなってしまった場合であっても、自分が過去に受け取った投稿が意図せず消えることはないということを意味します。

これを「情報を削除したくてもできない」と否定的に捉えることもできますし、「かつて私が受け取ったメッセージは、他者の手によって勝手に消されることはない」というユーザ(フォロワー)の自由を尊重した仕様であると肯定的に捉えることもできます。 いずれにせよ、そういう仕様であるということは知っておくべきです。

悪いことを考えている人の Mastodon インスタンスに登録してしまうと、メールアドレスやパスワードを悪用されかねない。 危険では？

Mastodon に限らない問題です。 Mastodon の件で注意喚起されて初めて「確かに」と思った人は、セキュリティ意識がちょっと低いと思うので注意してください。

• そもそも、信用できないサーバに情報を渡してはいけません。
  • たとえば twitter アカウントを持っている人は、 twitter に登録するときメールアドレスや電話番号を登録したと思います。 それは、 twitter 社が情報を悪用しないとあなたが信用したからですよね？
  • Mastodon インスタンスも同じことです。 あなたが「この運営者なら信用してもいい」と思った場合だけ登録してください。
  • 「どのインスタンスの運営者もよく知りません。これでは登録できません！」→それなら仕方がありません。 どうにかして探すか、甘んじて大手を信用する(そしてある程度のリスクを許容する)か、諦めてください。 (ヒント: たとえば pixiv がインスタンスを立てたようです。 あなたは pixiv を信用しますか？)

  • 「最近聞いたサーバに登録したけど、メールアドレスとパスワードが悪用されるかも！ 怖い！」って、
    「最近見た人に部屋の鍵渡したけど、鍵を悪用されるかも！ 怖い！」と何が違うんですか。

• パスワードを使い回すのは論外です。 そのようなことをすれば、 Mastodon 以外のどのようなサービスであっても危険性が格段に高まります。
• パスワードを使い回していなければ、メールアドレスを知られるだけで済みます。 知られたくないメールアドレスであれば、そもそも登録に使ってはいけません。

インスタンス運営者の方針によっては、無法地帯になりかねないのでは？

一般登録を受け付けているインスタンスについていえば、その通りです。 だからこそ、信用できる運営者のインスタンスを使ってください。

そもそも、もしインスタンスに法的に問題のある情報が投稿されれば、それを削除する責任はインスタンス管理者にあります。 (もちろん、だからといって投稿者が悪くないというわけではありません。) よって、インスタンス管理者は、問題のある投稿を知らされたら適切な対応をとるか、信用できないユーザが登録しないよう制限をかけるべきです。

個人用(自分用)のインスタンスであれば、そのような問題は基本的に(そうそうは)生じません。 そのインスタンスに保存されるデータは、自分の投稿か、自分がフォローしたユーザの投稿だけだからです。 (つまり、当然ではありますが、迂闊に良くないユーザをフォローしない方が良いです。) もしインスタンスに法的に問題のある投稿が流れてきても、インスタンスの管理コマンド等でデータを削除することはできるはずです。

個人ユーザがポコポコ新しいインスタンスを立てて、流行が廃れてそれらの多くが死んでしまったら、断絶や分断が発生するのでは？

これは誤解を含んでいると思われます。

• あるインスタンスが消えたり接続できなくなったときの影響は、そのインスタンスからの投稿が届かなくなるだけで、他との繋がりには一切影響はありません。
• GNU Social や Mastodon のインスタンス同士は、直接互いに通信しあっています。 よって、当事者インスタンス間にある第三の中継インスタンスのようなものは存在しないため、断絶や分断はそもそも発生しえません。

たとえばあなたのインスタンスを X とし、 X のアカウントからインスタンス A 、 B 、 C のアカウントをフォローしているとしましょう。 ここでインスタンス A が消えてしまっても、 X は依然として B 、 C からの投稿を受け取ることができます。 B や C が消えた場合でも同様に、消えたインスタンス以外との通信に影響が及ぶことはありません。

よって、個人ユーザがポコポコ新しいインスタンスを立てると、消えるインスタンスがユーザ単位になります。 (インスタンスが生き残ってユーザが活動しなくなっても、結局何も得られなくなることに変わりはないので、それならインスタンスが消えても同じことです。) インスタンスと共に死ぬユーザが少なくなるのは、むしろ好ましいことです。

インスタンスが乱立することで、むしろ衰退の影響範囲が小さくなり、これはユーザにとっては良いことです。 個人や組織単位で、もっと気軽にポンポンインスタンスを立てましょう！

公式アカウントのような機能がないけど、アカウントが自分の思っている人のものであるとどう確認すればいいの？

短い答: 個人用インスタンスであれば、そのドメインの所有者を確認しましょう。 そうでなければ、ブログや公式 web ページなど別の信頼できる情報源で聞いたり、そこからリンクされているか確認しましょう。 (当然ですが、アカウントの説明に公式 web ページ等へのリンクが書いてあったとしても、偽装の可能性があるので信頼してはいけません。)

これは分散プラットフォームの特徴によるものです。 twitter における公式アカウントは、「 twitter という絶対の管理者が身分確認を行うことで、当人であると証明する」という仕組みです。 GNU Social や Mastodon では、この仕組みは合いません。 何故なら「絶対の管理者」など存在せず、単にそれぞれのインスタンスの運営を行う人が各所に居るだけだからです。 分散プラットフォームに、絶対の権威はいません。

マイクロブログで自分が読んだ情報が消えないメディアなら、 tumblr があるじゃん。それじゃ駄目なの？

たしかに、ブログの「トラックバック」は OStatus (や Mastodon) の設計によく似ていますし、 tumblr のリブログは情報を発信者だけでなく読者が保持することを可能にします。

しかし勘違いしないでください。 tumblr は、れっきとした中央集権サービスです。 分散なんてしていません。 そもそも twitter や Mastodon ほどチャットに近い SNS ではありません。

• tumblr では、運営会社がその権限をもって、投稿やアカウントを消すことができてしまいます。
  • 分散していれば、自分用のサーバを立ててそこで同じようなサービスを利用可能です。 しかし tumblr は単一の会社が提供するサービスであり、「自分のサーバに tumblr を立てる」ことはできません。
  • tumblr を真似た OSS は存在するようなので、それらを使うことはできるでしょうが、それは「tumblr」ではありません。
• tumblr のサービスがなくなったり tumblr の会社が消えたりすると、 tumblr 上の全てのサイトが駄目になります。
  • 分散していれば、落ちたサーバ以外にある情報はすべて無事のままです。 (たとえば mstdn.jp が落ちても mstdn.io は何事もなく動いていたように。)
• twitter や Mastodon のように、チャットに近い用途で設計されていません。
  • tumblr はそもそもチャットに使ってる人いませんよね？ (いるかもしれませんが、使い勝手は Mastodon と比べるまでもなさそうです)
  • tumblr は記事を配信するブログをベースにして作られていますが、 Mastodon は「マイクロブログ」という呼称で勘違いされがちですが、 IRC や チャットに近いものです。
• 仕様や API がいつまでも公開されているとは限らない
  • 仕様や API は会社が定めて管理しているものであり、国際規格ではありません。 よって、会社の都合などで勝手に変更される可能性があります。 (一応 forum はありますが、それを言ったら twitter にも開発者フォーラムがあるのにあの様です。)

このようなわけで、 tumblr はその仕組みからして中央集権であり、 twitter と同様のものです。 tumblr は分散プラットフォームではありません。 「分散プラットフォームなら Mastodon じゃなくても tumblr がある」という意見は、分散プラットフォームというものを勘違いしています。 (tumblr で満足できるなら、そもそも twitter を離れずとも twilog やクライアントの機能等でログをとるので十分です。)