これのFediverse版を作った．
https://koogawa.sakura.ne.jp/hb/rss.php?id=h3poteto
こちらで公開されていたRSSが非常に有用だったのでそのまま使わせてもらっています．おそらく個人運用のサービスなので，提供先のRSSが終了したらこの方法は使えなくなります．
続きを読むFediForumでWhalebirdとFedistarの話をしてきた
3月29日＆30日にFediForumというイベントがあり，そこでライブデモをしてきた．
オンライン開催だったが，UTC 15:00スタートというスケジュールだったため，JST 24:00スタートとなる．つまり，厳密に言うと3月30日0:00スタートだった． 終わり時間がJST 29:00で，流石にこの時間まで起きているのは無理で，28:00くらいまでで撤退した．
いずれ動画が公開されるらしい．
ライブデモの話
そもそもこのイベントはちょっと特殊で，CFPの募集等はしていなかった．当日にみんなで集まって話したい人がアジェンダを書き込んでその日のプログラムを決める．ただし，Demoだけは別で，これは事前にプログラムが組まれていた．
そういう形式だったので，別に俺が応募して発表したわけではない．予めオーガナイザーからメールが来て「デモしてみない？」というお誘いが来ており，それに答えてDemoをしたということになる． 他にも俺と同じように声をかけられたであろう数人が，なかなかに面白いデモをしていた．
FediForum | Demos at FediForum
デモは5分で，全編英語だった．というかそもそもアジア圏からの参加者はほぼいなくて，USおよびヨーロッパ近辺の人が多かったように思う．当然のように英語であった．
5分という発表時間は結構短くて，発表してみるとなかなか一つふたつ程度のトピックしか話せない．そういうのは日本語でも経験があるので，予め話す内容は決めていた． だいたい，
- 5分ならほぼ完全に原稿を作っておく．なにかミスったら時間が絶対に足らなくなるので，削る覚悟はしておく．
- 15分程度なら割と適当に話す内容だけ決めておけばなんとかなる．ミスっても時間的にはリカバリーが効く．
- 20分以上（だいたい40分とか50分セッションとか）の場合は時間調整のためのコンテンツを仕込んでおくと便利．
というイメージだったのだが，これはだいたい英語でも同じなんじゃないだろうか．
一応英語はともかくとして，デモ自体は特に失敗なく見せたいものは見せられたと思う．
その他のセッション
発表というよりは，みんなで話し合いというのが近かったように思う．もちろんアジェンダを出した人が仕切っているので，その人が多めに自分の意見を言っている部屋もあったのだが，だいたいは「みんなどう思う？どうしたらいい？なんか知ってる？」みたいな振り方をされて，みんなで意見を言い合って話し合う場が多かった．
Mastodon以外のFediverseサービスの話をしたり，クライアントアプリの話をするのは楽しかった．
結構結論のない話もいっぱいあって，FediverseでIDの認証をどうするか，というかつまりはなりすまし対策で，そのアカウントが本当に本人であるかどうかを誰かが保証できるのか，みたいな話は面白かったのだが結論はとくにない．Keybaseみたいなものでやるしかないのかなぁ．
もちろんActivityPub以外のProtocolの話もあって，Nostrの話とかも出ていた．
Native DependencyがあるElectronアプリをビルドする
Electronでsqliteを使いたくなった場合，
とか
とかを使うと思う．これを組み込んだ状態でアプリをビルドするときに，かなり詰まったので記録しておく．
成果物と同じプラットフォームでビルドする場合は問題なし
たとえばLinuxでLinux用のビルドをするとか，WindowsでWindows用のビルドをするような場合，特になんの問題もない．上記のライブラリはどちらもnative dependencyになるのだが，同じプラットフォーム向けなのでビルドされたバイナリもそのまま動く．
問題はそうではない場合が，かなりきついという話．
MacOS x64でarm64向けのビルド
ここがかなり詰まった部分になる．今まで，
- DMG: electron-builder + electron-notarize
- AppStore: electron-packager + electron-universal + codesignコマンド
でビルドしていた．electron-builderは，archを指定した場合にはarchごとにrebuildをしてくれている．しかしelectron-packagerは本当にパッケージングするだけなので，x64マシンでビルドした成果物はarm64では動かない．arm64向けにnative dependencyをrebuildしなければならず，electron-rebuildを使って
こいういうことをする必要がある．そのため，最初に失敗したのはAppStore版であった（後にDMGも結局動かないことが発覚したので，いずれにしろ今までの設定ではダメなことに変わりはなかった）．
同時に複数の問題が発生しており，時系列順に書くとかなり複雑なため，時系列をすっ飛ばして発生した問題を整理する．問題点が4つある．
問題1: electron-osx-signでAppStore版をcode signingするとローカルで起動できない
electron-builderでもelectron-packagerでも良いのだが，ビルドしたあとにcode signingする必要がある．DMGとして配布するのであれば Developer ID Application: YOUR_NAME(TEAM_ID) という証明書でcode signingできれば良い．
AppStore版の場合は 3rd Party Mac Developer Application: YOUR_NAME(TEAM_ID) という証明書を使う．
DMG版はelectron-osx-signでcode signingしたあと，普通に起動できるのだが（当然だ），AppStore版については EXC_CRASH (SIGKILL (Code Signature Invalid)) というエラーによりエラーがでて起動できない．これを避けるためにもともと electron-packager + codesignコマンドを使っていた．
参考: https://github.com/h3poteto/whalebird-desktop/blob/4.7.4/appStore.sh
が，どうやら，electron-osx-signにおいてこの挙動は想定内であり，通常の挙動らしい．つまりAppStore用のビルドはAppStore経由出ない場合には起動できない．ではどうするかというと，ProvisioningProfileとともにcode signingした上で，AppStoreConnectにアップロードし，TestFlight経由でインストールすると起動する（その他の設定が正しければ）．
というわけで，この時点でelectron-packager + electron-universal + codesignコマンドを捨てて，electron-builderでAppStore版もビルドすることにした．
問題2: native depencencyの成果物もcode signingしないとエラーになる
どういうことかというと，node-sqlite3もbetter-sqlite3もrebuild時に .node ファイルを生成し，electronはこいつを呼び出してsqliteを実行する．このときに呼び出す .node は外部ライブラリ扱いであり，最近のMacOSでは依存している外部ライブラリもcode signingされている必要がある．
これをやらないと，
Uncaught Exception: Error: dlopen(/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU, 0x0001): tried: '/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' (code signature in <5439AE43-90A3-3A47-A95F-32AEC2235239> '/private/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)), '/System/Volumes/Preboot/Cryptexes/OS/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' (no such file), '/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' (code signature in <5439AE43-90A3-3A47-A95F-32AEC2235239> '/private/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)), '/private/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' (code signature in <5439AE43-90A3-3A47-A95F-32AEC2235239> '/private/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' (no such file), '/private/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' (code signature in <5439AE43-90A3-3A47-A95F-32AEC2235239> '/private/var/folders/w9/_481zfb94wx2yq562f5h68vw0000gn/T/.social.whalebird.app.mH2BlU' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)) at process.func [as dlopen] (node:electron/js2c/asar_bundle:5:1812) at Module._extensions..node (node:internal/modules/cjs/loader:1205:18) at Object.func [as .node] (node:electron/js2c/asar_bundle:5:2039) at Module.load (node:internal/modules/cjs/loader:988:32) at Module._load (node:internal/modules/cjs/loader:829:12) at c._load (node:electron/js2c/asar_bundle:5:13343) at Module.require (node:internal/modules/cjs/loader:1012:19) at require (node:internal/modules/cjs/helpers:102:18) at Object.<anonymous> (/Applications/Whalebird.app/Contents/Resources/app.asar/node_modules/sqlite3/lib/sqlite3-binding.js:4:17) at Module._compile (node:internal/modules/cjs/loader:1120:14)
というようなエラーになる．
ここでは com.apple.security.cs.disable-library-validation が紹介されているが，BigSur以上のMacOSの場合は，この設定に問題がある件が指摘されている．
https://github.com/electron-userland/electron-builder/issues/3940#issuecomment-900527250
で，そもそもなぜアプリに含まれているはずの .node ファイルがelectron-osx-signでcode signingされないのかというと，これらがすべて asar に圧縮されてしまっているためだ．electronはプログラムを asar に圧縮して配布している．割と簡単に解凍できるのだが，code signするときにいちいち解凍はしてくれない．
というわけで，
"build": { "mac": { "asarUnpack": "node_modules/**/*.node" } }
という設定を入れて，.node ファイルを asar 圧縮から除外してやる必要がある．これをやると asar.unpacked というディレクトリ内に生ファイルのまま格納されるので， electron-osx-signが --deep オプション付きでcodesignするときにすべてcode signingされる．
ちなみに元のcodesignコマンドを使ったスクリプトは --deep オプションを使っていなかったので，unpackedにしたところで結局同じエラーに陥った．
問題3: native dependencyの成果物をuniversalでマージできない
electron-universalは，一度x64，arm64両方のビルドを作り，それらをマージすることでuniversalバイナリを作っている．このときに，問題2でasarから除外したunpackedなnative dependencyが問題になる．
Detected unique file "node_modules/sqlite3/lib/binding/napi-v6-darwin-unknown-arm64" in "***/whalebird-desktop/build/mac-universal--arm64/Whalebird.app/Contents/Resources/app.asar.unpacked" not covered by allowList rule: "undefined"
これと同じことが発生し，同じ名前の別archファイルをマージできなくなる．これについては，singleArchFiles オプションを使えという話ではあるが，最終的に俺は mergeASARs: false にして，universalのときにasarのマージをやめた．これは次の問題4に大きく関係する．
が，いずれにしろ，どちらかのオプションを使い，両方のアーキテクチャ用のバイナリを残す必要がある．
問題4: node-sqlite3はelectron-rebuildした成果物が正しくない
ここまでで，だいたい動くようにはなったのだが，一つ大きな問題が残った．どうもx64では問題なくarm64でのみ問題が発生することがわかった．
エラーがこれだ．
Uncaught Exception: Error: Cannot find module '/Applications/Whalebird.app/Contents/Resources/app.asar/node_modules/sqlite3/lib/binding/napi-v6-darwin-unknown-arm64/node_sqlite3.node'
おかしい．そもそも問題3の解決のために node_sqlite3.node は asarから除外してunpackedに入っているはずだ．しかし，ここではasarの中を探している．
さらにもう一点おかしいことがある． unpackedディレクトリの中身はx64もarm64も同じで，bindingの下には
napi-v{napi_build_version}-darwin-unknown-arm64napi-v{napi_build_version}-darwin-unknown-x64napi-v6-darwin-unknown-x64
の3つしかディレクトリがない．確かにこれなら，x64は napi-v6-darwin-unknown-x64 を使って起動できるが，arm64になると napi-v6-darwin-unknown-arm64が存在せずにエラーになることは理解できる．asarを探しているのは，おそらく探索順序が unpacked -> asar の順で探索されているだけだろう（これは勘）．
というわけで
これだ．これはelectron-rebuildとnode-sqlite3の掛け合わせで発生する問題のようだ．
これ自体が解決していないので，そもそもnode-sqlite3を使うのをここでやめて，better-sqlite3を使うことにした．
better-sqlite3は開発時もrebuildしないと起動しない
これはproduction buildの話ではないのだが，そもそも開発環境でも
NODE_MODULE_VERSION 108. This version of Node.js requires NODE_MODULE_VERSION 107. Please try re-compiling or re-installing
というエラーがでて起動できなかった．これはelectronのバージョン（の中で決まっているNODE_MODULE_VERSION）が合致したものを使えばいいとは思うのだが，毎回それを気にしてライブラリの更新をするのも手間なので，install直後にrebuildすることにした．
package.jsonに
"scripts": { "postinstall": "electron-builder install-app-deps" }
とかを追記しておけば，起動するようになる．
解決
そして解決し，無事にAppStoreのレビューも通った．
今回の問題のうち
- 問題1
はAppStoreのみに関係する問題だったが，
- 問題2
- 問題3
- 問題4
に関しては，DMGでも同様のエラーがでて使えないという報告が上がっており，
Whalebird 5.0.0 fails to start · Issue #4195 · h3poteto/whalebird-desktop · GitHub
v5.0.0 macOS x64 JavaScript error on launch · Issue #4173 · h3poteto/whalebird-desktop · GitHub
同時にすべて解決することができた．
まとめ：結局どうするのが良いのか
node-sqlite3ではなくbetter-sqlite3を使う．
Windows, Linux向け
electron-builderでもelectron-packagerでも問題ない．そもそもビルド環境と実行環境が同じプラットフォームであれば，気にすることはない．
MacOS向け
AppStore
electron-builderを使う．
こういう設定でビルドする．
{ "productName": "Whalebird", "appId": "social.whalebird.app", "artifactName": "${productName}-${version}-${os}-${arch}.${ext}", "directories": { "output": "build" }, "extraResources": [ "build/icons/*" ], "files": [ "dist/electron/**/*", "build/icons/*" ], "mas": { "type": "distribution", "entitlements": "plist/parent.plist", "entitlementsInherit": "plist/child.plist", "entitlementsLoginHelper": "plist/loginhelper.plist", "hardenedRuntime": false, "gatekeeperAssess": false, "extendInfo": { "ITSAppUsesNonExemptEncryption": "false" }, "provisioningProfile": "./packages/socialwhalebirdapp_MAS.provisionprofile" }, "mac": { "icon": "build/icons/icon.icns", "target": [ { "target": "mas", "arch": [ "universal" ] } ], "category": "public.app-category.social-networking", "hardenedRuntime": true, "gatekeeperAssess": false, "darkModeSupport": true, "extendInfo": { "ITSAppUsesNonExemptEncryption": "false" }, "mergeASARs": false, "asarUnpack": "node_modules/**/*.node" } }
なお，electron-builderは内部でelectron-osx-signやelectron-rebuild, electron-universalを使っている．そのため，
com.apple.security.application-groups や ElectronTeamID は自動挿入されるので，entitlementsに追加する必要はない．
whalebird-desktop/plist at master · h3poteto/whalebird-desktop · GitHub
この辺を参考にしてもらうと良い．
DMG
electron-builderを使う．
こちらもあまり変わらないが
{ "productName": "Whalebird", "appId": "social.whalebird.app", "artifactName": "${productName}-${version}-${os}-${arch}.${ext}", "directories": { "output": "build" }, "extraResources": [ "build/icons/*" ], "files": [ "dist/electron/**/*", "build/icons/*" ], "afterSign": "build/notarize.js", "dmg": { "sign": false, "contents": [ { "x": 410, "y": 150, "type": "link", "path": "/Applications" }, { "x": 130, "y": 150, "type": "file" } ] }, "mac": { "icon": "build/icons/icon.icns", "target": [ { "target": "dmg", "arch": [ "x64", "arm64", "universal" ] } ], "category": "public.app-category.social-networking", "entitlements": "plist/entitlements.mac.plist", "entitlementsInherit": "plist/entitlements.mac.plist", "entitlementsLoginHelper": "plist/loginhelper.plist", "hardenedRuntime": true, "gatekeeperAssess": false, "darkModeSupport": true, "extendInfo": { "ITSAppUsesNonExemptEncryption": "false" }, "mergeASARs": false, "asarUnpack": "node_modules/**/*.node" } }
こんな感じ．
Fedistar 1.0.0をリリースした
リリースした．ここからダウンロードしてくれ．
無事AppStoreにも公開された．
見た目．
だいたい普段遣いする機能は追加できたと思う．
- マルチアカウント管理
- ストリーミング
- 通知
- Reblog/Fav/Bookmark/Emoji
- ステータスの編集
- スレッドの表示
- リンクカード
- アンケートと投票
- 新規投稿時のサジェスト
- メディアの表示
- ログインせずにタイムラインを表示
あたりはできている． なんとWhalebirdを追い越して編集機能は先にFedistarに入った（UI的にWhalebirdのほうが考えることが多いというのはある）．
あといくつかやることは予定しているんだけど，全部IssueoにしてあるんでGitHubを見てくれ．
1.0.0を出したからには流石に安定版なので，バグ報告等も受け付けている．
今のところ，GitHub releaseページ以外だと
- MacAppStore
- AUR
にしか上げていない．
HomebrewCaskは，リポジトリ自体がある程度人気じゃないと受け付けてくれないので，スターがそれなりに溜まったらやる． Snapcraftは，やりたい思いはあるんだけどtauri側がまだsnapパッケージのビルドに対応していない．
こいうのはあるんだけど，コレ自体GitHub Actionsで動かすのはほぼ無理（依存しているmultipassがKVM supportを前提にしている）なので，すぐには対応できそうにない．
他，
- Flatpak
- Winget
- MicrosoftStore
あたりはやる気次第でそのうちできるかもしれない．
という記事を書いている間に1.0.1をリリースしたので，さっそくアップデートしてくれ．
ディスプレイを新調したらWhalebirdに満足できなくなったので新しくFediverseクライアントを作っている
この記事はFediverse (2) Advent Calendar 2022の7日目です．
最近34インチのウルトラワイドディスプレイを買ったんだけど，これによって俺の作業スペースは格段に広がった．Emacsは常時3分割or4分割だし，1ワークスペースにブラウザとターミナルを表示するのは普通．むしろ1アプリで1ワークスペースを専有させるものはほとんどなくなった．と同時に，Whalebirdの情報密度をもっと濃くしたくなった．
Whalebirdは当初からシングルカラムのMastodonクライアントだ．ただし最近はいくつか不満な点があって，
- 画面幅が3440x1440なので画面に対して表示される情報量が少ない
- 他のサーバや他のTLを開くときにいちいち読み込みが走るのが面倒
- （これは日本人だけかもしれんが）そもそもみんなそんなに長いポスト，してないんだわ．みんな「ゆれ」とかしか投稿しないのに，この横幅いらなくね？
というわけでマルチカラムのクライアントが欲しくなった．
Whalebirdをマルチカラム化することも考えたが，
- 現状のコードベースをきれいにしたいところがかなりある
- Vue.jsをもうあまり書きたくない
- そもそもマルチカラムに耐えうる設計じゃない
と思ったので新しく作ることになった．
はい，こんな感じです．
リポジトリはこれ．
機能面でいうと，
- 認証せずにサーバを追加できる．この場合見られるTLはpublicとlocalのみで，リアクションもできない．が，TLを覗くだけということができるようになる
- 投稿するアカウントを選択できる．ただしリプライ時にここをどうするかは検討中
- Mastodon/Pleromaには対応済み．Misskeyどうするかね？
- あとは普通のマルチカラムクライアントの機能……はまだ全然足りてないが
今後実装したいもので，優先度の高いものはissueにしているが
ここに書いていないものだと
- RT, fav等のリアクション時に，どのアカウントで行うかを選択できるようにしたい……？できるのか？
- 通知件数をmarkerから読むようにしたら未読件数を表示できる……？かなぁ？
- サーバ/アカウントごとの通知に一発で飛べるようにしたい
- アイコンほしい
WhalebirdはElectronで作っていたが，実はこいつはtauriで動いている．だからたぶんWhalebirdより軽いんじゃないかな，計測してないけど．メインプロセスはそりゃー軽いだろうが，レンダリング部分は正直何をレンダリングしているか（=TLに今何が表示されているか）に強く依存するので，何を比較したらいいのかよくわからん．同じTLを表示するだけならtauriのほうが軽いんじゃないかね．ただ，そもそもシングルカラムとマルチカラムでは同時に表示されるTLの数も違うので，比較するのに意味があるのかわからん．原理的にはfedistarのほうが重くなるはず（今の所TLの数を無限に増やせるので）．
で，tauriはメインプロセスをRustで動かすわけだが，このためにmegalodon（Whalebirdのために作ったMastodon/Pleroma/Misskeyのクライアントライブラリ）をRust対応させた．これだけでひと月くらい費やしたけど．
メインプロセスで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であればいくつか選択肢があり，
この中から用途にあった開発が活発そうなものを選べる． これに限らず様々なライブラリで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版とか？
ない． 作る予定もない．というかモバイルでマルチカラムはいらんだろ……．別で開発したほうがいい．
そういえばアイコンもまだない
アイコンをどうしようか考え中なんだけど，俺にはアイコンを描く技術はない．ので誰かに頼まないといけないのだが，あんまりデザイナーの友達もいないので，もし描いてもいいよって方がいたら連絡ください．お金は払います．
大事なことなのでもう一度書くと，お金は払います．