LGBTPZNは遊戯的であるべきだが、遊戯ではない

運動の本体は暴徒であるべきである、理論家はその支援者に過ぎない、というのが私の意見である。LGBTPZNは原理的に、理論家によって真面目な運動に仕立て上げられることが不可能であるように思われる。では、私たちは、暴徒であることができただろうか? あるいは、その支援者として振る舞うことができていただろうか?

LGBTPZNのうち、特にペドフィリアは、多様な困難に直面している。まず、性徴前の人間と性交することの問題に絞って考えると、相手に性欲がないこと (状況を限定すればこれに論駁することも可能かもしれない)、相手と知識や力に差があること (しかし、ペドフィリアの側が童貞であったり、知的障害者であったりする場合にはどうであろうか?)、などの倫理的な問題があることが分かる。ペドフィリアであること自体が (たとえ内面の空想に限定したとしても) 倫理的に罪であるという風潮も、多くの敵対者たちに共有されている。

児童ポルノを製造・販売・所持することは、わが国では (あるいは、ほとんどすべての先進国で) 違法である。前段落では問題を「性徴前の人間と性交すること」に限定したが、法的な児童とは18歳未満の者を指し、この中には人格、体格、あるいは性体験のうえで成人と遜色ない者が多く含まれている。ペドフィリアに対する社会的な禁忌感は強固であり、性徴後の児童と成人との恋愛ですらしばしば指弾されるけれども、児童と児童との恋愛はむしろ奨励されている。

法と倫理によって徹底的に自分自身を破壊された者が、なおも何らかの倫理や価値観に対して誠実であることは可能だろうか?

LGBTPZNのうちのPは本質的に倫理的な困難を抱えている。かつてはLGBTもそうであった、特にそれが宗教的な禁忌と強く結び付いていた時代には。

だから、LGBTPZNはLGBTPZNの (あるいはPZNの) 権利運動にはなり得ない。そのようなものを夢想したり、あるいは、そのようなものに擬態したりしながら、それの周りで歌ったり踊ったりしている。これは熱狂的な死の舞踏である。

遊戯的な運動には前例がある。というよりも、わが国のシリアスな運動は、浅間山荘を最後に敗北した。それ以降の運動は、革命的非モテ同盟やSEALDsのように、パロディーあるいはコメディーとして振る舞わざるを得ない。

LGBTPZNは遊戯的であることしかできない。そして、それは呼吸や排泄と同じくらい、私たちにとって重要なことである。

広告

GitLabと仲良くなる

Pleromaの開発はGitLabが使われている。本稿では、GitLabの使い方情報と、Pleromaの開発に固有の事情を織り交ぜてやっていく。

developブランチとfeatureブランチ

まず超実践Gitは強いのでみんな読むといい。ところで、超実践Gitの既存の戦略を知るという節によると、Git界隈で使われているブランチの名前には、以下のような流派がある。

  • git-flow: development, features, hotfix, releases, master
  • github-flow: master

さて、PleromaのGitLabがどうなっているかというと、develop がデフォルトのブランチであり、feature/XXX というブランチと fix/XXX というブランチが大量に作られている。masterブランチは、存在するがまったく使われていない。

Pleromaの開発体制は、ブランチの名前はgit-flowだが、実際にやっていることはgithub-flowである。Pleromaのdevelopブランチは、github-flowにおけるmasterブランチと同じように使われている。そのため、インスタンスを運営したい人はdevelopブランチからコードを持っていくことになっている。

余談だが、ブランチの名前に / を含めることが普及しているのは、初心者にとっては割と驚きがある。

ブランチをいっぱい作る

開発者にとって最終的な目標の一つがマージリクエストを出すことだ。GitHubにおけるプルリクエストのことをGitLabではマージリクエストと呼ぶ。

マージリクエストの実体は2個のブランチの組である。これらのブランチは別のレポジトリに置かれていてもよい。いずれかのブランチに新しいコードがコミットされれば、マージリクエストの内容も変化していく。そのたびに、マージが成功したりコンフリクトしたりするし、テストが通ったり通らなかったりする。

マージリクエストを出すことを想定して、1個のブランチには1個のテーマのコードのみをコミットする。このようなブランチを特にトピックブランチと言うこともある。

トピックブランチとは別に、インスタンスで実際に稼動しているコードを入れるブランチも必要である。AGPLにより、インスタンスが独自機能を持つならば、コードを公開する義務があるからである。私はdistsnという名前のブランチにしたが、deploy/distsn のような説明的な名前のほうがわかりやすいかもしれない。

本稿の読者の知識をどのように想定すればよいかわからないが、クローンとは以下のようなコマンドをやっていくことである。-b のあとの feature/who-to-follow-panel はブランチの名前であり、最後の who-to-follow-panel はローカルのディレクトリ名である。

git clone https://git.pleroma.social/hakabahitoyo/pleroma-fe.git -b feature/who-to-follow-panel who-to-follow-panel

本家のdevelopブランチに追従する

インスタンスを運営しているならば、新機能を取り入れることは欠かせない。また、トピックブランチにおいては、他の開発者による変更と衝突がないようにするために、きりのいいところで本家のdevelopブランチに追従する必要がある。

この作業はGitLabではなくローカルのgitコマンドでやっていく。Pleromaのレポジトリにはpleromaとpleroma-feがあり、ここでは例としてpleroma-feの方でやっていく。

git remote add official https://git.pleroma.social/pleroma/pleroma-fe.git
git fetch official
git merge official/develop

git remote add はレポジトリをクローンしたときに1回やればよく、git fetch と git merge は本家のdevelopブランチに変化があったときにはやるべきである。余談だが、git remote add でスペルミスをやらかしたときの直し方は git remote set-url である。

応用としては、レポジトリをクローンしたときには、自分のレポジトリが origin という名前で登録されている。これに対して fetch と merge をやっていくことにより、トピックブランチから機能を取り込むことができる。

git fetch origin
git merge origin/feature/who-to-follow-panel

pleroma.distsn.org は本番環境が開発環境を兼ねているので、この方法でトピックブランチを取り込んで動作確認をやっている。

ESLintを倒す

PleromaのGitLabレポジトリでマージリクエストを出すと、自動的にテストが走る。マージリクエストではなく普通のコミットでも自動的にテストが実行される。pleroma-fe は JavaScript 的なもの (Vue.jsとwebpackあたり) で書かれているので、ESLintでチェックされる。Lintとは人類にコーディングスタイルを強制するプログラムで、ESLintはそれのJavaScriptのやつである。

