| HN Mirror

You got it, yep; I should've been more precise about what I meant by self-hosting.

Smartphones and data plans would provide the bare necessities for self-hosting; in many cases there's abundant computing and bandwidth resource available to them. Many packages/containers are small and downloaded infrequently - any much data capacity, I expect, goes unused.

If and when smartphone-hosted resources become insufficient, a cloud VPS like your approach would be a next logical upgrade. Beyond that, corporate/foundation-based sponsorship and dedicated servers and bandwidth.

The key would be to make it near-seamless to migrate between those different environments. Namespaced source code repositories and packages appear to have worked well for the likes of GitHub, GitLab, NPM and Docker Hub, so perhaps following similar conceptual design ideas would make sense.

A few areas of concern would be:

- How do you keep end-user devices safe if they will be hosting content for a wide audience?

- How do you react to credentials and other protected content being posted if repositories themselves are a distributed network?

- How do you achieve discoverability and search of content in a distributed environment?

... not to mention whether the effort and migration to such a model is worth the benefits.

I tend to think it would be, since it aligns the incentives around spending, increases hardware utilization, and increases resilience by removing single points of failure.

That said, I also imagine there are well-founded and sincere arguments for continued centralized code and container hosting that are valid and worthwhile (not least of which: it's where we are, and it's relatively straightforward to reason about).