fediverseで見かけたネタ。ちょっと考えてみたらよくあるこの手のものとは違う帰結になりそうな気がする（ような前提を置ける）のが面白そうだったのでちょっとここに書いておく。

https://mozilla.social/@taku0/112507954617690585

99人の人狼と1人の人間が暮らす村がある。
この村の住人は皆、誰が人狼で誰が人間なのか知っている。自分自身がどちらかなのかを除いて。そのことは全員がよく知っている。
また、古くからの掟として、人狼は深夜に人間を襲わなくてはならないということもよく知られている。

この村の住人は皆、相手が人間であるかのように振る舞っていた。もしも自分が人間だった場合、相手が自分が人狼だと自覚した夜に襲われてしまうからだ。
そうやってこの村の住人は平和に暮らしていた。しかし、その平和は長くは続かなかった。
ある日この村に恐ろしい狼の神が現れ、「この村には人狼がいる」と告げて去っていった。

リプライでリンクされているが、 https://ja.wikipedia.org/wiki/%E5%85%B1%E6%9C%89%E7%9F%A5%E8%AD%98 のようなパズルの一種として解釈できる、が、人狼と人間という関係性があるので少し違った振る舞いになるんじゃないかというふうに思う。

まず基本的な前提は次のようなものだ。

1. 村人は人狼か人間かのどちらかである
2. どの村人も、自分が人狼か人間かは知らない
3. どの村人も、他の村人が人狼か人間かは知っている
4. どの村人も、条件3（他の全ての村人は自分の正体を知っている）ことを知っている
5. 村人は、自分が人狼であるとわかったらその日の夜に人間を襲わなければならない。襲われた人間は死ぬ
6. 自分が人狼であると確信を持てない人は人間を襲わない
7. 村の中に少なくとも一人は人狼がいることがわかった

こんなところかな。一般的な人狼・人間とは違うしそんな条件が成り立ちうるのかなという気がしないでもないけど、ひとまずこの条件が成立している場合にどうなるか、と考えることにする。またこの手のパズルの前提として「8. 全ての村人は同等に論理的に推論でき、論理的に行動するし、全ての村人は他の村人がそうであることを理解している」とする。

もし村人が2人であり、一方が人間でもう一方が人狼だとするとどうなるだろうか。人狼からは人間の村人しかいないので自分が人狼であることが確定する。したがって条件5によりその日の晩に人間を襲う。人間は自分が人間であるか人狼であるかはわからない。もし自分が人狼であれば自分は襲われないが（人狼は人狼を襲わないので）、人間であれば自分は襲われて死ぬことになる。したがって翌朝には人間は死んでいる、というのが良くあるパズルの解である。

でもそうなんだろうか。人間の側からすれば襲われて死ぬ可能性があるのに放置するものだろうか。自分だったら逃げる気がする。もしそうだとすると、村人が2人の時は「その日のうちに人間の村人は逃げ、人狼ひとりの村になる」なんじゃないか。

つまりここで自分は新しい条件を置いている。それは「9. 誰でも死にたくないので、もし自分が襲われる可能性が少しでもあるなら村から逃げていなくなる」というものだ。かぶっている帽子の色とか目の色とかと異なり、人狼と人間だと人間側は死ぬことがあるので、パズルとしてはそこに非対称性ができてしまうのではないか、ということです。

次に村人が3人（人狼2vs人間1）の場合はどうなるか。この時、人狼の側からすると人狼1と人間1が見えている状態である。もし自分が人狼なら問題ないが、もし自分が人間であるなら、自分から見えている人狼にとっては人間2の状態に見えるので自分が人狼であることが確定され、自分は襲われる可能性が捨てきれない。したがって逆に人狼2人がその日のうちに逃げ出すことになる。人間1にとっては自分が人狼でも人間でも人狼がこちらを襲う行動はとらないことがわかるので、残る。

村人が4人の時。人狼からすると人狼2vs人間1に見える。もし自分が人間だとすると、上記の推論により人狼2は逃げ出すはずである。そこで1日待って様子を見るが人狼たちは逃げ出さない。このことにより自分が人狼であることが確信できるので2日目の晩に人間を襲う行動を取れる。人間からは人狼3が見えており、もし自分が人間であるなら上記の行動が推論できるので、1日は待つが2日目のうちに逃げ出す行動をとることになる。