ESLintを倒さないと気分が悪いので、倒す。JavaScript Standard Styleという偉そうな名前のやつが相手なので、あらかじめ読んでおくと倒しやすい。

ユニットテストを倒す

pleromaレポジトリはElixirで書かれているので、それ用のユニットテストフレームワークが作動する。ただし、テスト環境が壊れていることも多い。テストの結果を見て、自分が書いたコードとは関係なさそうなところがエラーになっていたら、マージリクエストのコメントあたりで発言すれば、強い人たちが直してくれそうである。

Pleromaの開発環境を作る

Pleromaという異常な分散SNSがあり、3.distsn.orgというインスタンスを運営している。インスタンスの運営よりも独自機能をもりもりやっていくことに興味があるので、そのようにする。

インスタンスを設立する

Pleromaのインストールは公式のWikiを読めば難しくない。日本語もあるが、英語が苦痛でなければディストリビューション別のドキュメントを読むほうが早い。やっていきましょう。

余談ですが、マストドンと比較して、Pleromaのインストールの楽なところを挙げる。

  • メールサーバーの設定が不要。マストドンでは、メールサーバーを自分で建てるか、Mailgunあたりのメールサーバーを使う必要がある。
  • 管理者ユーザーの作成が不要。Pleromaには管理者ユーザーが存在せず、インスタンスの設定はローカルなファイルを編集することで行う。
  • 安価な計算機資源でまともに動く。さくらのVPS 512 MBでも余裕。

Pleromaのインストールの面倒なところは、Elixirのバージョンが最新である必要があり、ディストリビューションのパッケージではなく、Elixirのウェブサイトからパッケージを取ってくる必要があることである。前述の手順書にはこの方法も書いてあるので安心だ。

レポジトリが2個ある

開発環境を作るということは、ソースコードとやっていくということで、まずはPleromaのGitLabにアカウントを作る必要がある。GitHubに依存して生活していると、まずここが面倒だが、やっていく。

次に pleromapleroma-fe をフォークする。レポジトリが2個あるというのが割と驚きポイントである。pleromaはバックエンド (サーバーサイド)、pleroma-feはフロントエンド (クライアントサイド) であり、両者は別のレポジトリになっている。

独自機能をやっていくことに興味がなく、単にインスタンスを設立したいだけなら、pleromaレポジトリだけをクローンすればよい。なぜかというと、pleroma-feレポジトリをビルドした生成物を、定期的に (開発者が手動で) pleromaレポジトリにコピーしているからである。具体的には、pleroma-fe の /dist/index.html と /dist/static が、それぞれ pleroma の /priv/static/index.html と /priv/static/static にコピーされる。

ここで、pleromaレポジトリが ~/pleroma にクローンされており、pleroma-fe レポジトリが ~/pleroma-fe にクローンされているとする。まず準備として、pleroma-fe で以下をやっていく必要がある。(補足: pleroma-fe の開発環境を作る)

npm install
npm run build

すると ~/pleroma-fe/dist ディレクトリに生成物が入る。あとは以下のようなシンボリックリンクを作ればよい。

cd ~/pleroma/priv/static
mv index.html index.html_
mv static static_
ln -s ~/pleroma-fe/dist/index.html .
ln -s ~/pleroma-fe/dist/static .

これで動くと思う。pleroma-fe の側でコードを編集したときは npm run build で新しくなる。pleroma の側でコードを編集したときは、たいてい何もしなくても新しくなるが、ごく稀に MIX_ENV=prod mix ecto.migrate が要る。

やや面倒なのは、pleromaレポジトリの側でgit関連の操作をしたいときは、これらのシンボリックリンクを元に戻す必要があることだ。そのために、上記のコマンド例ではmvコマンドで元のファイルを残している。

config.jsonをやっていく

さて、pleromaレポジトリには /priv/static/static/config.json があり、pleroma-feレポジトリには /dist/static/config.json がある。これらは内容は同一であるべきであり、開発者がぼんやりしていない限りはそうなっている。とはいえ、このファイルはインスタンスごとに設定を書き換えて使うので、どちらか一方だけを書き換えるというミスがあり得る。すると、シンボリックリンクに切り替えたときに動作が変わることになる。両者を常に同一の内容に保つべきだろう。

訂正 よく考えたら pleroma-feレポジトリの /static/config.json が /dist/static/config.json にコピーされるので、/static/config.json を編集する必要がある。npm run build で更新される。

追記

ふむっふむっ

ツイッターからPleromaに移住する方法

界隈で言うところの、鳥を捨てて神の連合に移住する方法。フレンズを維持したまま、異常者は置き去りにする。

もしあなたがPleromaを知らないなら、マストドン日本語ウィキの記事新しい連合型SNS「Pleroma」はMastodonを置き換える?Mastodonに続く新たな連合型SNS「Pleroma」作者に聞く開発の背景、特徴、ロードマップを読むとよい。簡単に言うと、Pleromaは脱中央集権なソーシャルネットワークで、自由ソフトウェア信者によって開発されており、ツイッターによく似ているが、さらに価値が追加されている。

もしあなたがまだツイッターを使っているなら、Pleromaに移住する理由は以下のものが考えられる。

  • Pleromaは友好的、会話的で新鮮。初期のツイッターに似ている。
  • ユーザーが最初に置かれている。Pleromaのアーキテクチャは完全にハラスメントとイジメに対する防御のために設計されている。
  • ナチスがいない。(ナナチはたくさんいる。)
  • 企業の利益のために運営されていない。あなたのデータを収穫し第三者に売る中央権威が存在しない。
  • 中毒性のあるテクノロジーではない。ログインと投稿を促すメールリマインダーを送らないし、あなたの個人的な詳細を手放すこともない。
  • 脱中央集権でオープンサースなソフトウェアがコミュニティにより開発されている。政府または邪悪な集団が、禁止したり検閲したりすることが難しい。

もしあなたがすでにPleromaのアカウントを持っているなら (もしまだならPleroma公式サイトPleromaインスタンス一覧が助けになるかもしれない)、移住を助ける以下のようなトリックがある。

