Refactor DRG server

[bnonni]

if someone publishes a package to their DWN, it'll contain a ref to the location of where the tarball for that package can be downloaded. in normal npm packages, this looks like so

{
  "dist": {
        "tarball": "https://registry.npmjs.org/tool5/-/tool5-1.0.1.tgz"
   }
}

currently, the metadata.json in the DWN package record looks like this

{
  "dist": {
        "tarball": "http://localhost:2093/@drg/tool5/did:dht:somedid123^1.0.1/-/tool5-1.0.1.tgz"
   }
}

using nginx, we would be able to swap out localhost for whatever we want (e.g. local.registry.drpm.tools)

{
  "dist": {
        "tarball": "http://local.registry.drpm.tools/@drg/tool5/did:dht:somedid123^1.0.1/-/tool5-1.0.1.tgz"
   }
}

With the localhost:port pattern, if a dev publishes, the tarball url will be locked against this port number. If they spin up DRG on a different port, everything breaks, so we need a different solution, and the initial reaction is to run an nginx server locally to do proxy bypass from port 80 to localhost:2092.

However, I am now realizing that this all may be an unnecessary leftover from struggling through getting npm install hooks to work right. I may be able to swap out localhost URLs for remote host DRLs targeting the DWN and returning the tarball to npm without using a DRG localhost and without writing anything locally. The below DRLs would potentially go inside package.json and/or metadata.json returned from the DWN.

Package DRL Example

https://dwn.nonni.org/did:dht:bnonniabc123/read/protocols/aHR0cHM6Ly9kcnBtLnRvb2xzL3Byb3RvY29scy9kcG0/package?filter.tags.name=tool5

Package/Release DRL Example

https://dwn.nonni.org/did:dht:bnonniabc123/read/protocols/aHR0cHM6Ly9kcnBtLnRvb2xzL3Byb3RvY29scy9kcG0/package/release?filter.tags.version=5.0.1

The data returned from Package would be application/json. The data returned from Package/Release DRL application/octet-stream.

Questions

1. Can I bypass using a localhost DRG and put a package/release DRL directly into package.json?
2. If not, I'll need to use a localhost DRG to intercept npm install to divert the hooks based on the semver string in the package.json dependencies, which is where the DRL will be placed. Can I reduce the DRG server routes to only 1 route that fetches the tarball and does not bother fetching and writing the metadata locally? If so, I can bypass the fetch for package metadata, directly fetch the package/release, and return it as an octet-stream to npm install. This would allow negate the need for the "tarball" url in the metadata.json entirely, which directly solves the problem.
3. If not, can I do 2 but instead of returning tarballs in the first call, keep only 1 route that does both: fetch metadata then fetches tarball does not write anything locally and sends back the tarball to npm install?
4. If not, I can still do 3, but I need to write everything locally to the @drg mock registry folder.

[bnonni]

1. Yes, this works. Results in a nasty dependency in package.json, but it works. However, it defeats the purpose of using the DID because it assumes knowledge of the DWN endpoint.

   "tool5": "http://localhost:3000/did:dht:8w7ckznnw671az7nmkrd19ddctpj4spgt8sjqxkmnamdartxh1bo/read/protocols/aHR0cHM6Ly9kcG0uc29mdHdhcmUvcHJvdG9jb2xzL2RwbQ/package/release"

2. Can't use a DRL in semver for the same reason as step 1
3. Yes, this is the next path forward. Defining convention around package.json dependency and how to pass the relevant information to query the package record and the release record.
4. Yes, this should also be done as part of step 3.