eniehackとの議論3

Twitter proxyに対する返信である2022/08/03 sei0oへの返信2 - およそMECEでないアカシックレコードの200那由多飛んで3万分の3への返信

• scrapboxだと共同編集で1ページにみんなで追記する方法があるけれど、昔の情報を適度に消せなくなってしまうデメリットがある
• トピックごとにスレッドが立たないのはメリットでもありデメリットでもあるな
  • 短期間の会話なら大して違いはなさそう
• Mastodonで3000字級の会話しとるやつおるか？

実装形態は固めたほうがよさそう（それはそう）

• 間違いない
• 普段スマホから見てるんで、早い段階で使用感を試すために、若干webに気持ちが傾いている
• standaloneのときの構成がまだよくわかってないな
  • Twitter APIを叩く、filterを管理するのは誰？

• 普通のGUIとは……？

  • Twidereとかofficial Twitterとか、そういうの

• Front <-> Backend(Filterが内包)みたいな想像してたけど、綺麗に分離できるならそれでもいいかも？

  • あ〜分離ってのは、それぞれのパーツが独立に交換可能ってのを考えてた。実装上はフィルタがフロントエンドかバックエンドに含まれますね

• Filterは単一のpost -> 単一のpost?という感じの型になるのかな？　細かい話: passしたい場合はpostかtrueを、dropしたい場合はnilやfalseを返せばいい感じ……？

  • その通り
  • FilterResponse::AddCW(cw: String), FilterResponse::Delete, FilterResponse::Pass … のようにフィルタが取れるアクションを絞ってもいいんだけど、自由にpost全体を操作させるほうが実装も楽だし面白いフィルタが作れるんじゃないかと考えた

• 提案: Filterが複数重ねられるとよさそう

  • それは当初から考えてたしそれがいいと思う。こういうことですよね：
    • 
  • それともこっちか？ （これおもしろいな、AppleだったらSmart Listsって名付けてそう）
    • 
• Ruby

  • magnusは普通のRubyをRustと協調させるという認識でok？

    • そうね、Ruby内部のVMを呼び出してそことmagnusが話す感じ
    • requireの制限とかはできなさそう、そういうのができるラッパーが果たしてあるのか…（mrubyなら？）

• 異議なし
• いまさらだけど、「クライアントのマルチプラットフォーム対応（iOS, Windows, Web, etc.）」と「マルチFediverseプラットフォーム対応（Misskey, Mastodon, etc.）」が混ざりそう