ツイッターから

  1. あなたのツイッターのフレンズのうちマストドンに移住している者を探し、フォローする。Pleromaのユーザーはマストドンのユーザーをリモートフォローできるからである。残念ながら、ツイッターからPleromaに移住した人を探すウェブサイトはまだないので、かわりにツイッターからマストドンに移住した人を探すウェブサイトを利用する。同じことを3ヶ月から6ヶ月くらいの周期で繰り返すとよい。すべての卒鳥が2017年4月に行われたとは限らない。まさに今日、移住した人もいるかもしれない。それを探してPleromaからリモートフォローしよう。
  2. Pleromaに移住したことを知らせるアナウンスと、PleromaのプロフィールページのURLをツイートする。私は鳥のアカウントを消してしまったので例を示すことができない。
  3. 移住を通知するツイートをプロフィールに固定する。これにより、ツイッター側のプロフィールページを見る人に移住を知らせることができる。
  4. ツイッターはスクリーンネームの文字数が多くなったので、ツイッターでのスクリーンネームの末尾にPleromaのハンドルネームを含めることができる。これはツイートのたびにメッセージを広めることができる。Pleromaのハンドルネームは @your-username@the-instance-where-ist-located のような形式である。私の例は @vaginaplant@3.distsn.org である。メールアドレスに似ているが、最初に @ がある。ところで、このアドレスにメールを送らないこと。送っても届かないぞ。
  5. あなたがまだツイッターにいるなら、Pleromaのツイッターアカウントは知られていないので、マストドンの公式アカウントをフォローするとよい。マストドン公式ツイッターアカウントは移住を決断したことを継続的に思い出させてくれるし、リツイートするに値する話を提供してくれる。

移住するとき

あなたがスマートフォンでツイートしているなら、Pleromaはさまざまな方法でそれを代替する。Pleromaのスマートフォン用クライアントは知られていないが、マストドンのクライアントはおおむねPleromaのインスタンスに接続できる。Pleromaで動作確認されたスマートフォン用クライアントの一覧 が提供されている。ただし、それよりも、スマートフォンのブラウザでウェブUIを使うほうがよい。近年ではスマートフォンのブラウザも優秀なので、いつまでもアプリにこだわる必要はない。それはそうと、こんな話もある:

  1. ツイッターの公式アプリをアンインストールしよう。あいつは悪い。あなたの位置を追跡するし、ツイートを時間順に配列してくれないし、あなたがスマートフォンでやることをすべて捕捉しようと試みている
  2. かわりに……マストドン用のスマートフォンアプリで、Pleromaでの利用に適したものがあれば教えてほしい。

Pleromaへ

Pleromaを、あなたが入学した大学か、あなたが引っ越してきた都市であると想像してほしい。あなたはPleromaがどのように動作するか知っているとする。ここにはあなたにとってなじみ深いものもあるし、よく知らないものもある。ここにはあなたの新しい友になる人がたくさんいるが、あなたがすでに知っている人はわずかである。いずれにせよ、引っ越しのたびに、ほんの少しの努力が必要である。

Pleromaではツイッターよりも少しだけ困難がある。けれども、必要なことは、自分自身であることである。それぞれのソーシャルネットワークには雰囲気に違いがある。Pleromaがいくらツイッターに似ているとしても。その違いを見つけようと意識するとよい。これは、あなたが引っ越してきた通りの角に喫茶店を見つけたときに似ている。混んでいるだろうか? もっともよい注文は何だろうか? なぜ人々は電話をするとき外に出るのだろうか?

ここに、あなたが興味を持つかもしれない少数のアカウントを挙げる。

もちろんもっとたくさん (マストドンとPleromaを合わせれば17,000くらい)。連合タイムラインまたはローカルタイムラインに飛び込めば、とてもたくさんの投稿が多様な言語でなされていることを見るだろう。特にアカウントを作った直後は連合タイムラインまたはローカルタイムラインを見るべきだ。それによりここがどういう所かが分かる。そして、これは基本的にPleromaでしかできないことだ。次は新しい人々をフォローしよう。思ったほどおもしろくなければアンフォローするのもよい。誰も怒られない。ここは新しい土地だ。好奇心になろう。

沈黙しないようにしよう。ここはソーシャルネットワークである。もしあなたが何も持ち込まないならば、本当におもしろいものはない。ソーシャルネットワークツールはデフォルトでは空である。他人と話そう。ここは、ありあわせ料理、持ち寄りのパーティー、共有ランチである。すべての人が何かしらをテーブルに持ってくる。

ツイッターからPleromaに投稿をシェアする

あなたはツイッターで見た良い物をPleromaにシェアしようと思うかもしれない。これは良いことだ。これを正しく行うために、あなたのコピーの先頭に “RT @username@twitter.com” を付けよう。これはオリジナルの著者をクレジットするためである。ところで、これは最初期のツイッターで行われていたことである。

読者にとって攻撃的かもしれない投稿はContent Warningするとよい。マストドンにはある。Pleromaだと話がややこしく、Pleromaの独自UIはContent Warningを扱えないが、Pleromaのバックエンドとマストドンのフロントエンドという不気味な組み合わせだとContent Warningが可能である。

マストドンの人々は観客を尊敬する傾向にある。暴力、政治的な意見、ツイッター (鳥) に関することはContent Warningに隠すことが好まれる。Pleromaはマストドンに対する反動で不謹慎を好む文化があるが、それにも限界はある。

あと、チンコツイツイマストドンスペースを使うのは絶対にやめよう。鳥を燃やされても知らんぞ。

Pleromaからツイッターに投稿をシェアする

移住の動機によっては、Pleromaでの行動を共有することによって、ツイッターのフォロワーとの接触を維持したいかもしれない。私はそれを行っていない。なにしろ鳥のアカウントをスナネコしてしまったし、もしそうでないとしても、Pleromaのアカウントをフォローしてもらうほうがよい。Pleromaはともかく、マストドンであればMastodon Twitter Posterという手がある。

結論

ツイッターは悪くなる一方ではあるが、かつては楽しく有望であったとあなたが感じているならば。より敬意ある文化のマイクロブログ、コミュニティの決定により運営されるプラットフォーム、中央集権なサイロでないSNSが可能であると信じるならば。新しい旅を始める時は今である。

さいわいなことに、私はこの記事で、移住を容易にするための複数のツールを紹介することができた。あなたの目的が、ツイッターのアカウントを完全に削除することであるとしても、あるいは、ツイッターが燃え尽きて灰になるまで両方のアカウントを維持することであるとしても。

いずれにせよ、未来は明るく、Pleromaの成長は早く、ソーシャルメディアの未来に対するインパクトを私たちは正確に見積もることができない。(PeerTubeとActivityPubのような新しい話題もある。)

この記事があなたを助けた、もしくは、この記事に間違いがあると感じたら、私に知らせてほしい。そして、「ちょうど羽田に着陸しました」と言うことを恥ずかしがらないでほしい。

謝辞

本稿はJulien Deswaef, How to transition from Twitter to Mastodonの日本語訳である。CC BY-SAが適用される。

Pleromaインスタンス一覧を作った

概要

Pleromaインスタンス一覧

背景

