binchotan仕様案 Aug13

  • 名前
    • binchotan
    • libchotanはどっかで使いたい
  • ほしい機能
    • TLをみる
    • ツイートを見る
    • いいね・RTをつける(見るのではない)
    • リプライをうけとる(やりとりする)
    • フィルタ
    • マルチアカウント
    • 今後検討:マルチソース(Fediverse; 適宜読み替え)
  • いらない機能
    • トレンド、ストーリー、モーメント、他人のいいねの可視化、DM, etc.
  • アーキテクチャ
  • フロントエンド
    • コンセプト
      • ミニマルなやつから始めて…
        • ツイート本文だけでいいのでは?
      • Twidere っぽいの
        • リストベース
        • タブ、マルチアカウント
    • 実装
      • standalone: gtk-rs
      • web: Webサーバ(+ Webの文脈でのフロントエンド)
    • バックエンドテスト用のCLIで動く簡単なやつ
    • …など、socketが読めればなんでもok
  • バックエンド
    • Linuxマシン上で、daemonとして動作する
      • 今後検討;Windows + named pipes
      • per-user service (systemd)
    • 今後検討:nitter, fediverseのようにbackendを共有する, ホスティングする
      • 鯖管の責任でフィルタを導入して、そのうち使用するフィルタをfrontendユーザが(なんらかの手段で)選択する
    • 今後検討:フィルタとの(プロセスレベルでの)分離
  • フロントエンド・バックエンド間のプロトコル
    • JSON-RPC v2 over Unix domain socket (UnixStream)
    • A) バックエンドは、基本フロントエンドのリクエストに認証情報を付加してTwitter APIにパスするだけ
    • B) 一部エンドポイントについてはフィルタを通すためにwrap
      • v0 の間は柔軟に変更する
      • 新たにwrapしたいendpointが増えても、endpointへの直接の呼び出しは変更しない
        • フィルタが同じ動作を続けるように
    • idでリクエスト・レスポンスは対応付ける
  • フィルタ
    • ツイートを受け取り、編集してツイートを返す
    • フィルタは複数持てる
      • フィルタの組み合わせ方?
        • 今後検討:”smart lists”, UNIX, 前後・依存関係の記述(ツイートを編集するか?)
    • 言語と文法
      • 実験して検討する
      • mruby
        • mrbgem(gembox)を通して制限できそう
        • Shopifyのess?
      • Lua
        • vanilla Lua
        • Luau
        • mlua crateがよさそう
      • WASM
      • セキュリティはbackend管理者(現時点ではfrontendユーザと同じ)の自己責任で
        • 今後検討:サンドボックス
          • 最低限のライブラリを環境に与え、ネットワーク関連などは制限する
        • 一応docsに警告入れとこう
    • メタデータ
      • どこに入れる?(未定)
      • 項目:タイトル、version、author、…(未定)
      • 別ファイル package.json的な
  • DevOps
    • testable/modularityを目指す
      • なるべく考えながら書いてみて、微妙であれば指摘する
      • 例:標準入出力を渡す関数を作るのではなく、Streamを渡す関数として設計する
      • testを書けばある程度保証される?
    • GitHub
      • https://github.com/sei0o/binchotan-backend
    • 議論にはIssuesを活用する
    • ドキュメントはdocs/
    • 通話
      • 8/25 お昼

Backlinks