村人が5人の時。人狼からすると人狼3vs人間1である。上記の推論により、もし自分が人間であるなら人狼から見えている他の人狼3は村人4人のケースと同様から2日目の晩に人間を襲うはずである。したがって人狼は2日目のうちに逃げ出して人間が残る。

村人が6人の時も同様の議論から、3日目のうちに人間が逃げる。

というふうに、村人の総人口が奇数か偶数かで振る舞いが変わるのではないか。この場合には村人が全部で100人だと50日目に人間が逃げ出すことになる。が、もし99人だと49日目のうちに人狼がみんな逃げてしまい人間1人がポツンと残ることになるのだろう。

もちろんこれは上で私が勝手に置いた前提に基づいた議論なので、違う前提なら結論は変わることになるはずである。人狼ゲームみたいに他の村人を攻撃できるなら全然違った話になるでしょう。自分が襲われる確率によって振る舞いが変わるならまた違った話になるかも。

でもまあこんなちょっとした前提の違いで結論が結構変わってしまうのは面白いのではないか？と思ったのでここでこうして書き下してみた次第。

あと当然ながらこれはパズルなので、現実的にそんな行動を取りますかという話はしていませんので悪しからず。

ある時期からちょっと自分用のactivitypubサーバを立ててみたいという気持ちが高まってきたので、ようやくやってみた。

ソフトウェアとしてはmastodonではなくpleromaを使うことにした。理由は、なんとなく面白そうだから。そのせいで無駄に面倒なことになっている気もするが。

サーバとしてはGCPでE2-microインスタンスを借りて使うことにした。0.25コア1GBメモリのburstableインスタンスだ。burstableなので高負荷時には遅くなりそうだが、自分の個人用途では今のところ大丈夫そうである。値段は$7/月くらい。趣味としてはまあまあのお値段ではある。f2-microの方が安かったしメモリもそれで足りそうなので、そっちの方がよかったのかもしれん。まあ今はこれでいいです。

インストール作業はとりあえず https://docs-develop.pleroma.social/backend/installation/otp_en/ をなぞるだけなのでそれほど困らない。ただ libssl-1.1 が apt 経由で入れられないのでちょっと難儀した。S3の設定はしていない。メールは（使わないと思うが）一応アカウントあったのでmailgunの設定を付け加えている。

実際に使っていて、特に負荷のない平常時でCPU利用率は5%くらい（0.25コアというのは平均使用率で、実際に見えるのは1コアなので0.05コアくらいということ）、メモリは20-30%くらい（200-300MBくらい）。PostgreSQLも走っているのでこれに追加はあるが、負荷としては全然大したことない。

インストールしてみて、ひとまずすんなり動いているので、さっさと旧アカウントからの移行を行なった。と言ってもmastodon / fediverseにおけるアカウント移行というのは、

• エイリアス設定（新しいアカウントから旧アカウントへ言及する）
• フォワード設定（旧アカウントから新アカウントに転送する）

というだけで、これは基本的にフォロワーを移行させるという効果しかない。旧アカウントをフォローしている人は新アカウントにフォローを付け替えられる。自分自身のフォローについては移行されないので手動でインポートする必要がある。また投稿自体は移行されず、空っぽのタイムラインから再構築しないといけない。これはfediverse全体でそういうもののようだ。

pleromaを使っていて意外に思った点：他サーバの投稿はfav/reshare/replyが全く見えていない。

どうも手元のサーバにある投稿についてだけ計上されるみたいだ。つまり基本的には自分がそういうものをつけたかどうかという0/1の情報以上のものは出てこない。他サーバ上でのリプライやfavの情報は取ってこないようになっている（？）ように思われる。

そういうものをみたい場合、投稿元のサーバにアクセスすれば情報は読めるから、一切アクセスできないというわけではない。自分はフロントエンドはphanpyを使っているが、phanpyの場合はメニューから簡単にアクセスできる。でもメニューを開いてクリックするという2クリックが必要になるし、そもそもリプライがあるのかどうかもわからない状態でそれをあえて確認するかというと結構な手間ではないか、という気がする（pleromaの標準フロントエンドでもメニューを開いてexternal sourceに移動すれば読める。クリック数は同じだが、pleromaの場合は実際に相手のサーバのURLを開くのでページロードのぶん遅い）。