マストドンのインスタンス一覧が乱立しているのに対して、Pleromaのインスタンス一覧はほとんど知られていない。Pleroma公式ウェブサイトに掲載されているインスタンスは実質2件 (他にフロントエンドのみPleromaのインスタンスが1件) である。マストポータルはインスタンスを登録するときGNU social、マストドン、Pleromaから実装を選択できるが、Pleromaのインスタンスのみを検索する方法が見当たらない。マストドン日本語ウィキのPleromaの記事には7件のインスタンスが記載されている。

提案手法

そこで、Pleromaのインスタンスの一覧を自動的に生成する方法を提案する。すでに、Peers APIを用いてインスタンス一覧を自動的に生成する手法が知られている。このインスタンス一覧にはマストドンとPleromaのインスタンスが含まれるため、Pleromaのインスタンスのみを抽出して表示すればよい。

インスタンスがPleromaであるかどうかを判断するために /api/pleroma/emoji を用いる。Pleromaのみに存在するAPIのうち、GETメソッドかつ認証不要でアクセスできることから、このAPIを選択した。このAPIにアクセスしたときJSONを返すインスタンスはPleromaであると判断する。稀に、すべてのパスに対してHTML形式のメッセージを返すウェブサイトが存在する () ので、これを避けるため、応答がJSON形式であることを確認する必要がある。

実際にPleromaのインスタンス一覧 (API) を作成したところ、20件のインスタンスを収集することが出来た。

制限

今回の実装では、掲載されるインスタンスはPeers APIを提供しているものに限られる。これは、2018年1月15日以降にdevelopブランチのコードを取り入れていることが必要である。

感想

APIを提供しないインスタンス一覧は何をやってもだめ。

マストドンインスタンス一覧を自動で作る

概要

マストドン2.1.1より /api/v1/instance/peers が導入された。これを使えば、誰でも簡単にインスタンス一覧を作ることができる。

背景

日本語圏のマストドンではインスタンスの一覧が乱立していることが知られている。このうち、インスタンスの登録が自動化されているものはinstances.socialマストポータルがある。また、自前ではインスタンスの登録を受け付けず、instances.socialのAPIを利用しているインスタンス一覧もある。

一方、インスタンスの登録にウェブサイト管理者の承認が必要であったり、ウェブサイト管理者が自分でインスタンスを収集していたりする場合には、ウェブサイト管理者の負担が大きいという問題がある。さらに、ウェブサイト管理者がインスタンスの登録の申請に応答しなくなり、インスタンス一覧の更新が途絶えている例も少なくない。有力なインスタンス一覧の更新が途絶えた場合には、古参のインスタンスに有利であり、新興のインスタンスには不利な状況になる。

ところで、マストドン2.1.1より /api/v1/instance/peers が提供されるようになった。これは、あるインスタンスに接続されている別のインスタンスのリストを提供するAPIである。Pleromaではstats-daemonブランチでPeers APIの開発が行われており、2018年1月15日にdevelopブランチにマージされた。すでにこのAPIを運用しているPleromaインスタンスには pleroma.distsn.org がある。

このAPIを再帰的に探索することにより、誰でもインスタンス一覧を作ることができる。このインスタンス一覧はインスタンスの登録が不要で、自動的にインスタンスを収集することができる。収録されるインスタンスの数と、新しいインスタンスを捕捉する早さは、既存のインスタンス一覧を簡単に凌駕する。

インスタンス一覧の作成

そこで、この節では、Peers APIを再帰的に探索することにより、自動的にインスタンス一覧を生成する方法を解説する。ソースコードは github.com/distsn/instances にある。重要なことは、深さ優先探索ではなく幅優先探索を用いることである。幅優先探索なので、先入れ先出しのキューを用いる。

準備

原初インスタンスのリストを用意する。私の実装では、以下のインスタンスを原初インスタンスとしている。これらのインスタンスのなかにはPeers APIを提供していないものもあるが、これは、将来のバージョンアップに期待してのことである。

  • mastodon.social
  • mastodon.cloud
  • pawoo.net
  • mstdn.jp
  • friends.nico
  • mstdn.kemono-friends.info
  • mstdn.maud.io
  • mastodon.juggler.jp
  • pleroma.soykaf.com
  • pleroma.knzk.me
  • ketsuben.red
  • plrm.ht164.jp
  • pleroma.vocalodon.net
  • plero.ma
  • pleroma.taketodon.com

反復

インスタンスの収集のため、以下の動作を繰り返す。

  1. 原初インスタンスのうち、キューに登録されていないものがあれば、キューの入口に追加する。
  2. キューの出口からインスタンスを1個取り出す。
  3. 取り出されたインスタンスの /api/v1/instance/peers を取得する。
  4. /api/v1/instance/peers のアクセスに失敗した場合は、手順1に戻る。
  5. /api/v1/instance/peers で得られたインスタンスを、すでにキューに登録されているものを除いて、キューの入口に追加する。
  6. 取り出されたインスタンスを、再びキューの入口から追加する。

追加の情報を得る

Peers APIで得られるのはインスタンスのホスト名のみである。ここでは、インスタンスのさまざまな情報のうち、自動的に取得できるものを紹介する。

/api/v1/instance

/api/v1/instance で得られる情報には、以下のものがある。

  • インスタンスの名称
  • インスタンスの説明文
  • 連絡先メールアドレス
  • バージョン
  • 登録ユーザー数
  • トゥート数
  • 接続インスタンス数
  • サムネイル画像
  • トゥートの最大字数

登録ユーザー数は、あまりに簡単に取得できるがゆえに濫用された指標である。

サムネイル画像を真面目に設定しているインスタンスは少数である。しかし、結月ゆかりインスタンスサムネイル画像は素晴らしい。

トゥートの最大字数を報告するのはPleromaの独自機能である。マストドンでのイシュープルリクエストは不穏になっている。

/api/v1/instance/activity

/api/v1/instance/activity と /api/v1/instance/peers は同時期に開発され、マストドン2.1.1から有効になった。/api/v1/instance/activity で取得できる情報は以下。

  • 週間トゥート数
  • 週間アクティブユーザー数
  • 週間新規ユーザー数

一例として、分散SNSフォーラムの流速順インスタンス一覧は、インスタンスの名称、サムネイル画像、週間トゥート数を用いている。

将来の課題

悪意のあるインスタンスが、無意味なホスト名を大量に羅列した /api/v1/instance/peers を送信することで、DoS攻撃が可能だと思う。

まとめ

インスタンス一覧は /api/v1/instance/peers を使えば30分くらいで作れる。あと、インスタンス管理者はサムネイル画像を設定してくれ。

