Questions about decentralization: tackling reliability and performance

👋 First of all, thanks for taking the initiative in imagining and bringing forth this amazing 🌠 project.

Decentralization makes complete sense to me. But decentralization may also bring about some challenges. With a federated model I would imagine that there may be several /public/ registries operated by different entities (e.g. companies, foundations). I would imagine the the network of public JavaScript modules may end up with cross registry dependencies.

This may open up some challenges: If the client is supposed to fetch modules from multiple host registries, then the overall experience would be only as fast and reliable as the slowest and least reliable server.

One mitigation could be for the registries to proxy and cache between themselves and for the client to be configured to talk to a primary registry. Alternatively, the registries may actively cache dependencies on a publish. In other words, we can engineer the decentralized model to ensure that a single registry that a client is talking to has the transitive closure of dependencies of all packages it hosts. AFAICT, this is not the current plan for `entropic.dev`? Perhaps this can be a per-registry configuration?

The Go languages ecosystem has had a decentralized model where they [observed some of these drawbacks](https://blog.golang.org/modules2019). The approach they are using to mitigate these is via a /module index/ on top of the decentralized registries that has inventory across all public registries. This enables proactive caching, along with enabling a centralized search. This may be a model to learn from or there may be other ways to address this.

I would be very curious about what y'all think about this.