タイトルの通りのことを行った．
その代わりと言ってはなんだけど，Firefishのサポートを開始している．
WhalebirdからもMisskeyサポートがなくなる
megalodonはWhalebird，Fedistarからもクライアントライブラリとして利用している．当然，WhalebirdからもMisskeyは使えなくなる．Fedistarは最初からサポートしていなかったので関係ない．
とりあえず，まだこのへんの終了対応はしていないんだけど，次のバージョンアップで完全に切ろうかと思っている．
理由とか
クリティカルな大きな事件があったわけではないんだけど，少しずつ積み重なってこういう決断に至った．
APIの変更頻度がそれなりに高いのにドキュメントがクソ
Misskeyは今年になってからドキュメントページをリニューアルしている． そして，今のAPIドキュメントはここだ．
俺がこの件で悩んでいた5月くらいは，そもそもエンドポイント一覧のドキュメントすらなかった． 今は一応全部リストアップされているが，それでもすべてのレスポンスが記述されているわけではない．
例えば， /users はユーザの一覧を返すが，UserDetailedのページは存在しない．
そもそもMisskeyは，/notes 系のAPIのレスポンスであるNote に含まれるUserと， /users 系のレスポンスである UserDetail が別物であり，この辺のハンドリングは非常に苦労する．
エンティティという概念が希薄であるとしか思えない．
にもかかわらず，ドキュメントにエンティティの情報がないので，結局全部自分でAPIを叩いて確認しないといけない． megalodonで最初にMisskey対応をしたときも，（リニューアル前のAPIドキュメントだったが）ドキュメントに乗っているレスポンスと，実際に叩いた際に帰ってくるレスポンスが違うことがよくあり，結局ほとんどcurlしながら開発した．
更新頻度の低いソフトウェアなら，「まぁそんなにコントリビュートしてくる人もいないのかね」と同情したくなるが，これでいてAPIの破壊的変更はそれなりにある． つまりコントリビュートしている人にとっては，APIドキュメントはそんなに重要ではなく，サードパーティー製のアプリケーション開発者も大して大事じゃないだろう．
Misskeyサポートを要求する人は別に手伝ってくれない
そういう経緯があって，Whalebirdもmegalodonも，Misskeyの新APIに対応するのが遅れていたりしてIssueが立ったりしていた． が，前述の通りドキュメントが当てにならないので，変更されたAPIについてはソースコードを読むかcurlしてまた実際のレスポンスを確認しながら修正する必要がある．
これに手が回らなくなって
こういうIssueを立てたのが4月． 5ヶ月経ったが，メンテなの立候補どころか上記の件に対するPRもない．GitHub Sponsorが増えるわけでもない．
みんな新機能への対応は要求するけど，手を貸すのは嫌だということ，自分でコストも負担したくないということ．
絵文字の変更が破壊的すぎた
おそらくv13あたりからだと思うけど，Emoji reaction周りにかなり大きな変更が入った．
reactionEmojis にリモートの絵文字情報は入るようになっていたのだが，ローカルで登録されているカスタム絵文字に関する情報が Note エンティティに存在しない．
これはおそらく別のAPIを叩いて，サーバのカスタム絵文字一覧を取ってきて，クライアント側で合致させる必要があるのだろうが，これが致命的だった．
megalodonはNode.jsとRustで提供するクライアントライブラリだ．これ自体をアプリケーションとして利用する人はほぼいない．
だから，例えばWebSocketでNotificationを受信したとき，内部の絵文字情報を取得しようとすると，それだけでは情報が足らない．かと言って Note をパースするたびに絵文字一覧APIを呼び出すのは非効率だ．
いや，サーバのことを考えなければ毎回呼び出してもいいのかもしれんが．
まぁMisskeyの開発チームは，WebUIを主眼に開発しているわけで，APIの使い勝手というのはWebUIを作りやすいようにしているのだろう． だから，きっとWebUIはこれで使いやすいのだろうが，クライアントライブラリとしては，ほぼ対応不可能になってしまった．やろうと思えば，事前に絵文字一覧を取得して，どこかに保存して……ということもできなくはないのだろうが． それをやるほどのモチベーションはすでにないし，誰か別の人がやってくれそうにもない．
Misskey.ioの邪魔はしたくない
Misskeyサポートを求めている人の87%くらいはmisskey.ioを使っているんじゃないだろうか．そのくらいMisskeyの中でioは勢いがあると思うけれど，ioの運営は最近法人化した． これだけのユーザ数を支えるのにかなりのコストを払っているはずで，ioには広告も導入されている．
別にioに特に思い入れがあるわけじゃないんだけど，3rd partyのクライアントは広告と相性が悪い．広告専用のAPIがあるわけでもないし，広告をいれなきゃ使えないわけでもない． となると，当然Whalebirdにはioの広告は表示されないわけだけど，これは一面ではioの運営を邪魔していることになる． Whalebirdがサポートを止めたところで，他のクライアントがサポートしてたら，みんなそっちを使うだけなのかもしれないけど．それでも邪魔はしたくないと思った．まぁ，これは言い訳に近いけど．
Firefishのサポートをする
代わりと言っては何だがFirefish (Calckey) のサポートを開始する．
作ってみた限り，こっちのほうがAPIドキュメントは親切で，一応ちゃんとドキュメント通りのレスポンスが帰ってくるし，不足しているエンティティはたぶんない．
ベースが同じなので， User と UserDetail が別物だとか，そいういクソな部分はまだ少し残っているけど，以前のMisskeyクライアント部分をかなり流用して作ることはできた．
まぁRust版の方はベースが存在しなかったので，全部初めから作ったのだが．それが作れるくらいには十分なドキュメントだったように思う．
まとめ
結局OSSというのは，みんな無料だから使っているだけで，そこに自分でコストを払って参加したり，Sponsorになったり，そういうことをする人は稀なんだろう．そして有料化したら，みんな使わないんだろう，どうせ． なので，たとえ要望が来たとして，俺が使わない機能に関して「俺は実装しない」という方針で行こうかと思っている．もちろん欲しい人がPRを送ってくる分には歓迎だけど．
WhalebirdやFedistarを有料化することも考えたけど，有料化するのはそれはそれで，「ユーザが求めている機能を実装しなきゃいけない」圧力を感じてしまうので，止めた．
さよならMisskey
