やめておけ Wildebeest やめておけ (2023/07時点の情報です)
なんかやめとけやめとけとだけ言って理由を書かないのも微妙だなと思ったので書いておきます。
放置されている
まだ全然実装していない機能があるのに、現状3月27日から新しいコミットが積まれていません。もう夏ですけど。。。
Mastodon 以外の相互運用に難がある (らしい)
なんか Pleroma とかと連合できないらしいです。あと Misskey もフォローリクエストが通らないらしい。
現状の WebUI が雑
連合ユーザーの投稿のURLが間違っていて (https://host/@username/uu-id 決め打ち？？) Public Timeline の投稿を見るとどうあがいても 404 になります。なんで外から流れてきた投稿に勝手にローカルで採番したUUIDが使えると思ったんでしょうか？
Mastodon API のドキュメントに書いてあった ID 採番の約束事が守られていない
ここが一番書きたかったところです。
TL;DR
Mastodon の ID 採番は、
- 長さが短い方が若い
- 同じ長さであれば、辞書順にソートする
という仕様があります。 docs.joinmastodon.org
が、どういうわけか Wildebeest は投稿のIDを UUIDv4 (というか crypto.randomUUID()) で採番しているので、当然ながらこの条件を満たせません。(ちなみに アカウントID はそのまま acct user@server.example になっているのでこれも条件を満たしていません)
Mastodonの実装に従うなら Snowflake *1 を使うことになりますが、そうでなくても ULID とか UUID v1 or v6~8 のようなタイムスタンプベースの採番方法を使っておけばよかったのに……。
というわけで、どこかの 3rd-party app が正しく動かない可能性があります。
これに関してはもうインスタンスを立ててしまった人に関してはどうしてもマイグレーション不可能な部類の失敗である *2 ので、傷が浅いうちに別の実装を立てるか、元居たサーバーが現存するなら蜻蛉返りをすることを強く推奨します。
昔話 (興味がない人は飛ばしてください)
昔々 (v1.xまで)、Mastodon の ID は素直に 1 ずつインクリメントされる素直なIDで、APIでも数値として渡ってきていました。
ところがそれが Mastodon 2.0.0 で Snowflake 移行と同時に 64-bit int が10進数で入る string になりました。これは Twitter が API の id_str でやっていることと同じで、JSON に 32-bit を超えた int を格納する手法としては一般的です *3
All id attributes in the REST API responses, including attributes that end in _id, are now returned as strings instead of integers. This is because large integers cannot be encoded in JSON losslessly, and all IDs in Mastodon are now bigint. Some apps will not work with this release until they are updated
で、ここから2年ほど、みんなが id は 64-bit int が10進数で入る string だと想定して実装していました。
が、時は過ぎ2019年1月、Pleroma という Mastodon API 互換実装を持ったソフトウェアが同じようにタイムスタンプベースの採番を採用しました。しかし、彼らはなぜか数値を10進数でstringに入れるのではなく、62進数でstringに入れることにしました。
Flake Ids for Users and Activities (!645) · Merge requests · Pleroma / pleroma · GitLab
当然10進数の 64-bit int だと想定していたアプリたちは壊れ、Pleromaユーザーが Mastodon クライアント作者に文句を言いまくるなど、結構いざこざがあったのですが、結局 Mastodon 側がドキュメントで折れる というオチで終わりました。
(当時は source.joinmastodon.org でホストされていたはずですが消滅しているので merge request のログがない)
結局前述の仕様に収まったんですが、Wildebeest はそれをガン無視して実装していったのでかっこいい (悪口) ですね、という話でした。
というわけなので、Mastodonクライアントが Wildebeest で壊れていても、Mastodonクライアント側に文句を付けないでください。ガイドラインを無視しているのは Wildebeest 側です。
結論
現状の Wildebeest は外部投稿へのリンクもまともに貼れていないし ID 採番で致命的なミスを犯している上に更新も止まっているので、立てちゃった人は今からでも Mastodon とかを立て直しましょう。ただし、同じ(サブ)ドメインでデータに連続性がない ActivityPub サーバーを立てると外界からの認知が怪しくなるので、別のサブドメインを使うことを強く推奨します。 ドMなら Wildebeest を改善するのもいいかもしれませんが、結局既存のめちゃくちゃなID採番はどうしようもないので………。
個人的に一番オススメできる ActivityPub 実装は Mastodon です。実装自体は Misskey とか Pleroma とかまあ他にもいろいろありますが、どれも絶妙におすすめできない理由があります。
サーバー管理が苦でないなら Vultr とか Linode とかで $5 のVPSでswap付ければ動きます (が、オブジェクトストレージに画像を上げる設定にしておいたほうがいいです)。ただこのスペックだとその場でビルドができるかは怪しいので、Docker の公式イメージを使うのがいいでしょう。$10 とか $20 とかにすると快適度が増すので、資金に余裕があるならもうちょっと払っておくと幸せになります。
サーバー管理なんてしたくないやい！という人は https://hostdon.jp などのホスティングサービスを使うか *4 、適当に信頼できそうな人がやってるところに逃げ込むのが良いんじゃないでしょうか。海外の人とも交流したいなら、二次(特にロリ)エロに寛容なところ (e.g. pawoo.net とか misskey.io とか) は海外からブロックされがちなので避けたほうがいいです。
