議論：ライブラリダウンロードAPIについて

[sevenc-nanashi]

内容

関連Issue：VOICEVOX/voicevox#830

追加ライブラリダウンロードについての議論Issueです。

現在のVoicevoxにはGET /downloadable_librariesというエンドポイントが実装されています。
が、ライブラリダウンロードを実装するには幾つか足りない物があると思っています：

ダウンロード済み・アップデート可能・最新版の状態の表示

statusのようなキーを追加する？（"latest" | "updatable" | "not_installed"）

実際のダウンロードをするエンドポイント

DownloadableLibraryにuuidキーを追加し、POST /download_library?id=[ライブラリのuuid]のようなエンドポイントで作動させる？
エンジン毎に実装が異なる場合がある（例：認証の有無、ダウンロードの展開先、フォーマットetc）ので、これはエンジン毎に実装を替えられる方が良いと思います。
進行度を出すように実装したい場合はエディタでやる必要があります。が、これも辛そう。
POST /download_library?id=[ライブラリのuuid]で{"session": "[ダウンロードのuuid]"}を返し、GET /download_library_status?id=[ダウンロードのuuid]で{"progress": 33.4}のようなデータを返すようにして、エディタは定期的にGETを送るという実装も可能ですがめんどくさそうだしパフォーマンスも低下しそう。

VOICEVOXのバージョン

（関係なし）

OSの種類/ディストリ/バージョン

（関係なし）

その他

@shirowanisan さんから意見を伺いたいです。

[Hiroshiba]

issue作成ありがとうございます！！
かなり入り組みそうですが、ちょっと今の考えをまとめてみました！

• ダウンロードについて
  • エディタ側でやるかエンジン側でやるかは、どっちでもいい。最初の実装者にお任せ。
  • できれば片方でやったあと、もう片方も実装しやすいアーキテクチャだと最高
• ライブラリ管理について
  • @sevenc-nanashi さんが仰ってるように、「ライブラリID」を作って管理するのが良さそう
  • それを話者IDと一緒にしたりするのはエンジン側の自由
• 必要なAPI
  • /download_library/[libraryId]
    • エンジン側でダウンロードするなら
  • /install_library/[libraryId]
    • エディタ側でダウンロードするなら
    • zipファイルをPOST
  • /installed_library/[libraryId]
    • ライブラリのインストール状況
    • バージョンもわかるのでlatestかどうかなどは判定可能なはず
    • libraryId無指定なら全部リストアップ
• なくても良い（優先度の低い）API
  • /status_library/[libraryId]
    • latset/updatable/notInstalledを↑の代わりに返すもの
  • /download_status_library/[libraryId]
    • @sevenc-nanashi さんの仕様が良さそう
• APIの改変
  • DownloadableLibraryはspeakerとspeaker_infoを複数持てるように
• 仕様
  • β版フラグは用意しない。β版ライブラリを作ってもらうのを想定
• ref
  • ダウンロード可能な音声ライブラリを取得できるようにする #437
  • ソフトウェアの初期容量を減らすために音声ライブラリをUIでダウンロードできるようにする voicevox#830

[y-chan]

さて、マルチエンジンもリリースを終え、一区切りついたので、こちらの議論・実装を色々と進めていきたいです！

マルチエンジン化したことにより、各エディタのキャラクターをVOICEVOXエディタ上に持ってくることは可能となりましたが、各ボイボ系エディタのソフトウェアが固有にもつ音声ライブラリダウンロード機能なども、VOICEVOXとして仕様を決めてしまい、各エディタにそれに従ってもらう方が都合が良いと思います(現状VOICEVOXとしてはキャラクターだけを刺せる仕様にはなっていないですが、今後独自に実装すれば良いので、APIだけ決定すれば良いはず...!)。
現に、私が運営するSHAREVOXも、音声ライブラリをインストールする機能を持ち合わせていますが、これは独自に決められたAPIであるため、VOICEVOX系で揃えた方が望ましいはずです。

ちょっと急足かもですが、2月末に実装完了を目安に動いていきたいです、一旦優先度を中に上げたいと思います！

[y-chan]

私の意見もまとめておきますね...!

• ダウンロードについて
  • エディタ側でやりたいです。
    • 理由としては、エンジン側でダウンロードできてしまうと、リクエストを飛ばすだけでダウンロードされてしまう可能性があるので、少し危ないかなと。設定変更系の中でも、負荷の重い処理になってしまうので、 書き込み系のAPIを起動引数および環境変数によって一括で無効化できるようにする #571 を含めて考えてみても、エディタ側でダウンロードするのが適切かなと思いました。
    • あと、エディタ内で音声ライブラリダウンロードを完結させるのではなく、HPなどからライブラリをダウンロードし、今のエンジン管理画面からvvppを選択するような感じで、音声ライブラリも刺せると便利そうと思ったので、エンジン側はダウンロードURLを返すAPIと、その中身(もしくは圧縮ファイルなど)を渡すAPIの2つに分ける方が、汎用性は高いのではないかと思いました。