脱中央集権のためのデザイン: セレブのためのインターネットを99 %の手に取り戻す

Mastodon 2 Advent Calendar 2017 の12月25日の参加記事。

概要

昨今のワールドワイドウェブ、特にCGM (consumer generated media) では、知名度のあるユーザーに視聴が集中する現象が起きている。これをセレブのインターネット (internet of celebrities) と呼ぶことを提案する。ところで、マストドンを含む分散SNSの理念に脱中央集権 (decentralization) がある。これは普通、複数のインスタンスが連合を形成することで権力を分散することを指すが、私はこれに加えて「ユーザーの脱中央集権」が必要と考えている。これは前述のセレブのインターネットに対抗するものである。

ユーザーの脱中央集権に逆行するデザインの一例として、フォロワー数順のユーザーランキングが挙げられる。確かに、フォロワー数の多いユーザーのトゥートは、愉快であったり有意義であったりする見込みは高い。しかし、同じように有意義なトゥートを発信するユーザーであっても、あらかじめ知名度がなければ着目されることは稀である。

ここで、ユーザーの脱中央集権に貢献するデザインを「累進的」、ユーザーの脱中央集権に逆行するデザインを「逆進的」と呼ぶことを提案する。これは、税制の分野において所得の再分配の効果があるかどうかを表す用語を転用したものである。本稿では、マストドンに関係するさまざまなデザインについて、その累進性と逆進性を検討する。

セレブのインターネット

昨今のワールドワイドウェブ、特にCGM (consumer generated media) では、知名度のあるユーザーに視聴が集中する現象が起きている。これをセレブのインターネット (internet of celebrities) と呼ぶことを提案する。

セレブのインターネットを象徴するウェブサイトとして VALU が挙げられる。VALU はインターネットでの知名度を (ビットコインを経由して) 換金するシステムである。岡田有花が VALU を退会するために仮想株式をすべて買い戻した ことは記憶に新しい。VALU のパロディーである NILU でさえ、ぬるかる、結城浩、高橋直大といったインターネット有名人の仮想株式が (無価値であるにもかかわらず) 大量に取引され、ある種の虚栄心可視化ツールとして機能している。

インターネットのアプリケーションは、しばしば電話のようなものとして想像されたり、テレビのようなものとして想像されたりする。CGM は原理的には電話でもテレビでもないはずであるが、実際には電話かテレビとして使われることが多い。有名な SNS のうちでも LINE は電話そのものである (そのため、LINE はそもそも CGM ではない)。CGM であることを意図してデザインされたウェブサイト、例えばツイッターであっても、仲間内での雑談や連絡のために使われることの方が多数派であるように思われる。

CGM は、また、テレビのようなものとして使われてしまうことも多い。主要なコンテンツが「公式コンテンツ」、すなわち、巨大な資金と人員を投入して製作されたコンテンツであることはよく見られる。もっとあり得るのは、著作権を侵害しているコンテンツ、すなわち、巨大資本が製作したコンテンツをユーザーが無断でアップロードしたものが CGM として扱われている場合である。

CGM をテレビのようにしてしまう要因には、有名人すなわちインターネットセレブの存在も挙げられる。インターネットセレブは、媒体によってアルファブロガー、アルファツイッタラー、ユーチューバーなどと称される。アルファツイッタラーという用語は、当初はアルファブロガーのパロディーであった。インターネットセレブはインターネットの外部 (オールドメディア、典型的にはテレビ) ですでに有名であった者が多く、インターネットのコンテンツで成り上がった者はいまだに少数派である。

私の経験では、ツイッターで情報を発信していても、アルファツイッタラーに RT されたときだけ RT が伸びるという現象を常に体験していると、情報を発信することに虚無を感じがちである。それよりはむしろ、単なる消費者・視聴者に徹する方が精神衛生に良い。(具体的には、これは vaginaplant と todesking の関係である。百合だ。)

マストドンはセレブのインターネットか?

では、マストドンはセレブのインターネットだろうか? 現在のマストドンは、アルファマストドナーと呼べるほどの巨大なユーザーは存在しないように思える。そもそも、マストドンのユーザー数は (Pawoo や JP のような大規模インスタンスを含め連合をすべて合計したとしても) インターネットセレブが出現するほどの母数がない。あるジャーナリストによれば、マストドンの現状のユーザー数では、広告代理店は採算が取れないので動かない、とのことである。

一方、アルファマストドナーの存在を示唆する意見もある。mstdn.jp Advent Calendar 2017ぐすくま氏の記事 では、岡田斗司夫のいう評価経済社会の概念を援用し、「現在のマストドンは、一部の人気ユーザーに評価が集まる、小さな評価経済社会が構成されている」という認識を示している。評価経済社会という用語を使わなければ、これはセレブのインターネットそのものである。

2017年10月22日発売の同人誌「対膣煽り: マストドンと分散SNSの熱狂と苦悩」には、「ポストエイプリルなマストドンでインスタンスを新たに開設するにあたっては、鯖管のインターネットにおける知名度が重要になりつつある」と書かれている。実際にこの記述を彷彿とさせるインスタンスもいくつか見受けられる。マストドンは、セレブのインターネットそのものとまでは行かないまでも、プチセレブと呼ぶべきユーザーは存在すると見てよいだろう。

デザインの累進性と逆進性

いずれにせよ、セレブのインターネットを打破し、ユーザーの脱中央集権を実現するためには、小規模なインスタンスや、無名のユーザーに光を当てていく必要がある。ここで、ユーザーの脱中央集権に貢献するデザインを「累進的」、ユーザーの脱中央集権に逆行するデザインを「逆進的」と呼ぶことを提案する。これは、税制の分野において所得の再分配の効果があるかどうかを表す用語を転用したものである。

逆進的なデザインに共通するパターンとして、シュリンクラップ効果、大御所効果、正のフィードバックの3点が挙げられる。

シュリンクラップ効果とは、知名度とタイトルだけを見て選択しなければならない状況がもたらす逆進性である。この名称の由来は、立ち読み防止のため書籍をシュリンクラップしている書店があることである。

大御所効果とは、過去に人気のあったインスタンスまたはユーザーが、その後も知名度を増やし続ける効果である。この名称の由来である大御所とは、征夷大将軍を引退した者の敬称である。

正のフィードバックとは、ある現象がその現象それ自体の原因となることで、時間の経過とともに影響が際限なく発散していくことを意味する。

インスタンス一覧の累進性と逆進性

