[Roadmap] Allow option to disable unusable/selected features

[Xtrah]

Why Users will be able to customize their big-AGI experience by selectively disabling features they can't access, don't need or don't want. This will provide a more streamlined and personalized interface, potentially improving performance and reducing cognitive load for users who prefer a simpler setup.

For example, if a user does not have a voice API, or do not wish to use it, they can disable it either in the UI or a server setting.

Description Implement a system that allows users to disable specific services or features, such as voice interactions and AI personas. This should be accessible through a settings menu or through a server-set environment variable, giving users granular control over which functionalities are active in their instance of big-AGI.

Requirements

• [ ] Create a new section in the settings menu for "Feature Management" or "Service Controls"
• [ ] Automatically detect unusable features, e.g. features lacking necessary API key
• [ ] Implement toggles for major features/services, including but not limited to:
  • [ ] Voice interactions
  • [ ] AI personas
  • [ ] Image generation
  • [ ] ...
• [ ] Ensure that disabling a feature removes related UI elements and options throughout the application, or disables it
• [ ] Implement a system to gracefully handle attempts to use disabled features (e.g., informative messages)
• [ ] Add a "Reset to Default" option to easily re-enable all features
• [ ] Ensure that core functionality (e.g., basic chat) remains accessible even if most features are disabled

[enricoros]

Thanks for this suggestion @Xtrah.

I think this would deserve a nice configuration framework, both on the server side, and user side.

• server side: for now we have control over the model services, but not much more, e.g. cannot set image generation preferences. would need to decide how to configure, and whether the server-side needs some sort of DB to store this configuration to then pass it to the users or enforce

• client side: I'm thinking of a dedicated section of big-AGI (an "application") with enough screen space to let the user pick the options within the constraints that are imposed by the server.

Complexities to solve:

• [ ] Conflicts: usually issues happen when the server changes configuration and there's conflict with the user's choices, but if this is well thought through then it should be very easy to operate
• [ ] "Matrix" configuration, when the presence of services depends on the configuration of other services (such as React depends on Browsing which can depend on a Google configuration) or text-to-image via Dall-E depends on OpenAI being one of the configured LLM providers

Very supportive of this, we'll just need to figure the best scalable experience around this.