Hacker News Reader

Comment by rl3 | Hacker News Reader

Curious world we live in, where the infrastructure behind so many OSS projects can simply be acquired.

What's preventing the dream of decentralization from taking off? We have the technology.

Money prevents it. It takes money to host things and pay people to work on infrastructure. While people often volunteer to contribute to OSS products because they like or use them, not many are willing to write infrastructure that can handle this kind of traffic in their spare time. Even if you can find someone to donate the time, you'd still need to fund that infra in some way. Having an infra company (say, Google donates a bunch of GCP credits) to cover the hosting costs still puts the project at risk if the host company decides to stop funding.

I seed several torrents for OSS, it's not much but that's about all I can do to help.

Whatever happened to people hosting things in an old computer in their basement? That used to be a more popular thing back in the days before the cloud came about and before we had these stable broadband connections. Obviously an infra like npm couldn't deliver with such a setup but at scale, who knows

Was that ever really a thing though? When I dig through my memory (and READMEs on old hard drives) I see a lot of .edu addresses. Seems the good-old-days of the internet wasn't about hosting things on an old computer in your basement but rather hosting things on an old computer in your school's basement.

And around the time when home connectivity became good enough that people considered home hosting was also around the time Slashdot was created.

Maybe you don't remember BBS systems. I know a bunch of people who hosted BBS systems "in their basement", hooking up multiple phone lines (4 or more) and multiple modems connected to a C64, or an Amiga, or a PC. And yes, we were calling all over the country (and the world) to exchange software, programming tools, games, etc. The good old days.

Many early dial-up ISPs offered static IPs for hosting FTP/HTTP/SMTP/MUDs etc.

Or you could host with the ISP

I had a members.aol.com/benibela site or something

Start a non-profit 501(c)(3). Only a non-profit can acquire the assets of another non-profit, so it's somewhat of a poison pill. Budgets for orgs listed below are anywhere between $100k up to a few million dollars per year. This doesn't mean you can't run on a shoe string; Hacker News and Pinboard run on single servers with hot spares.

Examples: Let's Encrypt (Certs), Internet Archive (Culture), Quad9 (DNS), Wikipedia (Knowledge), OpenStreetMap (GIS), Python Packaging Authority ["PyPi"] (as part of the Python Software Foundation)

EDIT: Seriously, start non-profits whenever considering implementing technology infrastructure you're unlikely to want to extract a profit from and are seeking long term oversight and governance.

There are laws, non-profits executives & boards must follow, but there is nothing stopping any of the non-profits you listed from selling any assets you listed with them as long as doing so is in the best interest of the nonprofit; which at best is a subjective topic, at worst, easily dismissed given properly crafted pretext & reasoning.

Generally speaking, much like for profits, it is the people that run it that decided its culture, not a legal structure.

Legal structures don't enforce good behavior, but it always helps to nudge folks in the right direction. As you mention, culture comes from people, and culture is the foundation of every org.

open whisper systems

For those not in the know, this is Signal/Signal Foundation. Great example, sorry I missed it.

There's nothing stopping someone from pulling code from an alternate package registry, or directly from someone's computer. So all the required decentralization infrastructure already exists. For people to use it, though, it has to be convenient.

The average developer isn't interested in showcasing their social/political views, starting a revolution or building the future of the internet. They just want to get the job done as quickly and effectively as possible and go home.

Are you interested in mitigating risk by reducing central dependencies? I am. But it's too costly right now.

All being equal, though, we should try to avoid technical systems with unnecessary trust relationships and critical concentrated dependencies, though.

And if we must have a concentrated dependency, we should do our best to pick very trustworthy ones-- both based on their track record and their likely future interests relating to organizational structures.

What kind of risk though?

If you don't trust the code itself – it doesn't matter where it is hosted. Validation/audits etc. are essential in any case.

If you don't trust the reliability/uptime of the central service — it's trivial to create a private mirror containing the packages you want. Every internal build system I have seen does this already.

All kinds of risks. Risks of being co-opted. Risks of no longer being maintained. Risks of poor administration. The risks you mention-- availability, etc.

NPM's had its share of catastrophes and controversies that have made things tougher and caused harm to downstream users. It has also saved lots of effort.

Focusing on e.g. mirroring misses the point, IMO: One's dependency on something fundamental like package infrastructure isn't to survive one deployment or minimum sustaining, but to be an ongoing part of your technology stack. Yes, you can move on, but it'll be costly. If the component decides to start to suck, you're going to feel pain.

Mirroring is the correct strategy. You either do something yourself or you let someone else do it.

I remember some years ago when npm was having a lot of stability issues because the guy just was not being given adequate time/resources from Joyent or whatever, I made a post on r/node saying now was the time for a fully decentralized package registry.

The post if I remember was mostly ignored, but received a few downvotes and maybe a couple of negative comments.

Based on that, it seems that what's preventing decentralization from taking off is ignorance and apathy.

A day or two later the guy announced npm, Inc. if I remember.

There are actually a lot more developers that have accepted a federated services worldview than a peer-based fully distributed one. But there are package registry projects along both of those lines.

https://github.com/orbs-network/decentralized-npm

https://blog.aragon.one/using-apm-to-replace-npm-and-other-c...

https://github.com/entropic-dev/entyropic

https://github.com/axic/mango

But again, ignorance, apathy, and the status quo remain the most popular options.

From my own attempts at developing a decentralized service I've learned that there is no free lunch. Consensus is still unsolved without resorting to a nuclear option like a blockchain. Federation is a far better strategy. Let people host their own instances and let instances interact with each other.

NPM by it's very nature is a centralized repository, not really an agent of decentralization, where you'd get code from the authors' sites/servers directly.

Ubuntu and Debian have mirrors of their apt repositories hosted all around the world by groups, schools, businesses, etc. There is no single point of failure, you grab from the best mirror near you.

That still isn't decentralization: There may be a bunch of mirrors, but there is still a single "source of truth". One entity determines what is acceptable and valid in a repository model, as the entire ability to trust packages you install tends to be on the assumption that entity is making good choices.

Who pays for that decentralized infrastructure though?

This is the dream of the token model for networks like Bitcoin, Ethereum or Filecoin / ipfs.

it can be the cost of access

>What's preventing the dream of decentralization from taking off? We have the technology.

Time and money.

discoverability mostly... the social aspect a second, smaller issue.

I think this is probably a good thing in general, and should maybe lead to some interesting enhancements, and maybe even finally solve the distribution of binary modules at a better level.

See: left-pad

Reply on news.ycombinator.com