Migration tool to change update source

[chuckadams]

Let's say someone has Connect installed, and has installed a plugin from the .org repository, and now that plugin is available for updates via FAIR (that is, indexed by AspireCloud) for one of two reasons:

1. The author publishes it on FAIR, via a PLC DID
2. It's available via a web DID on AC (already the case for every extant plugin on .org)

Right now the only way to change update sources is to uninstall the old plugin and reinstall the new one via the DID (probably through FAIR Explorer), which is not only cumbersome, but risks losing data through the uninstall/reinstall cycle. We should look into creating a migration assistant of some sort, either within Connect or a separate plugin, that would change the installed plugin to be managed through FAIR instead.

The first case, the author moving to FAIR, would mean we'd want some verification process that ensures that they're the legitimate owner of the plugin. Including a DID in the plugin header of the last version published on .org would be necessary to tell the migration plugin what to actually migrate to, but will also suffice as a challenge to prove control of the original.

The second case would be more a convenience thing for sites that just want to stop speaking the legacy update protocol. Probably too niche to worry about (most people installing Connect are going FAIR from the start) but smoothing the path for late adopters still makes for a nice UX. But overall it's PLC DID migrations we want to be most concerned with.

Note BTW that this isn't about the update process for Fair Connect itself, since Connect uses its own self-updater.

Also out of scope is composer installs, since composer users can simply switch to a FAIR repository in their composer.json if they wish. A command line tool to migrate a composer.json could be nifty, but would be even more niche than the web DID case.

[namithj]

Is there an easy way for us to detect the fair version of a plugin without polling?

If the update checks in a plugin can give the DID via AC, we can replace the update available notification with another one which can say something like "Plugin available via FAIR" and can handle the update process without breaking stuff (we cant be a 100% certain as changing the directory of the plugin will break the settings of atleast a small number of plugins).

[chuckadams]

For a .org plugin with a web DID, the detection is simple: just assume it's there, and the web DID is a simple string transformation of the slug. For a PLC DID, it'll have to appear in the plugin header, because slugs in FAIR aren't unique and collisions are entirely possible. (The way AC works now, slugs are in fact unique, but that's a defect in AC)