eniehackとの議論

Twitter proxyへの返信であるぼくの考えたさいきょうのTwitterクライアント - およそMECEでないアカシックレコードの200那由多飛んで3万分の3 への返信

• List運用を基本とする

  • なるほど。そうしちゃう手もあるのか

• 個人的にはTwidere for Androidを想像している

  • ここはちょっと違いがありそう、自分はとりあえずどこまでミニマルにやれるか？というのを考えてみている
    • 最初は実装コストを下げるという意図もある

• 単体のTweetに対してTrue/Falseを返す、命題のような関数を定義する方式でもいいかも

• その中でhas_images?などの関数がほしいかも

  • たしかに
• フィルタの単位
  1. ツイートを表示・非表示にする
  2. ツイートの列（＝タイムライン）を入れ替える
     • 自由度：1 < 2
     • Nakaya君が考えているのは1で、sei0oが考えているのは2（だと思う）
     • 2にすることで、TLの文脈とか雰囲気を考慮できる？
     • TLの順番をバラバラにされてめちゃくちゃ困ったんだから、順番をうまくやれば逆にわかりやすくならないかな、と考えてみている
       • 具体的な案はまだない - ツイートの内容そのものを変更する（伏せ字・省略）のもありうる
     • 自動CW?
• 言語
  • Scheme
    • たしかに、シンプルな処理系だからよさそう
  • ある程度普及した言語でやりたい
    • Rubyはかんたんに綺麗なDSLが作れる（e.g. Sonic Pi）と思っており…

• Fediverse instance間が [[ ActivityPub ]]で接続されてるのはわかるんだけど、それぞれのノードからデータを取ってくるには各Fediverse server software（といっていいのか？Mastodon, Pleroma, Misskeyなど）のバラバラのAPIを使う必要がある？

• 差異を吸収するための抽象化

• standalone
  • RustとGUI
    • gtk-rs なら使ったことある、アクティブだしいいと思う
    • Qtはなぜか全然流行ってないのでおすすめできない
    • Tauri は最近1.0が出たのでいいかも
  • socketによる実装

    • セキュリティ機構が組込めればremoteマシンのsocketに繋いで……みたいなことも

      • おもしろそう
      • その一方で、それはremoteマシンでAPI作って、ローカルのsocketから叩かせればよくない？とも思う
• Web
  • 単に自分がつくりやすいだけ
  • 一回Flutterで作ろうとしたことがあるんだけど、挫折した
• Twitter APIのwrapping

  • すべてはつらそう

  • わかるなあ