Description
Probably the most notable feature that is missing from Kagi right now are topic-specific Search Cards (the ones that appear on top of all the results with referential info).
Now, of course, y'all could implement them yourselves. But that wouldn't be too much of a priority in the grand scheme of things, and probably not a good return on investment.
But... what if you exposed an API that would allow us to write our own cards. If you licensed the API in such a way that requires the custom cards be distributed with an open-source license, this would allow a decent level of auditing so we as the community can audit their source code.
Examples
- Scientific calculator
- PyPI/Crates/NPM package table/reference
- Docs.rs/Readthedocs page reference
- Euros 2024
- Eurovision
- Olympics
- Periodic Table
- Chemical element/molecule reference
- Physics formula explanation
- Live/official election results
etc.
Usage
So as an MVP, a user using these custom cards would be able to go on GitHub (or find on community discussion boards) and find a custom card they're interested in. They would be able to reference the GitHub repo (or a specific release tag maybe) into the Kagi Settings frontend.
I imagine every repo would include a widget definition yaml/json with information on how Kagi should hook the widget into the frontend (for example, providing a relative path to the minimised js file in the repo). As well as some keyword/search context/alias/etc. configuration that would trigger this widget.
Then the Kagi search frontend would dynamically keep a list of the trigger keywords and decide to load the widgets depending on the user search.
Of course, there 1001 possible improvements, like having a Kagi-based "storefront" for these. But I think the feature described as above is enough to get us started and validate if this would be something the community is excited about.
And from your side, you could add a disclaimer on both the card result and the settings page to say that this functionality is provided by the community-provided widget, and is not a Kagi-endorsed result, or anything similar, and that would also ease some of the potential downsides on your end too.