日本語圏のマストドンではインスタンスの一覧が乱立している。インスタンスの一覧の一覧のような記事も、いつもの匠によるもの墓場人夜によるものマストドン日本語ポータルによるもの が知られている。では、乱立するこれらのインスタンスの一覧について、その累進性と逆進性を見ていこう。

登録ユーザーが多い順

実用的なインスタンス一覧のうち、最も逆進的なのが、登録ユーザーが多い順に配列しているリストである。この逆進性には複数の理由がある。第1に、登録ユーザー数とは、そのインスタンスに少しでも興味を持って登録した人の数である。これは、そのインスタンスの知名度そのものであり、必ずしもそのインスタンスが実力で獲得したものではない。興味を持って登録したものの、実際には魅力がなかった場合、ユーザーはそのインスタンスを離れていくかもしれないが、それによってユーザー数が減るとは限らない。

第2に、ユーザー数が過去からの累積であることである。これにより、開設時期が古いインスタンスは有利である。特に、2017年4月のブームの時期にマストドンのユーザーが急激に増加したことを考えると、その時期に存在したインスタンスはそれだけで有利になる。

第3に、登録ユーザーが多い順に配列されたインスタンス一覧を見て、それを参考にインスタンスに登録するという行動を取るユーザーがいると、正のフィードバックが発生することである。これにより、少数のインスタンスに多数のユーザーが集中することになるであろう。

登録ユーザーが多い順に配列されたインスタンス一覧には、日本のマストドンインスタンスの一覧マストドン検索ポータル などがある。

トゥートが多い順

トゥートが多い順の配列は、登録ユーザー数が多い順と比べれば、逆進的ではない。なぜなら、登録ユーザー数は少しでも興味を持った人の数であるのに対して、トゥート数は、実際にそのインスタンスの実態を経験したうえで、トゥートという能動的な行動をとったことを反映しているからである。

しかしながら、過去からの累積であることと、正のフィードバックが発生することは、登録ユーザー数が多い順と同じである。トゥートが多い順の配列は、やはり大いに逆進的であると言わざるを得ない。

トゥートが多い順をデフォルトの並び順としているインスタンス一覧は知られていないが、Mastodon Instance List はトゥートが多い順にソートすることができる。

収録が古い順

続いて、インスタンス一覧に収録された日時が古い順に配列されているリストを考える。このようなリストは、末尾に新たなインスタンスが追加されることを除けば、常に同じインスタンスが同じ順番で見えている。

このリストはユーザーの行動によって順序が変動しないので、ユーザーの行動によって正のフィードバックが発生することはない。そのため、登録ユーザーが多い順、トゥートが多い順に比べれば、逆進性は低い。しかし、古参インスタンスにユーザーが集中する可能性を考えると、やはり逆進的であると言える。

インスタンス一覧に収録された日時が古い順に配列されているリストとして、日本Mastodonインスタンス一覧 が知られている。また、2017年11月6日までの joinmastodon.orgMastodon Instances に登録された日時が古い順であった。joinmastodon.orgは古参インスタンスを優遇していた も参照。

手動で作成されたリスト

手動で作成されたインスタンス一覧の逆進性と累進性は、作者の心がけ次第である。しかしながら、作者による主観評価は、しばしば知名度や登録ユーザー数に影響されがちである。また、作者による更新が停止した場合には、その時点までに存在したインスタンスのみが掲載されるため、新興インスタンスにとっては相対的に不利になる。

これらの理由から、現時点で知られている手動で作成されたインスタンス一覧は、かなり逆進的であると指摘せざるを得ない。

手動で作成されたインスタンス一覧には、Иagiによるもの (スプレッドシート抜粋)、童貞ペンギンによるもの (三大インスタンス編中規模インスタンス編小規模インスタンス編)、takimuraによるものおかず◎によるもの が知られている。

流速が速い順

ここで流速とは、一定時間あたりのローカルタイムラインのトゥート数のことである。流速が速い順に配列されたリストは、これまで見てきたような逆進性の原因を、かなり排除することに成功している。第1に、流速は直近3時間 (分散SNSフォーラムの実装) の観測値であるので、過去の累積が無関係である。そのため、先に開設されたインスタンスが有利になることはないし、2017年4月のマストドンブームの状況を引きずることもない。第2に、流速はトゥートという能動的な行動の結果なので、知名度や話題性ではなく、実際にそのインスタンスが活発であるかどうかを見ることができる。

しかしながら、もしユーザーがこのリストをもとにインスタンスを選択した場合、やはり正のフィードバックが発生する。流速が速い順に配列されたリストは、やはり逆進性があると言える。

流速が速い順に配列されたインスタンス一覧は、分散SNSフォーラム のものが知られている。また、デフォルトの並び順ではないが、マストポータル は流速順に切り替えることができる。

ランダム

ランダムに配列されたインスタンス一覧は、逆進性と累進性について中立である。

ランダムに配列されたインスタンス一覧には、Mastodon Instancesjoinmastodon.org (2017年11月6日以降)、ムトー などがある。また、インスタンス一覧ではないが、分散SNSフォーラムのローカルタイムラインビューア は、ランダムに選択されたインスタンスのプレビューを見ることができる。

収録が新しい順

収録が新しい順に配列されたインスタンス一覧は累進的である。なぜなら、新興のインスタンス、あまり知られていないインスタンスも、限られた期間ではあるがリストの先頭に掲載されるからである。

この累進性はわずかに不完全である。すでに多くのユーザーを獲得したインスタンスが、後になってインスタンス一覧に登録されれば、やはりリストの先頭に掲載されるからである。

収録が新しい順に配列されたインスタンス一覧は、Mastodon Instance Listマストポータル が知られている。デフォルトの並び順ではないが、日本のマストドンインスタンスの一覧 は新着順に切り替えることができる。

インスタンスの開設が新しい順

インスタンスの開設が新しい順に配列されたインスタンス一覧は、より確実に新興インスタンスをリストの先頭に表示するので、これまでに挙げたなかでは最も累進的である。

デフォルトの並び順ではないが、分散SNSフォーラムの新着順リスト は、インスタンスの開設が新しい順に配列されている。なお、分散SNSフォーラムの実装では、インスタンスの開設日時は、現存する最古のトゥートの日時で近似している。

ここまでのまとめ

インスタンス一覧を逆進性と累進性によって配列すると、以下の順になる。

  • (↑逆進的)
  • 登録ユーザーが多い順 (シュリンクラップ効果、大御所効果、正のフィードバック)
  • トゥートが多い順 (大御所効果、正のフィードバック)
  • 収録が古い順 (大御所効果)
  • 手動で作成されたリスト (シュリンクラップ効果、大御所効果)
  • 流速が速い順 (正のフィードバック)
  • ランダム (逆進性、累進性について中立)
  • 収録が新しい順
  • インスタンスの開設が新しい順
  • (↓累進的)

