B視機 · BTelly

なぜ作ったか

テレビと車機での Bilibili 体験は長らく低地だった。公式クライアントはリモコンと車内インターフェースを「まあいいか」で扱い、広告とフィードの騒音だけはそのまま。私はただ、リビングのソファの上で、そして通勤の一時間の中で、静かにフォロー中の人が何かを更新したのを見たかった。サードパーティ製クライアントの意義は決して「解析」ではなく、視聴者に属するはずの画面を視聴者に返すことだった。

難しさはどこにあるか

• エンドポイント考古学：サードパーティクライアントは「API が予告なく変わる」世界に生きている。フォローリストの接口が死んだ時、公開されている接口収集リポジトリさえ空っぽになっていた——正しいエンドポイントは最終的に別のオープンソースクライアントのソースから掘り出され、実レスポンスに照らして字段ごとに修正された。カバー字段が実際に何と呼ばれるか、ページネーションの終了标记を誰が下すか、ライブ配信数がどこから来るか。すべて実トラフィックで検証し、推測ではない。
• 一つのコードベースに二つの形態：同じ十フィート界面でも意味は違う。テレビはリモコンの方向キーによるフォーカス移動を欲し、車機は走行中の思考ゼロ操作を欲する。二つのインタラクション哲学が一つのリポジトリに共存しなければならない。
• 透かしと署名：署名は README の中だけに住まわせておけない。ビルド時に作者アイデンティティとリポジトリ由来を成果物に焼き付ける——アプリ内で見え、自己検証できる。これはサードパーティプロジェクトが利用者に負う最低限の誠実さだ。

現状

• デュアル再生内核、弾幕コメント、空降アシスタント——広告なし、フィード挿入なし
• 「我的关注」ライブページは「配信中 / 未配信」でグループ化。配信中は全件表示とページネーション読み込み、未配信はグレーアウトして個人空間へ直接ジャンプ
• アプリ内更新は二重チャンネル（GitHub メイン + Codeberg 予備）、メイン失敗時は自動フォールバック
• Mac ビルドマシンが署名済み成果物を生産、GitHub Actions の出力はローカル証明書とビット単位で一致

学んだこと

他人の API の上に生きるプロジェクトを保守する上で、重要な能力は新機能を出すことではない——API が寝返った時にどれだけ速く立ち直れるかだ。ネットワーク層を独立モジュールに閉じ込め、エンドポイント考古学の過程を記録に残し、署名をドキュメントではなく成果物に焼き付ける。それらは順調な日にはすべて余計に見えて、API が顔を変える日にはすべてが命綱になる。また、二度のアカウント停止が教えてくれたことが一つある。ミラーチャンネルはバックアップの儀式ではない——実際に通ることになる道だ。