Command LLM

[whilefoo]

Resolves #166

[whilefoo]

I have a dilemma about the command interface. I added a command property in the input object that has command name and command parameters. The name and parameters are given by the LLM when the user tags the bot.

I'm guessing we still wanna keep the /command something 10 so I'm thinking between

1. letting the LLM also infer this way of calling a command but it might not always be successful because there is less context than a user using natural language to express what they want
2. leaving the command input empty and the plugin itself has to decode the command from the comment payload like it has done now
3. removing this way of calling the command but if the LLM can't figure out how to call a command, you basically can't do anything

First option seems better because there's only way to receive commands and it's already parsed by the LLM so the plugin doesn't need to do any parsing, but might be inaccurate at times Second option makes sure that the direct way of calling a command is robust and not prone to hallucinations by LLM

@0x4007 @gentlementlegen

[gentlementlegen]

Second option seems proper to me because it is what we use for all the plugins so the parser is ready without any change, making maintenance easier.

[0x4007]

@sshivaditya2019 perhaps you can offer some pointers related to function calling

[whilefoo]

I will leave it for now since every plugin already supports parsing, we can add later if we want

[whilefoo]

@gentlementlegen I've just realised that separating SDK makes development more difficult, I made changes to Manifest but now it's in SDK package so I need to use bun link and I have to build the SDK every time I make a change. Also decoding manifest schema gives some TS errors about types not matching even though Typebox version is the same in kernel and SDK

[gentlementlegen]

@whilefoo The types not matching was there before somehow, not sure about the cause.

What I usually do is to build with a --watch so I don't have to think of it. If that is too burdensome, we can consider merging it back, but it has to be perfectly separated otherwise we will have the circular reference again which will break ncc compilation.

[whilefoo]

QA: https://github.com/ubiquibot-whilefoo-testing/testing/issues/7

[gentlementlegen]

@whilefoo Looks cool. I wanted to try some commands, I guess the bot was not able to execute them which is ok but I got no feedback on them: https://github.com/ubiquibot-whilefoo-testing/testing/issues/7#issuecomment-2466970407 should there be some error message displayed in such case?

[whilefoo]

@whilefoo Looks cool. I wanted to try some commands, I guess the bot was not able to execute them which is ok but I got no feedback on them: ubiquibot-whilefoo-testing/testing#7 (comment) should there be some error message displayed in such case?

I was running it locally on my laptop and I think it went to sleep so it stopped replying

[0x4007]

QA: https://github.com/ubiquibot-whilefoo-testing/testing/issues/7

This is amazing for demos to see let's merge it if you think it's in a good spot to.

Really looking forward to this natural language interface either on the copilot chat window on GitHub web desktop / iOS and/or our telegram bot.

[whilefoo]

This is amazing for demos to see let's merge it if you think it's in a good spot to.

I have to modify and make PR for each plugin to accommodate for the new interface so only then we can merge it

[0x4007]

This is amazing for demos to see let's merge it if you think it's in a good spot to.

I have to modify and make PR for each plugin to accommodate for the new interface so only then we can merge it

Can't this be done async? Lets just merge these and then fix the plugins later? Or will kernel be broken?

[ubiquity-os-beta[bot]]

@whilefoo, this task has been idle for a while. Please provide an update.

[whilefoo]

Can't this be done async? Lets just merge these and then fix the plugins later? Or will kernel be broken?

Unfortunately not, plugins won't run because of this change