Hacker News new | ask | show | jobs
by jka 2052 days ago
This is an important conversation and I can't help but think that it is repeatedly drawn in predictably valley-minded directions.

As a responsible developer your use case is likely: "I want to install package X, and know that my customers are receiving and installing that package when they perform a build"

The fact that individuals cannot self-host content has been held back by the limitations of DNS (content addressing) and IPv4 (routability) for a long time now.

What I ask is this: if you as a developer were able to self-host the libraries and applications you offer to others -- regardless of whether they're open source or proprietary -- would that not solve most of these perverse incentive situations?

- The bandwidth costs would be yours, but that would allow you to find a charging model that works

- If your software became extremely successful - beyond your own ability to pay for the bandwidth - then the companies and individuals who rely upon your software would be incentivized to step in to foot the bill

- Data about software adoption and usage would be de-rigueur shared with the providers who offer the bandwidth for it

- We would not be reliant (in a community sense, but also in a day-to-day operations sense) on the benevolent albeit often-loss-leading hosting of centralized repositories

1 comments

How can we not self-host? For lots of these you can if you want. I mean, I host docker images and various packages that folks source from our infrastructure. I don't see DNS or IPv4 as a blocker
A 13 year old dabbler cannot self host using their home connection. And that is arguably a problem.

Hell I don't know how I would self-host, I just (reluctantly) put stuff on paid-for servers. I guess you start by calling your ISP and asking if they can pretty please give you a static IPV4?

Ok, I get it. I host on a cloud VPS which costs $$/mo - I don't consider hosting on home system a blocker.

Even still, you don't need a static. Easy to do DNS map and punch a hole in your FW or have some DMZ.

There is not a way to solve for zero-cash and zero-work

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).

From what I heard, hosting on dynamic IP is unreliable.