0.16用のVVMダウンロードの流れ議論issue

[Hiroshiba]

内容

ダウンローダーでVVMをダウンロードできると良さそうですが、どのような流れにするかはまだ明確に決まってません。
ここで議論できればなと！

その他

今まで方針についての議論があったか調べてみたのですが、おそらくほとんど何も決まってなさそうでした！

関連しそうなリンク：

• VOICEVOXコアのプロプライエタリ部分をonnxruntimeに逃がして別々にビルド可能にする voicevox_project#24
• C API用のzipファイルからmodelディレクトリをなくし、別でmodelダウンロード可能にする #596

[Hiroshiba]

個人的な意見をリストアップしてみます！

ダウンローダーにVVMダウンロード機能を持たせるべきか

引き続き持たせた方が便利そう！
ダウンローダーはコアを使うためのいろんな素材（CUDAとかonnxruntime.dllとか）を持ってくる機能があり、その機能の一環としてモデルもダウンロードする機能があると便利そうなので。

どこからVVMファイルをダウンロードするか

今はコアのreleases内にあるmodel.zipに全部入れるけど、これからはvoicevox_fat_resourceから直接ダウンロードするようにしても良いかも？

ダウンローダーがデフォルトでどのバージョンのVVMを持ってくるか

そのコアバージョンに対応する vvm を持ってこれると便利そうではある。
つまり過去のダウンローダーは過去のモデルをデフォルトでダウンロードすると便利そう･･･？

今はたぶんコア.dllが配布されてるreleasesと対応するvvmがmodel.zipとして降ってきてるから、コアのバージョンを指定すればそれに対応するvvmを持ってくる実装になってそう。
（でもコアは最新のがデフォルト降ってくるはず）

仮にvvmをvoicevox_fat_resourceから得る場合は、対応するresourceバージョンをダウンローダーに刻むと良い･･･かもと思ったけど、うまくやらないとそれだとvvmが追加されるたびにコア側のreleaseをしないといけなそう！
voicevox_fat_resourceのバージョニングを頑張る手もある（メジャーバージョン変更でVVMのversion更新、マイナーバージョン変更でキャラクター追加、他の変更は全てパッチバージョン変更･･･？）けど、そうするとvoicevox_fat_resourceとvoicevox_resourceのバージョンが異なるようになりそう。
まあ別に･･････良い･････？ちょっと見通しが立てづらい･･･。

（追記）あるいは今まで通りとりあえずlatestを持ってくる仕様でも良いかも･･･？
いやこれはとりあえずじゃなくてこれからずっとになりそう。

ダウンローダーで利用規約を表示するか

可能ならダウンロードでダウンロードする時にVVMの利用規約を表示して、規約に同意する時のみダウンロードするようにしたい。
もしそれをやる場合はVVMごとにtos.mdを置くか、全体で１つtos.mdを置くと良さそう。（たぶん後者になりそう。）

vvmなどのディレクトリ構造をどうするか

これはちょっと自明じゃなさそう。
雑にやるならこう？

root
┗core
　┗vvm
　　┗0.vvm
　　┗1.vvm
　　┗･･･
　　┗README.md （このディレクトリの説明用、ダウンローダーからは使わなそう）
　　┗term.md （利用規約ファイル。VOICEVOX webページの利用規約ページがtermなので合わせただけ）

---

まとまってないけど一旦コメントまで 🙇
なんかうまい運用の仕方とか思いついたら是非コメント欲しいです！

とりあえずどうしましょう。。。。。
運用周りはさておいて先にダウンローダーの実装だけでも進める･･･？
例えばvoicevox_fat_resourceに新しいvvmをアップロードして、何でもいいから適当に1回タグを切り、コアのダウンローダを変更してvoicevox_fat_resourceからvvmをダウンロードできるようにする･･･？

[qryxip]

ダウンローダーにVVMダウンロード機能を持たせるべきか

賛成です。

どこからVVMファイルをダウンロードするか

voicevox_fat_resourceから直接ダウンロード

同じく賛成。

[追記] 利用規約のSHA-256を鍵としたAESでVVMを暗号化しておく、というアイデアを前話したと思うのですが、費用対効果は…うーん…

