ディスプレイを新調したらWhalebirdに満足できなくなったので新しくFediverseクライアントを作っている

この記事はFediverse (2) Advent Calendar 2022の7日目です.

最近34インチのウルトラワイドディスプレイを買ったんだけど,これによって俺の作業スペースは格段に広がった.Emacsは常時3分割or4分割だし,1ワークスペースにブラウザとターミナルを表示するのは普通.むしろ1アプリで1ワークスペースを専有させるものはほとんどなくなった.と同時に,Whalebirdの情報密度をもっと濃くしたくなった.

Whalebirdは当初からシングルカラムのMastodonクライアントだ.ただし最近はいくつか不満な点があって,

  1. 画面幅が3440x1440なので画面に対して表示される情報量が少ない
  2. 他のサーバや他のTLを開くときにいちいち読み込みが走るのが面倒
  3. (これは日本人だけかもしれんが)そもそもみんなそんなに長いポスト,してないんだわ.みんな「ゆれ」とかしか投稿しないのに,この横幅いらなくね?

というわけでマルチカラムのクライアントが欲しくなった.

Whalebirdをマルチカラム化することも考えたが,

  1. 現状のコードベースをきれいにしたいところがかなりある
  2. Vue.jsをもうあまり書きたくない
  3. そもそもマルチカラムに耐えうる設計じゃない

と思ったので新しく作ることになった.

はい,こんな感じです.

リポジトリはこれ.

github.com

機能面でいうと,

  1. 認証せずにサーバを追加できる.この場合見られるTLはpublicとlocalのみで,リアクションもできない.が,TLを覗くだけということができるようになる
  2. 投稿するアカウントを選択できる.ただしリプライ時にここをどうするかは検討中
  3. Mastodon/Pleromaには対応済み.Misskeyどうするかね?
  4. あとは普通のマルチカラムクライアントの機能……はまだ全然足りてないが

今後実装したいもので,優先度の高いものはissueにしているが

github.com

ここに書いていないものだと

  • RT, fav等のリアクション時に,どのアカウントで行うかを選択できるようにしたい……?できるのか?
  • 通知件数をmarkerから読むようにしたら未読件数を表示できる……?かなぁ?
  • サーバ/アカウントごとの通知に一発で飛べるようにしたい
  • アイコンほしい

WhalebirdはElectronで作っていたが,実はこいつはtauriで動いている.だからたぶんWhalebirdより軽いんじゃないかな,計測してないけど.メインプロセスはそりゃー軽いだろうが,レンダリング部分は正直何をレンダリングしているか(=TLに今何が表示されているか)に強く依存するので,何を比較したらいいのかよくわからん.同じTLを表示するだけならtauriのほうが軽いんじゃないかね.ただ,そもそもシングルカラムとマルチカラムでは同時に表示されるTLの数も違うので,比較するのに意味があるのかわからん.原理的にはfedistarのほうが重くなるはず(今の所TLの数を無限に増やせるので).

で,tauriはメインプロセスをRustで動かすわけだが,このためにmegalodon(Whalebirdのために作ったMastodon/Pleroma/Misskeyのクライアントライブラリ)をRust対応させた.これだけでひと月くらい費やしたけど.

github.com

メインプロセスでFediverse APIを叩くかどうかという疑問もあるのだが,俺は叩くことにした.というか,WebSocketのストリーミングをフロントエンドで維持するのかメインプロセスで維持するのか,どちらが良いか考えた末にメインプロセスでやらせることにした.おそらく多少はこのほうが軽くなるはず. もちろんフロントエンド側でFediverse APIを叩く部分は従来どおりmegalodonを使っている.同じライブラリなのでEntityは互換性をもたせている.そのためバックエンド - フロントエンド間でEntityのやりとりをするときも,そのままEntityを送りつけることができる.

フロントエンドはNext.jsにしている.Reactにしたのは,Vue.jsを書きたくないというのもあるし,周辺ライブラリやエコシステムが豊富だというのもある. 例えばこういうクライアントを作る上で考慮するのはバーチャルスクロールなのだが,SNSのタイムラインを構成するバーチャルスクロールというのはかなり複雑である.