それに「フォローしているアカウントに対するリプライ」に反応することができない。つまり私のフォローするAさんに、私のフォローしていないBさんがリプライしていたとする。このBさんのリプライは私のサーバには来ていないので見えない。上記の方法でAさんの投稿の所属するサーバに移動すると読めるが、そのBさんのリプライはAさんの所属するサーバの投稿なので、私からはreshareとか再リプライとかができないわけだ。そんなに困ることはない気もするけどちょっと直感的ではないように感じる。

ちなみに一方で、「フォローしている人が他の自分のフォローしていない人にリプライした投稿」の場合はリプライ元も読め、反応できるようになっている。ややこしいけど、自分はAさんをフォローしていて、AさんがBさんの（公開された）投稿にリプライしているとする。すると、Aさんのリプライと、元のBさんの投稿はどちらも自分のサーバに保存されるので、Bさんの元投稿に対しての各種操作が許されるようになっている。

この組み合わせで、A->B->A->Bみたいにリプライの応酬があったとすると、一つ目のBさんのリプライは見える（Aさんがリプライ仕返しているので）が、二つ目のBさんのリプライは見えない、みたいなことが起こったりする。さらにAさんの最初の投稿についた別のCさんのリプライも見えない、みたいになったりする。めちゃややこしい。

同様にフォロワー・フォロイーもほとんど情報がない。例えば私がAさんをフォローしているとして、Aさんのアカウント情報を自分のサーバ上で表示させてみる。するとフォロワー数とかフォロー数とかは正確に出ているが、実際に誰をフォローしているのか、どんなフォロワーがいるのかを確認しようとすると自分以外は一切出てこない、といったことが起こる。これも自分のサーバ内のDBには情報がないからであろう。もちろん当人の所属するサーバに行って表示させれば出てくるからそんなに問題はないのかも知れない。でもこれもfindabilityが低い気がして今ひとつだなという気もする。

前使っていた普通のmastodonではこういうことはなかったように思う。設計思想の違いというやつだろうか、それとも前のサーバは大規模なので単に気づきづらかっただけなのだろうか。単に気づいていなかっただけという気もするが、一方でpleromaは軽量を自称している関係である程度の割り切りもあるからではないか、という気がしている。同じActivityPubサーバでもそういうところに違いがある（ありうる）というのはあんまり考えていなかったので興味深い。基本的にはちょっと不便だなと思っているが、投稿が限られていて静かな雰囲気はあってこれはこれで悪くないかもという気もしないでもない。いやまあでも不便は不便だな。

それにしてもサーバを動かして公開するのって久しぶり。しかし、正直にいうともうそういうことあんまりしたくないという気持ちはある。最初にセットアップしてソフトウェアを起動するところまでは全然問題ないんだけど、ソフトウェアをアップデートしたりとか、証明書の更新とか、もうなんか面倒だなと思ってしまう。そういうのはクラウドプロバイダに任せてAppEngineみたいなのでソフトウェアを動かしたい、という気持ちが強い。その方が（個人用途だと特に）安くなるだろうし。AppEngine + firestore + blobstore or google storage みたいな構成のactivitypub対応ソフトウェアはないんだろうか。AWS ECS + Aurora + S3でもいいですけど。

もちろん探せばあるんだろうけど、そういうものが特に人気ということでもない、というのはちょっと不思議。ものすごく時間があったら自作を試してみたい気もするけど、そんな時間はないかなぁ……activitypubのプロトコルはかなり複雑そうだし、上記のようなあれこれを考えるにやるべきこともかなり大掛かりなものだろうな。

そういえば、かつてcloudflareが開発したwildebeestっていうソフトウェアがあって、これはこういう自分のような人間には向いているよな、最近あんまり噂を聞かないけど、と思って見に行ってみたところ、噂を聞かないどころかプロジェクト自体がいつの間にかアーカイブされてしまっていた。残念。