I opened a preliminary PR (open-services/open-registry#10) for Federation but probably best to go via a issue first, to better enable discussions around it. Here is what I've been thinking so far.
This proposed feature of Open-Registry opens up the ability to federate servers for serving the tarballs for the registry.
Running a global network of the scale of the npm registry will be impossible to do with just being funded by the community as the costs will be too high.
With Federation, the community can help with whatever resources they have available, to make the Open-Registry faster, more resillient and stable.
A user (person installing modules) using the federated Open-Registry should not notice it in their day-to-day usage as the registry continues to operate as normal for them.
A organization using Open-Registry could easily install a federated Open-Registry on-premise, saving bandwidth and time.
It would possibly introduce a new class of contributors to the Open-Registry, named "Registry Operators", who's responsibility is to make sure their registry is operating normally and it's up-to-date.
We need to keep the following in mind while designing and running it:
- Malicious people might try to be a part of federation honestly, until they aren't honest anymore
- Constant monitoring needs to be applied to make sure servers are not in a performance or otherwise degraded state
Currently, the cache lives in IPFS so we should take advantage of that and do the federation via IPFS.
The MVP of federation would be to decentralize the tarballs while leaving the metadata centralized for now.
So the central party (Open-Registry) would distribute a hash with the latest version of the registry that we've seen. Currently, there are a few ways of doing that, all have their benefits/drawbacks:
- GET request to npm.open-registry.dev shows the root hash (already implemented)
- Resolving npm.open-registry.dev TXT record reveals the same, albeit with a bit of delay (missing)
- Every time the root hash changes, we publish it on the
npm.open-registry.devpubsub topic in the IPFS network. (missing)
Implementing the federated mode would require a new mode where you can point your own Open-Registry instance towards the metadata index, and either choose to just download on-the-fly when needed, or mirror the full thing.
The thing with doing the federation over IPFS would be that to really take advantage of it, you would need to find a mirror close to you (latency wise) that has good bandwidth if you don't have IPFS installed locally.
Quick thought about how the discovery of mirrors would work is to have a collaborative list in source code, and allow people to add their mirrors there, exposing them under a endpoint. Last step that is missing is providing a tool for choosing the best of those mirrors. The mirrors should expose the standard IPFS gateway interface, as it's well defined.
The discovery of mirrors is basically automatic if people would run their own IPFS node. A small program implemented in Golang that embeds a go-ipfs node would make this very to simple, but not as simple as just pointing to a new registry URL.
Further down the line, we can offer some redirects either via DNS or HTTP where the closest trusted registry would be chosen automatically. This is simple but requires trust and DNS introduces unwanted latency regarding updates to packages.
- Lockfiles contains direct URLs to the registries
- HTTP routing needs a possibly slow redirect
- DNS routing would introduce latency for updates
- Direct IPFS usage requires users to locally run a IPFS node