流速が速い順のインスタンス一覧は、逆進的ではあるが、インスタンスの活発さを反映しているという利点がある。そうでなければ、中立または累進的なインスタンス一覧を使うべきである。

逆進的な配列を逆順にすると累進的になり、累進的な配列を逆順にすると逆進的になる。そのため、理論的には、最も累進的なインスタンス一覧は、登録ユーザーが少ない順である。そのようなインスタンス一覧は知られていないが、作ってみるとおもしろいかもしれない。

2017年4月のマストドンブームにおいては、ユーザーの流入が多く、インスタンス一覧を参考にインスタンスを選択する機会も多かったであろう。その時点で存在したインスタンス一覧は、手動で作成されたリストまたは登録ユーザー数が多い順のリストであり、いずれもきわめて逆進的であった。この損失は永遠に埋め合わせることができない。

ユーザー一覧の累進性と逆進性

日本語圏においてインスタンスの一覧が乱立しているのに対して、ユーザーの一覧はあまり知られていない。自動化されたものでは User Localによるもの と 分散SNSフォーラムによるもの が知られている。手動で作成されたリストは いつもの匠によるもの が挙げられる。マストドンを始めたら誰をフォローすべきか? も参照。

また、ローカルタイムラインまたは連合タイムラインを流れてくるトゥートを見て、気に入ったユーザーをフォローするというユースケースを考えると、これらのタイムラインもユーザー一覧の変種であると考えられる。同様に、検索エンジン (マストドンリアルタイム検索tootsearch など) や、語彙が類似するユーザーを検索するシステム も、その逆進性と累進性をユーザー一覧と比較することが可能である。

なお、Mastodonおすすめユーザー検索は、本稿の掲載後にソースコードが公開されたため、逆進性と累進性の検討は今後の課題である。

フォロワーが多い順

最も逆進的なユーザー一覧は、フォロワーが多い順の配列である。第1に、あるユーザーをフォローするかどうか決めるとき、すでにその名前を聞いたことがあれば、フォローする見込みは大きくなる。すなわち、すでに何らかの手段で有名になっている人にとって有利な指標である。第2に、フォロワー数が過去からの累積であることである。過去に大量にフォロワーを獲得するだけの魅力があったとしても、現在それが維持されているとは限らない。単にフォロワーたちがフォローの解除 (リムーブ) を怠っているだけかもしれない。第3に、フォロワーが多い順に配列されたユーザー一覧を見て、それを参考にフォローするという行動をとるユーザーがいると、正のフィードバックが発生することである。これにより、少数のユーザーに多数のフォロワーが集中することになるであろう。

登録ユーザーが多い順に配列されたインスタンス一覧と、フォロワーが多い順に配列されたユーザー一覧にはアナロジーがあり、それらが逆進的である理由はほとんど同じである。

フォロワーが多い順に配列されたユーザー一覧は Mastodonランキング が知られている。

被ブーストが多い順

被ブーストが多い順に配列されたユーザー一覧は、フォロワーが多い順の配列と比べれば、逆進性は緩和される。なぜなら、トゥートをブーストするということは、実際にそのトゥートが魅力的であると判断したことを意味するからである。

逆進性の他の要因、被ブースト数が過去からの累積であることと、正のフィードバックを発生させることは、フォロワーが多い順の配列と同様である。

トゥートが多い順に配列されたインスタンス一覧と、被ブーストが多い順に配列されたユーザー一覧にはアナロジーがあり、同程度の逆進性がある。

デフォルトの並び順ではないが、Mastodonランキング は被ブーストが多い順に配列することができる。

有名人のリスト

有名人のリストは、セレブのインターネットそのものである。しかしながら、正のフィードバックが発生するおそれがないことから、逆進性は緩和される。

有名人のリストとして いつもの匠によるもの が知られている。ただし、作者自身がその限界を指摘している

連合タイムライン

連合タイムラインは、同じインスタンスのユーザーがフォローしているユーザーのトゥートと、同じインスタンスのユーザーのトゥートの和集合である。前者はフォロワーが多い順に配列されたユーザー一覧と同程度の逆進性があり、後者はローカルタイムラインそのものである。すなわち、連合タイムラインは、フォロワーが多い順に配列されたユーザー一覧と、ローカルタイムラインの中間の逆進性を持つ。

流速が速い順

流速が速い順に配列されたユーザー一覧は、これまで見てきたものよりは逆進性が緩和される。第1に、流速は、過去の蓄積を反映せず、現在の状態のみを評価する。第2に、過去の名声や知名度にかかわらず、誰でも努力次第で獲得できる指標だからである。

しかし、流速が速い順に配列されたユーザー一覧についても、その逆進性を指摘する必要がある。なぜなら、インスタンスの文化は、流速の速い少数のユーザーの慣れ合いによって形成されている側面があるからである。そのようなユーザーがインスタンスの文化と治安に貢献するところは大きいが、ある種のプチセレブであるとも言える。

流速が速い順に配列されたインスタンス一覧と、同じく流速順に配列されたユーザー一覧にはアナロジーがあり、同程度の逆進性がある。

流速が速い順に配列されたインスタンス一覧は 分散SNSフォーラムによるもの が知られている。

ローカルタイムライン

ローカルタイムラインの逆進性は、流速が速い順に配列されたユーザー一覧とほぼ同等である。なぜなら、流速が速い順に配列されたユーザー一覧は、一定時間あたりのローカルタイムラインのトゥートを数えているからである。ただし、流速が速い順に配列されたユーザー一覧が流速の数値のみを表示するのに対して、ローカルタイムラインはトゥートの内容を表示するので、逆進性はわずかに緩和される。

語彙が類似するユーザーを検索するシステム

語彙が類似するユーザーを検索するシステムは、内部のアルゴリズムが複雑であるので、逆進性を評価することが難しい。後述の検索エンジンとほとんど同等の逆進性を持つが、語彙が類似するユーザーを検索するシステムがユーザーの一覧を表示するのに対して、検索エンジンはトゥートの内容を表示するので、語彙が類似するユーザーを検索するシステムの方がいくぶん逆進的である。

語彙が類似するユーザーを検索するシステムとして マストドンユーザーマッチング が知られている。

検索エンジン

検索エンジンの逆進性は、ローカルタイムラインとほぼ同等である。なぜなら、トゥートの数が多ければ、検索エンジンでヒットすることも多くなるからである。しかしながら、検索に用いるキーワードによって、ヒットするユーザーは変化するため、逆進性はローカルタイムラインよりも緩和される。

