It would be useful to have a plugin interface for the FriendNet client. Since the client is fully controllable using gRPC, I figure plugins could simply be an archive containing a manifest.json file listing the executables for each platform, version information, etc. When the client loads the plugin, it would just execute and own the process, and plugin would write a header and an address of a local HTTP server or UNIX socket to talk to, along with an authorization token to use when talking to it. The server would then make calls to methods like /plugin/start or /plugin/stop. On the start request, it would include the client version, RPC address and token so that the plugin can control the client. The RPC token would probably include whitelisted gRPC methods that were declared in the plugin, although I don't know how useful that would be given that plugins run as actual executables with access to the user's system.
The server should be able to make a request to the client to get menus in a JSON form that it can render. Forms should be able to have names and actions, and when a form is submitted in the client, the client will make a POST to /plugin/action/ with the JSON body generated by the form. This could also be used for one-shot button actions.
Plugins should be given access to a private per-plugin key-value API via the client RPC.
Plugins should have some built-in update mechanism where the client can check for new plugin versions and optionally automatically update from the URL. It would be cool if the plugin manifest included the update checker method, which would include support for RSS, GitHub and Forgejo. Also an optional public key for verifying plugins, like how the FriendNet updater works.
I also like the idea of installing plugins via a direct URL to the archive, as well as uploading the file through the client.
More ideas can be posted here.
It would be useful to have a plugin interface for the FriendNet client. Since the client is fully controllable using gRPC, I figure plugins could simply be an archive containing a manifest.json file listing the executables for each platform, version information, etc. When the client loads the plugin, it would just execute and own the process, and plugin would write a header and an address of a local HTTP server or UNIX socket to talk to, along with an authorization token to use when talking to it. The server would then make calls to methods like
/plugin/startor/plugin/stop. On the start request, it would include the client version, RPC address and token so that the plugin can control the client. The RPC token would probably include whitelisted gRPC methods that were declared in the plugin, although I don't know how useful that would be given that plugins run as actual executables with access to the user's system.The server should be able to make a request to the client to get menus in a JSON form that it can render. Forms should be able to have names and actions, and when a form is submitted in the client, the client will make a POST to
/plugin/action/with the JSON body generated by the form. This could also be used for one-shot button actions.Plugins should be given access to a private per-plugin key-value API via the client RPC.
Plugins should have some built-in update mechanism where the client can check for new plugin versions and optionally automatically update from the URL. It would be cool if the plugin manifest included the update checker method, which would include support for RSS, GitHub and Forgejo. Also an optional public key for verifying plugins, like how the FriendNet updater works.
I also like the idea of installing plugins via a direct URL to the archive, as well as uploading the file through the client.
More ideas can be posted here.