Hacker News new | past | comments | ask | show | jobs | submit login

> In which way is IPFS immune to content takedowns?

In the way that, if one node is forced to take down some information, that information may still be accessible from other nodes under the same address as before. It's not quite immunity: They can still harrass individuals. Call it "resilience", maybe.

> IPFS provides no anonymity, so it won't take long before DMCA notices to start arriving.

It should compose well with Tor, I'd hope.




Which makes it about as resilient as regular content hosting, which is not very.

Does IPFS work with Tor?


>Which makes it about as resilient as regular content hosting, which is not very.

It is decidedly more resilient than regular hosting in that situation.


How so?

IPFS so only as resilient as you are good at dodging DMCA notices.


Because mirroring content on IPFS is trivial and transparent to the consumer. All it takes is a single user (or an arbitrary number) outside of US jurisdiction and the content is more or less DMCA-immune.

The equivalent is not practical in traditional HTTP, where content at risk of being taken down is scraped from the server and that snapshot-in-time is hosted as a mirror, generally at a different domain.


> Because mirroring content on IPFS is trivial and transparent to the consumer.

Which is also why a regular consumer should never use IPFS and why prosumer should immediately disable caching and seeding upon install.

> All it takes is a single user (or an arbitrary number) outside of US jurisdiction and the content is more or less DMCA-immune.

Perhaps so, but if your plan for resiliency is based on the kindness of strangers in countries where the DMCA nor censorship does not apply, it's not much of a plan.

Plus you'll still have to seed the original which opens you up to liability, as IPFS does not provide any kind of anonymity.

So, while better than traditional HTTP, IPFS isn't really immune to takedowns nor very resilient.


>Which is also why a regular consumer should never use IPFS and why prosumer should immediately disable caching and seeding upon install.

Unless they changed policy, seeding is strictly a manual, opt-in process.

>Perhaps so, but if your plan for resiliency is based on the kindness of strangers in countries where the DMCA nor censorship does not apply, it's not much of a plan.

I disagree, IPFS is a pretty reasonable plan for resiliency in the case of static web content, as previously discussed.

If instead of "kindness of strangers" you frame it as a "market with incentives" to maintain information availability it is both less condescending and more accurate to how situations are likely to play out with things like DMCA'd content.

>So, while better than traditional HTTP

(which is all it needs to be)

>IPFS isn't really immune to takedowns nor very resilient.

That wasn't the goalpost we originally set, nor one of the project's longterm objectives, so I'm not sure the relevance.


> Unless they changed policy, seeding is strictly a manual, opt-in process.

Pinning may be manual, but is not content automatically cached and seeded (until purged from the cache) once any content is retrieved?

> I disagree, IPFS is a pretty reasonable plan for resiliency in the case of static web content, as previously discussed.

How is it a reasonable plan to exploit the naive and the uninformed or to depend only on those that are outside your juridistiction and unassailable by their own?

> If instead of "kindness of strangers" you frame it as a "market with incentives" to maintain information availability it is both less condescending and more accurate to how situations are likely to play out with things like DMCA'd content.

What incentives exactly would those be?

I also find it interesting that you object to kindness from strangers.

>>So, while better than traditional HTTP

> (which is all it needs to be)

That might not be sufficient for IPFS to get enough adoption, tho.

>>IPFS isn't really immune to takedowns nor very resilient.

> That wasn't the goalpost we originally set, nor one of the project's longterm objectives, so I'm not sure the relevance.

Fair enough. It is however relevant in the sense that it both removes a use case and acts as a disincentive for users to participate, as there is no liability shielding.


> Perhaps so, but if your plan for resiliency is based on the kindness of strangers in countries where the DMCA nor censorship does not apply, it's not much of a plan.

Have you ever used Bittorent? It works great.


It works great only for a limited number of use cases.

It's terrible for unpopular content, it is not immune to takedown notices nor is it very resilient in the face of a determined adversary.


Backing 'long tail' content with webseeds works well for Bittorrent.

...but that's the same as saying let's back the decentralized web with centralized resources erp.


Exactly. Which begs the question of why bother with the decentralization part at all of long tail / unpopular content?


That's what zeronet is for.


Could you expand on that?

Zeronet offers no anonymity, you have to use Tor for that.


Torrents work for content that is heavily seeded, but you also have a lot of content that has ~0-5 seeders with very bad bandwidth.

I don't see how IPFS tackles the problems of guaranteed availability and enough redundancy while relying on volunteers to mirror and serve content.

Also, if you want to DDoS content, it sounds like all you need to do is find the IPs of the nodes that host the content you want to target (which might not be many, and I guess become visible to you once you access/download that content) and knock them out

Unless I missed something?


Have fun when all your DDOS bot ips get added to null route on my ISPs level.


It's not like the grandparent is advocating DDOSing, he is just pointing out that doing so is trivial for less popular content. This is something that IPFS doesn't address, but that their marketing fluff implies would IPFS would take care of.

Good luck adding all DDOS bot IPs to your null route.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: