Tracking installs is difficult in a decentralized package registry management system. Below is a potential solution.
Includes adding features to the web app being developed at @csuwildcat/dpm
Solution
Add a field to the package protocolPath record data called "installs" that can be updated by anyone to track installs of that DPK.
Add a way to allow devs installing DRPM to OPT IN during postinstall to let us track dpk installs.
Set an OPTIN flag in a local file (i.e. package.json, .npmrc, etc.) to trigger conditional logic in the DRG routes that updates OUR dwn (dwn.drpm.tools) everytime a new DPK is installed to their local project.
This would bootstrap DPK discovery and provide a way to track installs.
Each time a user installs and runs DRPM to install a new DPK, DRG.
This requires us to add an API to the drpm.tools website that we can use to POST to for tracking installs
In this way, we can track installs in a distributed manner until we can deploy a DWN server aggregator to search for the drpm protocol in DWNs. We need not wait for DPK publishers to manually visit our site, signup and add their dpks. We can actually do discovery as early as the first install of a DPK and keep some minimal info about it in our DWN.
This would be a non-func feature / stretch goal for TAB, but def should be on the roadmap.
Tracking installs is difficult in a decentralized package registry management system. Below is a potential solution.
Includes adding features to the web app being developed at @csuwildcat/dpm
Solution
In this way, we can track installs in a distributed manner until we can deploy a DWN server aggregator to search for the drpm protocol in DWNs. We need not wait for DPK publishers to manually visit our site, signup and add their dpks. We can actually do discovery as early as the first install of a DPK and keep some minimal info about it in our DWN.
This would be a non-func feature / stretch goal for TAB, but def should be on the roadmap.