[FEAT] Skill settings endpoint

[NeonDaniel]

Objective

Implement endpoints to set/get skill settings per-client with global defaults. The actual settings storage may be implemented in a separate service or as part of Hana.

Initial Implementation Requirements

• API methods to set and get skill settings for a specific client
• API method for configuring default skill settings

Other Considerations

• configuring default settings will require a higher level of authentication or else be a hard-coded internal method to prevent accidental or malicious overrides of default settings
• This should integrate with ovos-backend-client
• Do we need to support multiple "clients" here, or is this just for the Neon instance in k8s?

[NeonDaniel]

If we're saving configuration, should this be per-user with the settings service including user configuration as well?

[Olzeke51]

so Neon is dependent upon a central server - HANA. ?doesn't this open Neon{local} to the same situation as Mycroft folding?
"configuring default settings will require a higher level of authentication or else be a hard-coded internal method to prevent accidental or malicious overrides of default settings" - - a need for a 'root' password?? or passphrase encoded with a PIN?

[mikejgray]

so Neon is dependent upon a central server - HANA. ?doesn't this open Neon{local} to the same situation as Mycroft folding?

"configuring default settings will require a higher level of authentication or else be a hard-coded internal method to prevent accidental or malicious overrides of default settings" - - a need for a 'root' password?? or passphrase encoded with a PIN?

Not quite. While Mycroft did have a central server, it was never meant to be run by users locally. HANA is designed from the start to belong to the user, although Neon does run their own. Don't worry - no one wants a repeat of that situation. 😄

[NeonDaniel]

so Neon is dependent upon a central server - HANA. ?doesn't this open Neon{local} to the same situation as Mycroft folding?

What Mike said, but also we aren't tying core functionality to the backend, only things that either cost money or require extra work for the user to set up themselves (i.e. paid weather and stock services, STT, TTS).

"configuring default settings will require a higher level of authentication or else be a hard-coded internal method to prevent accidental or malicious overrides of default settings" - - a need for a 'root' password?? or passphrase encoded with a PIN?

Something like that. For a shared system where the clients are unrelated (like hana.neonaiservices.com), we wouldn't want any authorized client to be able to set the defaults for other clients. For an internal system, you might want to set the defaults that every device you connect will use if you haven't separately configured that device. i.e. A skill that has an API key in config; a shared system would definitely NOT want to use the same key on every client, but an internal system might share one key for every client