self configuring goose - packaging of the app for non technical corporate use

[michaelneale]

Had a chat with zcharloppowers about how we package goose today for corporate use for various audiences.
it is a hodge podge of env variables and files and repackaging, which works, but seems like it is more work than it should be.

What I think we could do better:

Have a packaged.json/yml/toml file which can be provided on disk, in a known location, ahead of goose desktop starting:

The endpoint management tool would provide this:

provider: X
alternative-providers: X, Y Z
access-key: *encrypted form*
extensions: (indicate which are enabled)
recipes: (pre-populated, or repo of pre populated)
starter-actions: list of recipe like prompts which show up as buttons people click on so don't start as blank slate
features: ... optional set of features to turn off/hide 
proxy: ... proxy config
goose-mode: if chat or full auto, or not, and if they can change it
security: settings to do with prompt injection protection, scanning, models used etc, MCP allowlist
role-persona: description of persons role to personalise, add to system prompt to steer actions

We have some of this already, but some of it we patch up at build time, but with something like this, the idea could be that if Goose detects that file laied down by a MDM or endpoint security tool or even... just as a ".goose" file - then when goose (desktop) boots - it starts pre-configured with all that. Any secrets in there are automatically stored in the keychain (and then removed from the file... possibly) and then things "Just Work".

So this could help corporate environments that do endpoint management (they can put a file like this in ~/.config/goose) or even for convenience for a small team - that wants to make goose a tool for their (expert) users (eg data modellers, scientists, chemists) who would love a pre-made tool. They can just double click the file (or similar) and goose will be working exactly how you want and they need.

Thoughts?

[zachcp]

Hi @michaelneale ,

Thanks for the convo! This would be a really fantastic addition to Goose. ( Here is a link to the motivating Discord thread ) I think this proposal is elegant and I'd be happy to test/contribute. Theres a few aspects of the develoment

provider: X
alternative-providers: X, Y Z
access-key: encrypted form

You may have multiple provider/key/model

recipes: (pre-populated, or repo of pre populated)

Are git repos currently supported? that would be quite nice.

security: settings to do with prompt injection protection, scanning, models used etc, MCP allowlist

I agree with this although I think for proper security across a broader team you would probably need to bake this in pre-build. Maybe the path to that is BUILD + apply the .goose file and then code-sign?

[michaelneale]

git repos are currently supported for recipe discovery at least, but I don't think anything makes them show up in that recipe listing yet.

[alexhancock]

I love the idea. Should just be an evolution of our config file I think?

ie... we should have one kind of file which when edited manually or through app interactions, configures goose. And then when provided in some sort of way built into a distribution of goose can configure everything automatically. Optionally in a "read only mode" where the user cannot change certain settings, to avoid config breakage by users who need something packaged that won't deviate.

But the key thing is it would only be one kind of file. We should also document the format.

[michaelneale]

yeah it could be config file evolved, but I was thinking that this one is more read-only, and could even be registered as a file type on the OS (so it bootstraps goose). the reason being, endpoint security can set this file, and it means there is always a constant reliable configuration or base for goose.

The other approach I thought of was a way to build a real custom .app based on this config somehow (but that implies some on-demand CI service where you can specify it and you get a monolithic app exactly as you want - what I didn't get past there was that you don't want secrets baked into an .app - so need to have some expectation of user auth, which makes it a bigger task).

[alexhancock]

Makes sense

The other approach I thought of was a way to build a real custom .app based on this config somehow

Yes. I think we should just move the config file into the app and make a mode for the app where it reads config from this source and disables editing all or part of it if the packaging person/company so desires.

Would require expanding the scope of the config file to also be able to contain recipes, but I think that's the only missing thing?

[michaelneale]

due to signing and notarisation we can't change the content of what is in it without breaking that, so has to be outside, or it has to be some process that packages it before signing and notarization (on mac and at least windows)

but yeah- something like that.

[alexhancock]

well conceptually that actually kind of seems right?

we let people bundle a custom copy but it's not signed by us as it has custom bundled recipes/extensions/etc that aren't from us.

I wonder if could we document how people could sign a copy themselves if it contained this bundled config? Is that possible/desirable in your view?

[michaelneale]

yeah - we used to have code in forge/justfile which would sign and notarize for macos, but you need setup your apple developer account just right (and similar for windows) - a non trivial amount of work for most people for this (it would also be nice to use the one signed binary, so it can get updates naturally) where possible at all.

[agupta-fispan]

I would love this, it will be great to be able to sort this out cleanly.

[mootrichard]

Could we just have this be doable via a CLI of some kind for building the pre-configured artifact? (at least initially before modifying the core config file)

[michaelneale]

@mootrichard yes that could work too. Could even be build time via the Justfile if that is what you mean?

[zachcp]

Combine this with the MCP apps discussion and you've got a really powerful combination for local llm powered apps #6069

[evangineer]

Is there a branch or fork where this is being worked on?

[michaelneale]

nope not yet - feel free to start one (if that was implied question!)

[michaelneale]

am starting to pick this up again, some thoughts of path ahead:

If packaging up self contained:

• do it from within the app itself (similar to recipes, but can customise a lot more, and produces a package)
• have a web service/web page which does it for you

I think second one at least on macos will be needed as it will need to be signed, and you don't want the hassle of setting all that up on your desktop.

Implementation ideas:

• can either modify parts of goose (at build time) so it is packaged up/hard coded in it or
• be similar to recipes, have a launch mode that picks up appropriate config and variables and sets the app up the prescribed way.
  The first option in some ways is powerful, but then makes it harder for goose to update itself, second one requires something more exotic than feature flags (but not much).

requirements:

• be able to preconfigure LLMs, lock configuration down for them (may even bundle access/keys)
• be able to configure (and bundle?) mcp servers and all their settings
• be able to hide features, settings, parts of settings, all settings etc
• customise style/L&F, logos
• have special starting screens/experiences/apps

cc @evangineer