• APIの変更
  • ヒホさんと同意見です！

少なくとも、downloadable_librariesで情報不足というのは私も思ったので、APIを増やす必要はありそうですね...
もしくは、今使っているわけではないし、おそらく連携アプリケーションにも迷惑はかからないはずなので、今あるAPIをより使いやすく仕様変更するというのもアリかなと。

[shirowanisan]

@sevenc-nanashi
すみません。自分は多忙のため開発に参加するのが難しそうです💦
全てVOICEVOXの方針におまかせします🙇‍♂️

[Hiroshiba]

良いですね！！進めていきたいです！！
/downloadable_librariesは必要とあらばがっつり仕様変更しても良いのかなと思います。

とりあえず認識を合わせるためにちょっとAPI構成をまとめてみると、こう･･･？
（エンジンでのダウンロード機能はいったん不要かなと思って省いてみました）

• GET /downloadable_libraries
  • 既存だけど、情報が足りないので要改修
• POST /install_library/[libraryId]
  • ダウンロードしたファイルとかをPOSTしてエンジンにインストール
• GET /installed_library/[libraryId]
  • ライブラリのインストール状況・バージョン情報など
  • libraryId無指定なら全部リストアップ

あとインストール周りのAPIはセキュリティレベルを１つ上げて、エンジンに起動引数を付けた場合にのみ使えるとかにしても良いかもと思いました。
今のままだとallow_origin=*を付けただけで任意のファイルが送られてしまうので･･･。

[sevenc-nanashi]

/installed_library は /downloadable_libraries に統合しても大丈夫だと思ってます、何か分ける理由ってあったりします？

[Hiroshiba]

役割が明確に違いそうです。
（installed_libraryはインストール済みでローカルで完結する情報で、downloadable_librariesはwebから取得する情報）
分けないと、例えば配布を停止したライブラリの扱いとかがややこしくなりそう？

両方の情報を集約して返す/library/[library_id]エンドポイントとかならありかもです。

[sevenc-nanashi]

たしかに。なら別で大丈夫そうですね。

---

engine_manifestのdownloadable_library_urlとdownloadable_library_pathはどうします？
自分はbool値のwith_downloadable_libraryで大丈夫だと思ってます

[Hiroshiba]

エンジン未起動の状態でダウンロードしたいことがあるか、ですよねぇ。。まあ･･･無い･･･かなぁ･･･。

bool値は賛成です。
supported_featuresに追加で良いのかなと思いました。
既存のが全部動詞始まりだから、まあdownload_libraryとinstall_libraryですかねぇ。
（uninstallとかも入ってきそうだし、全部まとめてmanage_libraryとかでも良いかもしれない）

[tarepan]

必要性

@Hiroshiba
2024年3月の時点で、本実装の必要性はどの程度でしょうか？
現状、プロジェクトレベル では「一部機能を off で維持」という方向性だと認識しています。

もし現時点で必要性が無くなっている or 優先度が低いのであれば、「プロジェクトレベルでの再始動に合わせた re-open 前提で close する」という対応もありうると考えます。
こうすれば「要議論 だからちょっと考えてみるか → issue コメント →『考えて貰ったのにすみません、この議題は今優先度低めなんです...』」というリソース浪費ケースを避けられそうです。

project側に「実装時にエンジンで当該 issue を reopen して議論再開」と案内すれば re-open 前提の close が達成できそうです。

[Hiroshiba]

優先度はVOICEVOXにとっては「あると嬉しいけど手がつけられていない」です！
（ちなみにVOICEVOX派生ソフトにとっては優先度がもうちょっと高いと思います。）

今のこのissueを見て、コメントなく手を付け始められる方はあまりいないと思います。
とはいえ現状動いているわけでもないので、一旦閉じておいて再始動するタイミングでre openするかどうか決めても良いと思います。

あ、こういうプロジェクトがあるよという案内になってるので、そこだけどこかで案内できると嬉しいかもです。
ロードマップに案内を１行ちょこっと付け足し、このissueは一旦closeというのはどうでしょうか。

[tarepan]

VOICEVOXにとっては「あると嬉しいけど手がつけられていない」 ... VOICEVOX派生ソフトにとっては優先度がもうちょっと高い ... ロードマップに案内を１行ちょこっと付け足し

👍
現状の明確化ありがとうございます！
ロードマップ #1106 へ記載しました。本 issue は一旦 close とします。