ダウンローダーがデフォルトでどのバージョンのVVMを持ってくるか

対応するresourceバージョンをダウンローダーに刻む

latest

この二つのハイブリッドはありかも。基本的にlatestだけど、ダウンローダーが知らないやつだったらやんわりとwarningを出す感じで。

ダウンローダーで利用規約を表示するか

ダウンロードする時にVVMの利用規約を表示して、規約に同意する時のみダウンロード

賛成。ただvoicevox_onnxruntimeも同様にした方がよいですね。

VVMごとにtos.mdを置くか、全体で１つtos.mdを置くと良さそう。（たぶん後者になりそう。）

後者ですかね。VVMという形式自体の利用規約は共通のはずですし。

それとは別にVVM内に利用規約を埋め込むというのはありかもしれません。VoiceModelFile::eulaでVVM自体の利用規約を、metas内で各キャラクターの利用規約(URL)を出せるようにして。

[追記] コアの実行時に、voicevox_core::agree_to_eula(&self, eula_sha256s: &[[u8; 32]])みたいなのを用意しておいて、session config entryに入れてvoicevox_onnxruntimeに伝える、という感じにすれば、利用規約について「知らなかったとは言わせない」と十分に言えると思います。
(その際二重にやってもあれなので、利用規約のSHA256についてはvv_binのバイナリに対してすみやかに判定できるような形にする)

…まあそこまでやると利便性にも影響が出そう。

+VVORT_EULA_SHA256 = b"…"
+VVM_EULA_SHA256 = b"…"
+
+voicevox_core.agree_to_eula({VVORT_EULA_SHA256, VVM_EULA_SHA256})
 vvort = await Onnxruntime.load_once()
 ojt = await OpenJtalk.new(…)
 synth = Synthesizer(vvort, ojt, …)

vvmなどのディレクトリ構造をどうするか

root
┗core
　┗vvm
　　┗0.vvm
　　┗1.vvm
　　┗･･･
　　┗README.md （このディレクトリの説明用、ダウンローダーからは使わなそう）
　　┗term.md （利用規約ファイル。VOICEVOX webページの利用規約ページがtermなので合わせただけ）

よさそう。

VOICEVOX webページの利用規約ページがtermなので合わせただけ

ダウンローダーで利用規約を表示するなら"eula"でよさそうな気がします。

[Hiroshiba]

@qryxip
ありがとうございます！！　結構固まってきた･･･！

ちょっといろいろ追加で考えたので一旦メモ＆相談まで！！

どこからVVMファイルをダウンロードするか

voicevox_fat_resourceにしようと思ってたのですが、もうVVM用にリポジトリ作ってそこで配布しちゃうとかありだなと感じました！
というのもバージョニングをどうしようか（voicevox_resourceと合わせるかどうか）がややこしく、しかも他のfatなリソースも放り込まれ始めるとだいぶややこしいなと。
であればvvm用のリポジトリを作っちゃえばいろいろ簡単になりそうだなと！！

（メンテナとしての思考メモ）
他にfatなリソースの種類がかなり増えるとリポジトリ管理が大変そうだけど、増えるとしてもたぶんエンジンに指せるキャラごとの音声ライブラリ（vvlib？）くらいだと思うので、まあ大丈夫そう！
１年fatリソース増えなかったし、これからもきっとあまり増えない！

ダウンローダーがデフォルトでどのバージョンのVVMを持ってくるか

基本的にlatestだけど、ダウンローダーが知らないやつだったらやんわりとwarningを出す

基本的にlatestにするのなるほどです！　一旦この形が良さそう！
正直しばらく運用してみないと最適な形がわからず、であれば一旦latestをDLする実装がコスパ良さそう。
「知らないやつだったらやんわりとwarningを出す」も、できるならやっても良さそう！　マストではなさそう。

ダウンローダーで利用規約を表示するか

ハッシュ値を入力必須にする案は、たぶん利用規約が変わったときに気付けるようにって感じですよね！
おっしゃる通り利便性がちょっと下がってしまうのと、結局自動化できるので意外と目的が果たせない気もしました！

