Vlad sure:
First of all those probably have to be JavaScript/TypeScript cause otherwise debugging them would be almost impossible and if it’s something on your server you get all sorts of problems (security, halting problem, etc).
UI wise:
If it’s the plugin UI you probably shouldn’t put any restrictions here (apart from the computer ones since those are limited by that).
If it’s how you install/write them:
Like I said I’d have some sort of plugin store/browser where people can list their plugins and other people can view the source code, install them, rate them, report them, etc. (maybe take inspiration from wago.io it’s a website for WoW user scripts https://wago.io/slraid2 )
After installing you should be able to modify scripts. It should also give you the ability to update them if there’s a new version in the “store”. (Appropriate warnings that custom changes will be overwritten and the likes before updating).
A user should have a list of installed plugins (Name,triggers, version, active state) where he can activate/deactivate them, view the code and delete them.
For writing them I’d make a on site JS editor kind of thing, with code highlighting, auto completion (especially useful for eventual Kagi specific api calls) and stuff like that.
Like UserScripts you probably should add meta information as comments to the header (plugin name, trigger conditions etc) so that they can be easily exported and imported by other people/parsed into a UI.
Flow:
The extension developer should be able to define trigger words that’ll activate the plugin (if there are multiple plugins with the same triggers, give a warning and tell the user to change one of them).
The trigger words and if the plugin is active are probably the only thing you guys should be aware of on the server tbh since depending on the trigger you might have to call the computer or the search widget.
After a trigger word is found you render either the search with the empty plugin container on top or the computer, give the search input to the plugin and let the dev handle the rest.
That being said you probably should do some JS binding to help with hooking into the Kagi UI (especially for the computer, for the empty plugin container selecting it and setting the html probably is enough).
I don’t know how viable it would be to define JS bindings in the way of querying a website via Kagi (rate limits and stuff) but that also could be something nice to not expose user IPs to websites if the plugin needs to crawl/parse a website to display something.
You should make a binding to store and load settings on the user profile though so that settings the plugins might have a shared between devices. (Maybe encrypt those somehow (user password? Though that would bring problems on password change) since they might contain login information or something)
Use cases:
probably endless tbh.
I could imagine a password generator with ones own rule sets would be a good example for a computer widget by typing something like password 25 and you’ll get a nice 25 character random password.(feel free to incorporate that one actually)
Basically small scripts like that would be predestined for computer plugins.
For the big on site widget ones a personal example maybe:
I thought it would be neat if I could scrap something like (https://na.finalfantasyxiv.com/lodestone/playguide/db/recipe/0e775b9dd31/) and display the recipe tree and where to find the stuff for FFXIV. Useful for me and probably another subset of people but way too much for an official Kagi widget so a custom one would be useful.
Thinking farther it might be a good thing to have for corporations to though.
They could define business related plugins and automatically distribute them to all their employees by means of corporate/team accounts.
Hope that helps 🙂
