> I don't get why public stuff like NPM, DEB or Docker registries haven't switched to use it as primary way of distribution

2 of them are run by commercial entities. I don't think those are all that interested in reducing dependency on them.

Some links without comment: - https://www.npmjs.com/package/ipfs-npm - https://github.com/ipfs-shipyard/apt-on-ipfs - https://blog.ipfs.io/2020-02-14-improved-bitswap-for-contain...

>2 of them are run by commercial entities. I don't think those are all that interested in reducing dependency on them.

Docker is also removing some old images and putting limits on existing images, it's too expensive for them to host.

or it could be a strategy to move more people to a pay model.

In a lot of the world, upload speeds are very limited and ISPs charge an arm and a leg if you exceed your upstream data caps.

On top of that, Bit torrent has a tendency to overwhelm routers and make them slow to a crawl.

Those are a lot of downsides to ask your users to accept just so you can cheap out on download servers.

Perhaps there are routers that don't handle well large amounts of data, but from my experience what typically is happening are two things:

1. the fairness in TCP is done per TCP connection, bittorrent opens many connections so they take over the whole bandwidth. You can limit number of connections or throttle the bandwidth used by BT (of course you will get slower speeds), maybe there are some other ways.

2. when you maximize your throughput ACKs might get dropped which slows everything down (I suspect that might be the issue you're talking about) again you could throttle or enable traffic shaping and give highest priority to ACKs. This worked well for me.

3. Bufferbloat. It's still a thing. dslreports has a bufferbloat score, one of my coworkers has been really impacted by it. http://www.dslreports.com/speedtest

I heard about bufferbloat, but I didn't think it was related to bittorrent maximizing throughput

It depends: packet loss due to bitorrent is a problem, but low loss and high latency makes it dramatically worse, and that is the bufferbloat cast. If you have 1-30 second pings (or I've seen even worse), when doing torrents or other heavy outbound traffic, it falls apart.

Even 1 second is already pretty severe bufferbloat, let alone 30 seconds. Your latency should increase by under 25-125ms even with upstream and downstream both running flat out.

But all this can be adjusted with concepts like pining, rate limiting, queuing, connection limits, even geo-fencing. I would gladly share % of my server's unlimited transfer to give back a tiny range of Debian or DockerHub packages which I have dowloaded and use. And I don't want to mirror the entire distros, which is condition to become an official host of distro mirror.

> In a lot of the world, upload speeds are very limited and ISPs charge an arm and a leg if you exceed your upstream data caps.

Not all 1st world countries have data caps. I pay ~20$ for month for 37mbps (15 upload) with no data caps (it's literally the cheapest plan I could find, if there was cheaper available, I would take it).

in Russia i have a ~$15 plan 1gbps (~700 realistically)up/down unfortunately it's clear that ISPs are not going to be able to upgrade their hardware nor keep prices low due to government interventions, government controlled ISPs competetion, mandated DPI censorship(paid by ISPs) so very soon internet in Russia will be as shitty as in most western countries that lack competition

P.S. until 2009-2014 russian internet was completely out of government sight. an average internet user in big cities had a choice of 3-10 ISPs competing prices etc

With LPD, we could have two PCs upload to each other, it would be even beneficial to ISPs if everyone didn't have to download updates at a similar time from the furthest-away server. Especially in developing countries.

I don't get why machines running the same Linux distribution couldn't actually do the same. BT2 would indeed work very well for this.

Nixos/guix might be a good fit for rootfs on ipfs? Comes with a local cache, and you could overlay local changes (eg: /etc/passwd)?

Actually not exactly rootfs on ipfs, but with NixOS is fairly easy to make it wipe data on reboot, here's an example article[1]. The idea is to only keep state we care about and rebuild the system on every boot.

[1] https://grahamc.com/blog/erase-your-darlings

BitTorrent 2.0 is not recent, no.

The current bittorrent company is interested in chasing ICOs, I don’t think they work on new versions of the protocol anymore?

edit: yeah it’s from 2008

Going on a tangent but this article that came out today is a good read for anyone that didn't follow what happened to BitTorrent the company: https://www.theverge.com/21459906/bittorrent-tron-acquisitio...

People are working on BitTorrent yes! libtorrents blog made a blog post quite recently (September 7th, 2020) - https://blog.libtorrent.org/2020/09/bittorrent-v2/

That is libtorrent, unrelated to bittorrent, no? (organizationally)

Yeah, maybe you were explicitly talking about the company BitTorrent Inc.

"work on new versions of the protocol anymore?" made me think of the BitTorrent protocol in general, sorry for the misunderstanding.

I think you're right that the BitTorrent company aren't directly involved in the protocol work, they seem to be focused on trying to push their plagiarized cryptocurrency project.

Because changing things out is hard and the benefit of pulling in that much more code and complexity is dubious.

It seems like you could implement a p2p solution as a pull through registry... as in host a registry (even per node if you like) that Docker will use as a pull through cache, still speak the same distribution protocol, but have the registry use p2p to get the content.