Plugin System: REST API and Webhook based Plugin System

[fabiangeissler]

Describe what problem this solves and why this would be valuable to many users

A lot of the smaller feature requests like #271 #1122 #1028 #466 #2133 #28 #2644 -- and I am sure there are a lot more -- could be solved by plugins using the existing REST API and to-be-implemented webhooks to trigger the plugin scripts. Also this would enable users to customize their workflow of downloading/sharing/editing/uploading based on how they want to use photoprism.

The plugin devs would not need to work through the entire photoprism codebase to add small features (and are also not limited to the go language). This will be interesting for people who just know a bit about scripting and increase the plugin dev userbase while the main developers can focus on the more important core features (like the new photo/video viewer 👍).

Describe the solution you'd like

I already kind of use a similar system, where I have python scripts for batch editing metadata, raw (only) image download, selecting the latest file in a stack as primary and WebDAV upload for stacking. This works well but needs a lot of manual script execution as there are no callbacks from photoprism yet.

It would be great to have for example in the selected photos menu (lower right corner) an additional button "Plugins" that opens a second set of icons -- one for each configured plugin. When one of them is clicked it POSTs to a webhook configured in the settings with for example a list of the selected photo UIDs in the body (and maybe other parameters, not sure what is required yet). Then the script can take over and use the REST API to to its thing on the selected images (download, stack, batch process, change primary, etc.)

Another thing would be general maintenance webhooks e.g. after finishing indexing (with new or modified photo IDs in the POST if that info is available).

I am sure there are some more places to put webhooks (image viewer for single image based plugins, general UI buttons for general operations e.g. start workflow, etc.) but the above mentioned would be the most relevant in my opinion and looking at the mentioned feature requests.

Another thing to think about would be authentication. Maybe use API tokens as auth keys or something similar, so the user does not need to enter their password in the plugin and can disable each plugin separately by diabling the API token. But for the start the existing user/pass auth should work for private scripts.

Describe alternatives you've considered

Manual script execution works, but is cumbersome. Getting selected images is not possible, used Album as workaround, but that's not very clean.

Additional context

I think the REST API is very powerful and easy to trace even without documentation by just manually doing what should be automated and looking at the requests the browser sends. I know the API may change without notice, in that case the plugin maintainers must adapt the scripts.

If this system gets implemented and used, I think it can even be exapanded in cooperation of photoprism devs and plugin devs by agreeing on new API features and webhooks, maybe even implementing plugin frames in the UI but I see that only in a distant future. For now the API can already do a lot of things and it should be possible to solve all the requests mentioned in the beginning. In fact I already did with my manual scripts.

Thanks for reading, I hope you like my Idea!

[graciousgrey]

Seems very similar to:

• Plugin System #117

[fabiangeissler]

The basic idea of a plugin system -- yes.

I have given a more detailed concept of implementation based on the least effort for the photoprism developers with commonly used interfaces. I assume the linked issue was too broad, and no one wanted to spend the resources to make a more elaborate concept. I have based my concept on the experience I have on working with scripts for the REST API.

As only the webhooks are missing (also, similar to #1450 and #2997) I hope it is realizable without too much effort and can be used by a lot of people that want to add functionality but fear digging in to the photoprism code base.