あと利用規約同意についてはダウンローダーにスキップ用の引数持たせる手も考えてましたが、まあ「y/N」聞いてyならダウンロードする実装だけにするのが一旦良さそうだなと思いました！
これがシンプルだし、「利用規約に同意しますか？」「はい」の形になっててまあ一旦この経路だけで良いかなと！

voicevox_onnxruntimeも同様にとか、それとは別にVVM内に利用規約を埋め込むとかも賛成寄りです！
前者は簡単に実装できるならやりたい気持ち。後者は一旦マストではなさそう？という認識です。

vvmなどのディレクトリ構造をどうするか

term.mdにするかeula.mdにするかについて、色々調べた感じぶっちゃけeulaのほうが合ってそうですが、ちょっと表記揺れすると管理大変なので一旦term.mdで行こうかなと思ってます 😇

---

とりあえず更に良い案なければVVM用のリポジトリ作ってそっちにVVM入れて、適当に0.0.1-preview.0あたりのバージョンを振ろうかなと思ってます！
voicevox_fat_resourceを改名しても良さそうなので、いろんなリポジトリなどに書かれてそうなvoicevox_fat_resourceが修正効きそうかどうかで判断しようかなと。

[qryxip]

どこからVVMファイルをダウンロードするか

VVM用にリポジトリ作ってそこで配布しちゃう

理由も含め賛成です。バージョンも0.0.1-preview.0とかでよさそう。

ダウンローダーがデフォルトでどのバージョンのVVMを持ってくるか

「知らないやつだったらやんわりとwarningを出す」

ふと思い付いたのですがVVMのバージョンをSemVer風のx.y.zにするなら、SemVerとして解釈してしまってパッチバージョン違いならwarningを出さない、という形もありかも？

ダウンローダーで利用規約を表示するか

これがシンプルだし、「利用規約に同意しますか？」「はい」の形になっててまあ一旦この経路だけで良いかなと！

まず前提として、voicevox_onnxruntimeとモデルを自動で（i.e. 非TTYで）ダウンロードしたい人は我々以外にも一定数要ると思います。その人達に対しては「yの代わりにyes(1)して下さい」という案内をする必要があるのではないかと。結局、--yesオプションが無いことに困惑されるだけとなるような気がしています。

結局自動化できるので

これについての私の意図としては、"SHA-256の値はハードコードしてくれ"という案内とセットでやれば効果を発揮できないかなと思ってました。その前提のもと、「スキップ用の引数」に使えないかなと。あるいは(y/N)を(y/N/<sha256>)にしてもよいかも。

規約の改定の際には多分「遡及」が発生しますが、それでも一度は見た利用規約に対してyesと言うことになるだけなので、そこは別によいかなと。

…まあENGINEは今そういうことをしていないし、CUDAとかも同様なので、こういった努力自体そもそもやんなくてもよいといえばよいかも。実際にVOICEVOXの利用規約を改定せざるを得なくなったシナリオを想像するとちょっと怖いかもしれませんが。

vvmなどのディレクトリ構造をどうするか

term.mdにするかeula.mdにするか

まず今公的に表示している"利用規約"は次のものがあると思います。

1. VOICEVOX BLOGにある"VOICEVOX ソフトウェア利用規約"
2. "VOICEVOX エンジン利用規約"
3. エンジンマニフェストのterms_of_service

（"terms"でもなく）"term"としているのは1.のみで、この1.のURLはあまり意識されされてなさそうな気がしています。なので"eula"に転換することは今ならまだできるのではないかと思ってます。

"term.md"にする場合、それが"license.md"や"eula.md"と同等のものだと、非日本語話者に至るまで一撃で理解できるかという点を一度考えた方がよいんじゃないかなという気がしています。
(ちなみに用語集.md的な意味のterms.mdみたいなのを見たことがあります。というかそういうのはいっぱいあるっぽい)

[Hiroshiba]

ダウンローダーがデフォルトでどのバージョンのVVMを持ってくるか

ふと思い付いたのですがVVMのバージョンをSemVer風のx.y.zにするなら、SemVerとして解釈してしまってパッチバージョン違いならwarningを出さない、という形もありかも？

