twitter proxy 実装原案

binchotan の前身になったやつ

• Plan A: Svelte + Netlify Function (Rust) + supabase (bird.o0i.esと同様)
• Plan B: SvelteKit + supabase (saurusと同様)
• Plan C: Svelte + Axum + psql
• Plan D: Svelte + Axum on Shuttle + psql/supabase
• serverless function vs. server-side framework
  • functionはメンテがいらない, 無料であれば安い
  • 常時動作していると
    • WebSocketとか張れる
    • pg_cronでfunction hookとかしなくていい
• SPAでaccess tokenを安全に保存できる気がしない
  • → nitter的な、Proxyにする
    • Nimだがソースコード読んでみるのはアリ？
    • Developer APIを整備予定なので、frontendだけまじめに作っちゃえばいずれは移転できる
  • SvelteKitでOAuth2を扱ったのはあるが、client secretとか隠蔽できてるのかわからん
    • hyper63/tutorial-sveltekit-authentication
• Proxy
  • A) ほとんど透過的に、クライアントが任意のendpointとパラメータを指定→Access Tokenを付与→Twitter API と流す
  • B) endpointのsubsetに対応するfunctionをつくり、それをクライアントから呼ばせる
    • こっちのほうが安全そう？いやそんなこともないか
    • サーバ上でもっておいてほしい情報
      • Access Token, refresh token
      • フィルターとか持っとかないといけないので、バックエンドで完結させるほうがいいか
        • でもフィルターはローカルで完結できる？
          • バックエンドのメリット：通信量削減、あとなんや
      • Rustパートが多いほうがいい
• 中途半端にserverlessにしようとするのがよくない気はする
• フィルタ
  • イテレータに強いのがいい
  • 言語選定
    • JavaScript/TypeScript
      • DenoのPluginとして？
      • Denoを組み込む？（Pluginと何が違うんだ）
      • Deno/NodeとFFI？
      • client-side
        • まさか eval()するわけにはいかない
          • Function()が使えるらしいが、別に安全ではなさそう
        • sandbox化にDenoの機能が使える？ https://github.com/denoland/deno/issues/1639#issuecomment-722191771
    • Ruby
      • mrubyでいい感じになるらしい(@eniehack)、artichokeええかもしれん
        • document少ないらしい
    • AiScript?
      • 具体的なsandboxの実装を知りたい
    • Lua
    • Scheme
    • (wasm?)
  • どこでかける？
    • バックエンド
      • 通信量削減
      • プッシュ型配信？
    • クライアント
      • Netlify functionsより計算リソースが自由に使える
      • 手軽
• 認証
  • jpopesculian/twitter-v2-rs: Rust bindings for Twitter API v2
• known todo
  • Twitterのhome/timeline読み込み
  • ツイート component
    • とりあえず本文表示
    • タップ時に詳細な情報を出す
  • custom filter
  • backend (proxy)
  • 認証
    • 全員ミュートが使い回せる