Hi all, I was doing my morning reading, and noticed that Microsoft have a Windows Package Manager in the works (https://www.theverge.com/2020/5/20/21264739/microsoft-windows-package-manag er-preview-download). While that might not be newsworthy for many people interested in FOSS, you might reconsider when you look at what they're doing for a community metadata repository: https://github.com/microsoft/winget-pkgs Here's an example of a metadata file for 7-zip in that repository: https://github.com/microsoft/winget-pkgs/blob/master/manifests/7Zip/7Zip/19. 0.0.yaml. It includes a URL to the installer and a SHA256 hash for integrity checking. Now according to https://github.com/microsoft/winget-cli, it doesn't look like they're using that Github repository as *the* metadata source repository. Indeed after a bit of digging it appears that the actual default metadata source is https://winget.azureedge.net/cache/source.msix, which contains a SQLite database of metadata (index.db). I think that's an interesting model. We could use http://gitlab.com/koha-community/plugins like https://github.com/microsoft/winget-pkgs where people could submit pull requests to get plugin metadata added to the repository. That would enable there to be a basic level of curation. We could then use something like https://plugins.koha-community.org/ to serve actual metadata (in whatever standardish format we want) to either the Koha web UI (and a Debian package Koha CLI tool like "koha-plugin-get" which make plugin deployment and maintenance potentially easier for sysadmins). There could be an automated process for updating plugins.koha-community.org from http://gitlab.com/koha-community/plugins too. People would be free to point to other plugin metadata repositories (e.g. vendor-specific repos), but by default it would be set up for the Koha Community plugin metadata repository. In terms of security, we could mimic Debian's Apt model of signing the plugin metadata manifest. That way, when setting up a plugin metadata repository in Koha, all you need to do is import a public key/cert to get trusted access to the repo. With the Koha Community repository, we could bake that public key/cert into Koha releases, so it would be seamless for end users. The hardest part of this process would be settling on what metadata manifest format to use for https://plugins.koha-community.org/. Actually, the hardest part would be trying to maintain some kind of backward compatibility. Maybe that's best done by rebranding the current plugin model as "Legacy Plugins" or "Manual Plugins" and then just building a separate web UI for the Repository model. We could re-use the same internals. We could also have separate controls for enabling/disabling "Manual Plugins" vs "Repository Plugins", so that vendors could provide access to plugins via a repository but prevent people from uploading random plugins from the Internet. Anyway, food for thought. I'm happy to do a lot of this work (probably in my personal time rather than work time), but I'd want to make sure there is some buy-in from other vendors and Koha plugin creators first. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595