Feature: Simple text-based config

[nh2]

Currently moonfire-nvr has a mix of a config file and then more config in the DB.

It would be great if all config could optionally be done declaratively in a text file.

This make it easier to:

• check the config into version control (e.g. git), and diff it
• use it in declarative systems such as NixOS Linux
  • see e.g. this for a declarative frigate config, it would be great to be able to do this with Moonfire as well
• have users post their full config in guides and issues, instead of having to provide screenshots
• increase simplicity and scriptability: Directly invoke moonfire-nvr run --config myconfig.toml with a single invocation, no separate init or config calls needed; they'd be done automatically; no need to navigate curses UIs (I appreciate that it's a cool feature that's nice for some groups of users, but many others might find the "just invoke 1 binary on 1 config file" approach even easier)

---

I understand that you also want to provide the feature to change settings, cameras, etc. via an API. For that, a DB is of course more suitable than a read-only configuration text file.

For that I propose to control the behaviour with some options:

• One to say "use this config file to initialise the DB; afterwards, config values in the DB persist and get used after restart".
• One to say "just use the config files; further configs done at run-time apply in-memory but get wiped on next restart".
• One to say "just use the config files, read-only; reject any config change via the API or similar".

[Alibirb]

Moonfire having a text-based config file would also be very convenient for the NVR system I'm working on, which wraps Moonfire and uses it as the recording backend. It would be a lot easier to automatically configure Moonfire if it just took a config file.

[scottlamb]

I'm skeptical of going this route. In particular, regarding these modes:

• One to say "just use the config files; further configs done at run-time apply in-memory but get wiped on next restart".
• One to say "just use the config files, read-only; reject any config change via the API or similar".

How would these modes work if the database is inconsistent with the config file? Moonfire has a very different design than Frigate with stricter ideas of database integrity. For example, each camera has an internal id (used in the SQLite database and sample file directories) and a uuid. If a user changes one or both between runs, what is expected to happen?

check the config into version control (e.g. git), and diff it
have users post their full config in guides and issues, instead of having to provide screenshots

It certainly would be possible to have a "dump current config to a nice format" operation.

no need to navigate curses UIs (I appreciate that it's a cool feature that's nice for some groups of users, but many others might find the "just invoke 1 binary on 1 config file" approach even easier)

I do want to get rid of this in favor of providing only a config HTTP API (and a web UI on top of it).

Moonfire having a text-based config file would also be very convenient for the NVR system I'm working on, which wraps Moonfire and uses it as the recording backend. It would be a lot easier to automatically configure Moonfire if it just took a config file.

I'd love to hear more about your system sometime. I would certainly like such things to be possible atop the API.