2022/08/02 sei0oへの返信
#ぼくの考えたさいきょうのTwitterクライアント
eniehackとの議論、 への返信
UI
ここはちょっと違いがありそう、自分はとりあえずどこまでミニマルにやれるか？というのを考えてみている。最初は実装コストを下げるという意図もある （注: eniehackが1行に改変）
実装コストを下げるのは正しそう
Twidere for Androidは目標、夢や妄想の類いということで……
フィルタ
sei0oが考えているのはツイートの列（＝タイムライン）を入れ替える
TLの文脈とか雰囲気を考慮できる？TLの順番をバラバラにされてめちゃくちゃ困ったんだから、順番をうまくやれば逆にわかりやすくならないかな、と考えてみている（注: eniehackが1行に改変）
その考えはなかった
変えられることのメリットが具体的には浮かばない……。
momentやtogetter的なものを編集するときには役立ちそうだが、TLの表示という観点では難しそう……？
daemon形式の場合、毎回、1からデータが送られてくるとステートレスになりそう
私は、増分をsocketに流す方式を考えていたので
ツイートの内容そのものを変更する（伏せ字・省略）のもありうる、自動CW?
提案: keywordでCWにするような機能をFilter言語に持たせるのはどうだろうか
命題型Filterで設計した場合、Filter言語の範疇は超えそうだが……。
ある程度普及した言語でやりたい、Rubyはかんたんに綺麗なDSLが作れる（e.g. Sonic Pi）と思っており…
これは同意
マルチプラットフォーム対応
Fediverse instance間がActivityPubで接続されてるのはわかるんだけど、それぞれのノードからデータを取ってくるには各Fediverse server software（といっていいのか？Mastodon, Pleroma, Misskeyなど）のバラバラのAPIを使う必要がある？
Yes、なので、Filterを渡す前段階のどこかで抽象化が行われてほしい
しかし、Payloadがそれぞれ違うので、has_images?的な関数が参照するfieldが違うのが、難所のような気がしている
余談: MastodonとPleromaは、ほとんどAPIは同じ
後者はCookieでも認証が可能とかの違い
余談: PleromaはBackとFrontが分離しているようなので差異がある？
GUI
細かい話: Elm Architectureを採用したicedもよさそう
余談？: daemon型にすればGTK,Qt,Webにこだわらずに開発可
Clientのみを開発すればいいので、他人がFilter型Clientの制作を楽にできそう？
Twitter APIのwrapping
すべてはつらそう
RPCに、エンドポイントとPayloadを渡すだけのProcedureを用意するだけでもよさそう
standalone/socketによる実装
それはremoteマシンでAPI作って、ローカルのsocketから叩かせればよくない？とも思う
それもそう
余談ということで……。