あ、まさにそういうことができるようリポジトリを分ける提案をした感じです！
多分知っているメジャーバージョンの中でのlatestを取ってくるのも良い気がしてます。
もちろんlatestを取ってきてメジャーバージョンが違えばwarningもあり。

ダウンローダーで利用規約を表示するか

これがシンプルだし、「利用規約に同意しますか？」「はい」の形になっててまあ一旦この経路だけで良いかなと！

この件ですが、やっぱり"一旦"この経路のみにしたいです！

まずSHA256の件は、ちょっとわかってないんですけれども多分何も防げてなく、ただ利便性が下がるだけな気がしてます。
もし利用規約を呼んでもらう前提だったら、利用規約の一番最後あたりにパスワードを書いておく感じのほうが目的を達成させやすく、かつハッシュコマンドの叩き方を説明する必要もなくなりそう。
でもまあそこまでする必要はいったんないと思ってます。

迂回するための引数を用意するかですが、一旦なしでお願いしたいです！
ぶっちゃけると、迂回引数がある時に法律的に「利用規約を読んだはずだ」と説得力を持って言えるかどうかわかんないんですよね。
そういう判例を探してきたり、いろんな意見を探してみたりして自信がついてから用意したいです。
ちなみに欲しい気持ちは分かります。多分エンジンでも使いたくなるはずですし。需要の声が大きくなったら優先度を上げたいところ。

ちなみに何かしらの方法でここのy手入力をスキップできるかもしれませんが、もちろんそれは案内しないつもりです。
利用規約を読み飛ばす方法を公式案内すると、ちょっと法的に微妙な気がしないでもないので。。

vvmなどのディレクトリ構造をどうするか

term.mdにするかeula.mdにするか

terms.mdにしましょうか！

ぶっちゃけここのファイル名はユーザーに全く提示されず（READMEから参照する際は別のタイトルをつけるだろうし、ダウンローダーからはこのファイル名が出ない）、自転車置き場の屋根の色の議論なので、あえて議論を避けて進んだほうがVOICEVOXのためになりそう。

[qryxip]

ダウンローダーがデフォルトでどのバージョンのVVMを持ってくるか

あ、まさにそういうことができるようリポジトリを分ける提案をした感じです！
多分知っているメジャーバージョンの中でのlatestを取ってくるのも良い気がしてます。
もちろんlatestを取ってきてメジャーバージョンが違えばwarningもあり。

あ、だとすると>=0.0.0,<0.1.0で一旦絞ってエラーにしてもいいかもですね。制限を緩和することなら後でできそうなので。

ダウンローダーで利用規約を表示するか

ちなみに何かしらの方法でここのy手入力をスキップできるかもしれませんが、もちろんそれは案内しないつもりです。
利用規約を読み飛ばす方法を公式案内すると、ちょっと法的に微妙な気がしないでもないので。。

VOICEVOX/voicevox_engine#709 の際には注意が必要そうですね。

vvmなどのディレクトリ構造をどうするか

terms.mdにしましょうか！

ここのファイル名はユーザーに全く提示されず（READMEから参照する際は別のタイトルをつけるだろうし、ダウンローダーからはこのファイル名が出ない）

"全く"というのは異議がある（例えば"モデルの利用規約が書かれたURL"が必要になるケースがありうる）のですが、了解しました。

[Hiroshiba]

VVM用のリポジトリ作ってみました！ https://github.com/VOICEVOX/voicevox_vvm
リポジトリ名迷ったのですが、voicevoxのVVMが入るとこということでvoicevox_を付けてみました。
（voicevoxとvvが被ってるような気がしますが、まあ。）

実際にVVMを配置するプルリクも作ってみました。

• feat: VVMを追加し、必要なドキュメントを自動生成するコードも追加 voicevox_vvm#1

これがマージされたら、とりあえずrelease（というかタグ）を切るつもりです 🙏

[Hiroshiba]

releaseも作りました！！

• https://github.com/VOICEVOX/voicevox_vvm/releases/tag/0.0.1-preview.0