特に上方向にスクロールしてステータスが積み上がるタイプのもの(Slackみたいなやつね)はかなり難しい.巷のinfinity scrollはだいたい下方向にスクロールする(これがデフォルトの挙動).この場合,ある程度下まで来たら追加読み込みをしてエンティティをリストの末尾に追加するだけで良い.ブラウザはエンティティが更新された場合,scrollTopを維持した状態でリストを更新する. しかし,この挙動は逆向きスクロールのときに非常に困る.上方向にスクロールしてエンティティが積み上がるということは,リストの末尾ではなく先頭にエンティティが追加される.となるとscrollTopを維持したままリストを更新したら,見ているエンティティが一気に入れ替わることになる.Slackを想像してもらえればわかりやすいが,これは許容できない.というわけで,上方向にエンティティが積み上がるときにscrollTopを維持せずに,というかスクロール位置を変えずにリストを更新する必要がある. こんなことができるライブラリはVue.jsには存在しない.

しかしReactであればいくつか選択肢があり,

tmegos.hatenablog.jp

この中から用途にあった開発が活発そうなものを選べる. これに限らず様々なライブラリでVueよりReactの方が選択肢が豊富だ.

その上Vue3になってから,そこまでReactに対してメリットがあるような記述でもなくなってしまった.結局hooksを使うReactの二番煎じみたいな状態になっており,これならReactを使うほうが良い.

ちなみにまだバージョンは0.2である.つまり安定版ではない,そんなものは存在しないのである. 少なくとも1.0にならなきゃMac App Storeには出せないわけで,そのくらいのバージョンになったら安定版だと考えてほしい.それまでは思う存分破壊的変更を入れるので,怖いものが見たい人だけがダウンロードしてくれ.そういう意味も込めて,基本的にはgithub releasesでしかバイナリを配布していない.snapcraftとかhomebrewとかMac App Storeとか,そういう「いかにも使ってください」みたいなところにはまだ出していないし,1.0が見えるまでは出すつもりはない. ただし,AURにはすでにある.Arch Linuxユーザなら,多少ぶっ壊れたソフトウェアとか,互換性がまったくないバージョンアップとか配布しても,許してくれるかなというイメージを勝手に持っているので出している.壊れたら消して入れ直してくれ. そしてリリースのchangelogはちゃんと読んでからインストールしてくれ.破壊的変更が入るときにアナウンスは書いているので.

あと,まだ0.2なので足らない機能が盛りだくさんである.そもそも0.1.0リリース時点では,TLが見られるだけで投稿が一切できなかった.今でも上記の通りリプライはできない.アカウント選択をどうするかが悩み中なのでそれが決まり次第ということになる.そういうのは順々に追加していくんで…….

ちなみにバグレーポートはほとんど募集していない.というか,なにか不都合があったとして,それはバグじゃない,未実装なだけだ.ありとあらゆるものは未実装であり,バグっているわけではない.なのでPullRequestは随時募集しております.

Q&A

The DeskとかSengiじゃだめだったの?

俺は俺の作るクライアントでFediverseをやりたいのでだめです.Fediverseがやりたいっていうかむしろクライアントが作りたいんだよ.Twitterはクライアント作らせてくれないし,そういうところが嫌で家出したのだから,Fediverseにきたら自分でクライアントを作りたいんだよ.

とはいえ差別化とかないの?

知らん. ビジネスなら差別化しないとシェアが奪えなくて売上が上がらないかもしれんが,これは無料だ.俺の趣味だ.シェアなんかどうでもいい.差別化なんぞ知るか.俺の好きな機能を好きなように実装させろ.

Whalebirdどうするの?

最初は置き換えることも考えたが,シングルカラムクライアントの需要がある限りは続けます.まぁ更新頻度が下がることはあり得る. ただ,マルチカラムをfedistarで実現できそうなので,Whalebirdはもう少しシンプルにしたいとは思っている.まず,最初に書いたアカウントやTL切替時のローディングはもっと短くできると思っているので,もっとスムーズに切り替えられるようにしたい.その他,結構言われるがまま実装したものもあるなーと思っていて,機能を削りたいとは思っている.

いつ安定版になるの?

わからん. PRを送ってくれると多少その時期が早くなるかもしれない.

Android版とかiOS版とか?

ない. 作る予定もない.というかモバイルでマルチカラムはいらんだろ…….別で開発したほうがいい.

そういえばアイコンもまだない

アイコンをどうしようか考え中なんだけど,俺にはアイコンを描く技術はない.ので誰かに頼まないといけないのだが,あんまりデザイナーの友達もいないので,もし描いてもいいよって方がいたら連絡ください.お金は払います.

@h3poteto@pleroma.io

大事なことなのでもう一度書くと,お金は払います