マストドンを対象にした検索エンジンは、マストドンリアルタイム検索tootsearch が知られている。マストドン検索ポータル は有名だが、マストドン 2.0.0 以上のインスタンスを検索できないなど、不具合が多い。

ランダム

ランダムに配列されたユーザー一覧は、逆進性と累進性について中立である。

ランダムに配列されたユーザー一覧の実例は知られていない。

新着順

新たにマストドンを始めたユーザーの一覧は、これまでに挙げたユーザー一覧のうちで最も累進的である。

新着順のユーザー一覧の実例は知られていない。新規のユーザーに積極的に話しかける文化 (「しんかこ」と呼ばれることがある) は、これと同様の累進性があると思われる。

ここまでのまとめ

ユーザー一覧を逆進性と累進性によって配列すると、以下の順になる。

  • (↑逆進的)
  • フォロワーが多い順 (シュリンクラップ効果、大御所効果、正のフィードバック)
  • 被ブーストが多い順 (大御所効果、正のフィードバック)
  • 有名人のリスト (シュリンクラップ効果、大御所効果)
  • 連合タイムライン
  • 流速が速い順
  • ローカルタイムライン
  • 語彙が類似するユーザーを検索するシステム
  • 検索エンジン
  • ランダム (逆進性と累進性について中立)
  • 新着順
  • (↓累進的)

ランダムまたは新着順のユーザー一覧が知られていないのは驚くべきことである。ランダムは逆進性と累進性について中立、新着順は累進的であるのに対して、他の配列はすべて、程度の差はあるものの逆進的であるからである。

インスタンス一覧の乱立とも言うべき状況と比較すると、未知のユーザーを発見する手段そのものが未発達である。そのため、最も逆進的な、フォロワーが多い順のユーザー一覧でさえ、未知のユーザーを発見する手段として貴重である。いずれにせよ、もしそのようなシステムを新たに開発する機会があれば、できる限り累進的なデザインを採用することが必要である。

将来の構想

セレブのインターネットに対抗するイデオロギーとして、生存のインターネット (internet of subsistence) というアイディアを構想している。

インターネットにおいて情報が無料であることが常識であった時代は過ぎ去り、クリエイターがファンから現金を受け取ることができる仕組みが普及している。PatreonEntyファンティア などのマンスリードネーションプラットフォームは、毎月決まった額を寄付する仕組みであるので、単発の寄付と比べると、より確実に寄付金を集めることができる。マストドンの開発者とインスタンス運営者は、これらのマンスリードネーションプラットフォームで資金を得ている者が少なくない。知名度を換金するシステムである VALU や、物品を換金するシステムである メルカリCASH なども含めて、マネーのインターネットとも言うべき流行が形成されている。

しかし、マンスリードネーションプラットフォームで寄付を得るためには、クリエイターとして作品を発表するだけでなく、あらかじめ知名度があることが必要である。実際には、少数のインターネット有名人に寄付が集中する一方で、寄付金ゼロのクリエイターが大半を占めている。

寄付する側の可処分所得は有限なので、すべてのクリエイターが満足するような分配は不可能である。しかし、少数のインターネット有名人に寄付が集中することを避け、より多くのクリエイターに寄付を分配することは可能だろうか?

ここで、漫画家で、シェアハウス界隈の有名人でもある小林銅蟲の発言を見てみよう。小林銅蟲によれば、シェアハウス界隈に迎え入れられるためには本人に卓越した「面白さ」が必要であり、そうでない者は巧妙に追い出されるという。すなわち、シェアハウス界隈は、面白を生存に変換する装置であると言える。では、卓越した面白があるわけでもない普通のインターネットユーザーが、それでもなおインターネットでの活動を生存に変換していくには、どのようなデザインが考えられるだろうか?

生存のインターネットの一例として Reduce Go が挙げられる。これは、月額1,980円を支払うと、近隣の飲食店で余剰食品を受け取ることができるというシステムである。月額1,980円は決して安くはないが、食料調達の心配をせずに生きていけることの利点は大きい。

また、第2回分散SNSフォーラム で発表された 分散Uber、分散Airbnb、分散就活サイト などのアイディアも、生存のインターネットに近い発想である。

ここで、EntyとReduce Goのシステムを結合し、Entyの1,980ポイントをReduce Goの1ヶ月のサービスと交換できる機能が実現したとしよう。現金を介さず「ポイント」で決済することの利点として、銀行などの手数料が不要になることが挙げられる。また、複数のReduce Goアカウントを持っていても意味がないので、月に1,980ポイントを超える寄付を受けた者は、翌月に持ち越すか、それでも使い切れなければ他のクリエイターへの寄付に回ることになる。これにより、少数のクリエイターに寄付が集中することを避けられる。

マンスリードネーションプラットフォームで寄付を集めるためには、情報発信と宣伝の手段として、Twitterなどのミニブログが欠かせない。Twitterが衰退したり、過酷な言論統制を敷いたりすれば、マストドンなどの分散SNSが重要な代替手段になるだろう。このとき、少数の有名人に寄付が集中することを避けるためには、分散SNSが累進的なデザインを採用することが必要である。

結論

本稿では、セレブのインターネットとも言うべき現状に抵抗するため、ユーザーの脱中央集権というイデオロギーを提案した。そして、ユーザーの脱中央集権を推進するか阻害するかによって、デザインの累進性と逆進性を定義した。具体的な検討として、マストドンのインスタンス一覧とユーザー一覧について、それぞれの累進性と逆進性を評価した。

さらに、将来の構想として、生存のインターネット (internet of subsistence) というアイディアを提案した。生存のインターネットを実現するためには、インターネットを利用したアプリケーションを開発するにあたって、あらかじめ累進的なデザインを採用することが必要である。

建物をいきいきさせる、健康な洗っていたアライグマを洗うこともある。建物の内部でさまざまなものを鋭い爪で形成し、多い、いろいろな角度の、クリエイティヴなフナクイムシのようだった、洗っていたアライグマを、今度は私達が夜、洗う日が来るだろう。私の爪は尖っていて鋭く、きらきらとして塩水に濡れている。茶色い湿った生物がいるのだ。飼育するのは容易ではない。水槽から外に出てくる紫色のいきものが素晴らしい。細胞は感動的だ。健康な増殖する死なない殺さない、暗い塩味の塩水で、詳しく解析するような心持ちで、冷たい、冷えたアライグマを水に漬け、保存する、ゆっくりと動かす腕の動きは海水の動きを受信していた。 (小笠原鳥類「走査」)