org configs sync/corrections

[Keyrxng]

• We have four orgs all with their own config files.
• Each org has repos which also have their own config files (potentially)
• repo config files need to copy the entire org config (afaik) as it overwrites, not merges.

Due to the above it's very easy to have plugin URLs which are out of sync.

• "ubiquibot" in command-wallet worker URL and it should be ubiquity-os-marketplace or just ubiquity-os but the URL is valid
• "ubiquibot" in command-query, this URL is invalid as it does not match the worker-deploy.yml deployment url
• "ubiquibot" in daemon-merging and URL is invalid as it still points to assistive-pricing
• potential branch mismatch in text-vector as it targets development but the most recent worker was deployed to main.
• plugin instance confusion in text-vector as it's installed as a worker here but is running on actions

That is just from one org' (ubiquity) config file and I'm 100% certain all of them are going to have either the same or similar problems.

1. Create a plugin which detects changes to ubiquity-os-config.yml and then tracks all other config files and updates them accordingly.
2. Create infra to simply TG message the org admins that there is a config mismatch and it can be manually reviewed.
3. Create a workflow which effectively does the same as 1 or presents links to other configs that are mismatched within a diff comment like the empty strings warning?

[Keyrxng]

@rndquu @gentlementlegen @0x4007 @whilefoo rfc

[rndquu]

We'd better:

1. Remove worker urls from the configs and simply use a github organization/repository slug
2. Make the kernel fetch worker url from the manifest (Add url property to manifest.json plugin-template#33)

[0x4007]

• I think this is an edge case that will only affect us.
• I also think with our new tooling like the installer UI or even my GitHub.com/0x4007/sync-configs-agent it's way easier to get things in sync.

We'd better:

1. Remove worker urls from the configs and simply use a github organization/repository slug

• I dislike the idea of adding redundant information to the manifest
• this disables the ability for plugins to be closed source

It would be preferred to allow any api endpoint to be called as a plugin in the config. I think it's one of the technical benefits of our architecture vs just a glorified GitHub actions invoker.

2. Make the kernel fetch worker url from the manifest (Add url property to manifest.json plugin-template#33)

I fixed the plugin installer UI dependency on matching the name so this is no longer a requirement

[Keyrxng]

• I dislike the idea of adding redundant information to the manifest
• this disables the ability for plugins to be closed source

this is literally being implemented lmao

ubiquity-os/ubiquity-os-kernel#224

ubiquity-os/plugin-template#33

I fixed the plugin installer UI dependency on matching the name so this is no longer a requirement

Yeah different issue but thanks