Repository navigation
Determining methods to curate packages #47
Description
Activity
Discussed on the https://github.com/orgs/fairpm/discussions/58 call, from a hosting standpoint, we might want to support:
- blocklisting plugins (or specific plugin versions) to disallow users of a service/host from using plugins that are blocked
Outside of the hosting context, an organization (I use WPCampus as an example because there have been conversations in there about this and I see this as a uniquely valuable solution for higher ed, specifically) might want to curate an allowlist as described in https://github.com/orgs/fairpm/discussions/58#discussioncomment-14036732, e.g. "I only want these xx specific, curated plugins to be available to my users."
There's some AspirePress work underway by @namithj for this now, and it's farther along than expected to this point. So far it's got a fairly sophisticated import, and will soon have a means of generating an allow-list for a subset of plugins. The proof of concept is going well, but would need a slightly different mechanism for blocking plugins than for subsetting allowed plugins. Related though; they could work in a similar manner. Still a work in progress, but end result would be a simple way of setting up a standalone aggregator for a manually curated list of packages.
@namithj has a proof-of-concept underway now. AspireHub will be a WordPress plugin that acts as an Aggregator for a curated list of plugins. To create a list, you'd browse available packages and add the ones you want to target. The POC for that is at https://sandbox.aspirepress.org/plugins/ where AspireExplorer has added a shopping cart. The icons etc would likely change so the metaphor isn't confusing, but essentially you can add your target packages to the cart. Viewing the "cart" gives you a csv list of packages which you can then export/import to AspireHub to use as a block-list or an allow-list, or to create a list of packages for bulk installation for a standardized environment.
Another potential approach for this will be the "starter kit" model that Bluesky uses. That model is DID-based, so won't yet work with legacy WP packages; not sure offhand if you can create a blocklist that way, but another alternative is to create your own labeller instance (once that spec is hammered out) and rely on the labels you apply to curate your list. Where appropriate, the labeller could be private for internal use. In the context of a host blocking certain packages, the labeller would want to be required within the hosting infrastructure, and the host may wish to hide its presence.
Ultimately there are multiple ways to achieve this objective, so I expect we'll see more than one solution developed. Of course, without disabling plugin/theme uploads or filtering them to eliminate blocked packages, there's no guarantee they won't find their way into an WP install anyway but that's the current situation, so likely addressed by scanning for the blocked packages or whatever mechanism the host employs.
One of the things web hosts do today is they limit plugins and themes (aka packages) from being used.
We need to think about ways to allow people to curate packages and set those lists.
One option would be to use moderation/labeling. In that case, we could hook in a moderation service that flags things as allowed/not-allowed. To do that, the FAIR plugin would need to use that moderation service, but also in a non overridable way. That is. we don't want users to be able to change/turn off the mod service.
Another option would be to make your own discovery aggregator that allows you to allow/block repositories, other aggregators, or packages themselves.
What are some use cases for this that we're not thinking of, to help us make a better curation method!