New improvements to IPFS Bitswap for faster container image distribution
blog.ipfs.io
blog.ipfs.io
Also, how well does BitSwap work when the underlying network is congested? Do IPFS nodes do any kind of congestion control?
https://docs.ipfs.io/guides/concepts/ipns/
TLDR IPNS are pointers to IPFS content (ie "latest"). If you're tracking your containers and pinning to their versions elsewhere, might not need IPNS.
So make each layer an own torrent?
If we can manage the assignment/padding to match ipfs fragments, that could result in a massive saving.
On top of that, most of them should already be able to understand that certain files already exist; but it seems like it’s more of a file-level feature at this point rather than block-level.
Is there something I am misunderstanding?
I mean, they have many devs, but that's still a few magnitudes below their number of viewers.
Developer tooling is a pretty limited part of their traffic probably
If Netflix is using IPFS for anything worth mentioning, it's almost certainly substantive enough to be considered an endorsement.
I say this as a developer for a FANG company.
It’s still an endorsement, but not nearly as strong as if the broadcasting was somehow relying on IPFS. As it is, this is probably just some engineering manager that made some non-crucial tool and put that on ipfs.
This is basically how booting from a disk image works on most cloud platforms too.
There was also a change later which turned off nodes being the middleman by default, but not sure which version.
It's supposed to be much better these days, but I haven't tried it again in a few months.
Trying to recall how the protocol works. Doesn’t this pattern of behavior mean that a lot of machines will end up with the beginning of a file and few will have the end? It sounds like the start of downloading would be very fast and the end would slow down while it hunts for a source
May be why this is only 20% faster than Dockerhub.
If I remember correctly, a node with a full file will send out the blocks in parallel, so leechers should receive blocks effectively in random order
The only reason for some machines having only the start versus the end would be implementation-wise, where maybe you see the want list ordered, and the seeder responds by only shipping the first n blocks it reads in the want list
If the seeder responds with random ordering, you'd avoid the problem of all leechers all having the same blocks
Hadn't seen that gem for a while.
but thats besides the point of the parent. web 2.0 hasn't really been mentioned in ages.
How do you do this? Exercise for the reader? :)
For the case of distributing containers in a datacenter with P2P, theres also this work:
IPFS and bittorrent don't do anything to protect the data you are uploading and your IP address.
Case in point: https://iknowwhatyoudownload.com/en/peer/
Now every website you visit, any ad/tracker, any homecalling phone app can tell what movies and contents you watch and when you are at home. For years.
It never looked like an anonymizing tool to me; did anybody advertise it as such?
People can be prosecuted or otherwise harassed for sharing contents on a P2P system.
> It never looked like an anonymizing tool to me; did anybody advertise it as such?
You are confusing "anonymizing" with "leaking a lot of information to the whole world".
They constantly "forget" to tell people about the huge security impact.
For the second scenario, you want another layer which maintains secrecy. (Like the tor transport https://ipfs.io/ipfs/QmYKQvBsbYrRhdaGvQXcEoSam7s5gKVYULfRgNP...)
In particular it's pointless to be able to circumvent censorship if you can't do so anonymously.
> IPFS and bittorrent don't do anything to protect the data you are uploading and your IP address.
And Netflix are using it across AWS for distributing container images, not touching client devices, unless you know something more than what the article says.
This doesn't have anything to do with customer's privacy.