Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IPFS is the Distributed Web

ipfs.io

Post reply on HN
Print view View original

171–180 of 286 posts

Re: IPFS is the Distributed Web

#171

Post by vegabook »

c22 wrote: post #88
vegabook wrote: post #50

IPFS appears here every 6 months, every 6 months the same questions get asked, the same problems get raised, the same collective sigh of bewilderment/disappointment appears to emanate from the comments, and it goes away again for another 6 months. Everybody wants something this clever and community-spirited to work, but the basic problem is, I don't want my data to be vulnerable to slow, unreliable endpoints, or peop…

I would say the impermanence is one of the most appealing aspects of the system. Content that no one uses and that no one is willing to sustain gets culled from the network, what more could you ask for?

I assume you would also like ext4 to automatically delete your seldom used files, without asking?

Re: IPFS is the Distributed Web

#172

Post by clueless404 »

wyager wrote: post #164
clueless404 wrote: post #144

Earlier quoted context omitted.

> 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 st…

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

Re: IPFS is the Distributed Web

#173

Post by diggan »

drivingmenuts wrote: post #161
vertex-four wrote: post #147

Earlier quoted context omitted.

All IPFS URLs contain the hash of the content, so you can't change it. There's a mechanism to allow for URLs which can point to varying bits of content, but I'm not aware of a paper which shows its security properties.

Upon further reading, it appears that it may be impossible to verify the security of an IPFS cached page, simply because the hash is calculated post-fetch on the client. That allows any sort of shenanigans to be performed on the original content before it's stored. If content is created specifically for IPFS-caching (similar to Freenet or Onion), then it may be possible to be authoritative, but content cached from th…

> Upon further reading, it appears that it may be impossible to verify the security of an IPFS cached page

Not at all, rather the opposite, it's very easy to verify a page since the hash is based on the content.

You have file "ABC" that you want to download. So you fetch it and once you have it locally, you hash it yourself and you compare the hashes. If they are the same, you know you have the right thing. If they are different, someone is sending you bad content.

Re: IPFS is the Distributed Web

#174

Post by clueless404 »

teekert wrote: post #169
clueless404 wrote: post #152

Earlier quoted context omitted.

> Well apart from battery, ... and that's pretty much the deal killer for this on mobile, even ignoring everything else. > If I was an ISP, I´d like it if a Youtube movie ... except you are not allowed to download videos from YouTube or most (if not all) the popular video content services. > a Youtube movie would flow from one persons mobile to the hotspot of the train said person is sitting on and on towards another…

> ... and that's pretty much the deal killer for this on mobile, even ignoring everything else. It is, for now, indeed. > Except you are not allowed to download videos from YouTube I think youtube would be interested in some load balancing if they could keep the income from commercials. Wait, what, there wouldn't be a need for YouTube. We'd only need a way to pay content creators build into the system (Ethereum coupl…

> I think youtube would be interested in some load balancing if they could keep the income from commercials.

Firstly, it's not up to Google. Secondly, how would that even work?

> Wait, what, there wouldn't be a need for YouTube.

Yes, there would. YouTube isn't the solution to a technical problem.

> We'd only need a way to pay content creators build into the system

Why?

That's also a pretty big "only".

> The same amount of bits are pumped around but they have to cover significantly less physical distance and hubs. This reduces bandwidth

No, it doesn't. What it reduces is bitmiles. Which may or may not be significant. Mostly not, but it may have some significant if we can lower the usage of some scarce and expensive radio bearer.

> Me pumping bits from my neighbor's house to mine instead of us both via the backbone from some server in a central location requires less (expensive) infrastructure between me and that central location.

Not really. You are still going to need that infrastucture, so no cost savings.

> indirectly they (we) pay for the copper and the fiber.

So we do, but using IPFS isn't going to result in us getting a check in the mail. Costs are still zero and savings likewise.

Re: IPFS is the Distributed Web

#175

Post by drivingmenuts »

diggan wrote: post #173
drivingmenuts wrote: post #161

Earlier quoted context omitted.

Upon further reading, it appears that it may be impossible to verify the security of an IPFS cached page, simply because the hash is calculated post-fetch on the client. That allows any sort of shenanigans to be performed on the original content before it's stored. If content is created specifically for IPFS-caching (similar to Freenet or Onion), then it may be possible to be authoritative, but content cached from th…

> Upon further reading, it appears that it may be impossible to verify the security of an IPFS cached page Not at all, rather the opposite, it's very easy to verify a page since the hash is based on the content. You have file "ABC" that you want to download. So you fetch it and once you have it locally, you hash it yourself and you compare the hashes. If they are the same, you know you have the right thing. If they a…

Re-read the original question. If someone is preventing access to the original page and the alternate is being served thru IPFS, there is no way to compare the original. The IPFS cached page becomes the authoritative page and could contain altered content, which the hash takes into account.

If the original page can perform the hash and embed it, that would somewhat alleviate the issue during the fetch, but do nothing to prove that the IPFS-served page was trustworthy or not, unless some third-party knows the original hash, as well.

If the page was served to the IPFS network, to be cached, by a neutral, trusted third-party, that would somewhat alleviate the problem, although there arises the problem of trust again.

The only way to minimize the trust issue is if the page originates from inside the IPFS network and is not a cached version of page originally served outside the network.

Re: IPFS is the Distributed Web

#176

Post by vertex-four »

drivingmenuts wrote: post #161
vertex-four wrote: post #147

Earlier quoted context omitted.

All IPFS URLs contain the hash of the content, so you can't change it. There's a mechanism to allow for URLs which can point to varying bits of content, but I'm not aware of a paper which shows its security properties.

Upon further reading, it appears that it may be impossible to verify the security of an IPFS cached page, simply because the hash is calculated post-fetch on the client. That allows any sort of shenanigans to be performed on the original content before it's stored. If content is created specifically for IPFS-caching (similar to Freenet or Onion), then it may be possible to be authoritative, but content cached from th…

You're right. I misread your parent's comment, which suggested that web pages could magically be cached securely into IPFS from the public web without any involvement from the website's owner, which is nonsense.

Re: IPFS is the Distributed Web

#177

Post by lkjhgfdsa57 »

pdkl95 wrote: post #156
clueless404 wrote: post #148

Earlier quoted context omitted.

> By simply not downloading and seeding it. ;) You seem to have glanced over the qualifier I used: accidentally. Given a hash for an IPFS resource, how do you know it does not contain child porn before you retrieve it? Once you have downloaded it you have committed a crime. There are no take backs with strict liability crimes and IPFS provides no anonymity, so there is a record of you downloading and seeding child po…

> Given a hash for an IPFS resource, how do you know it does not contain child porn before you retrieve it? Given a URL for an HTTP resource, how do you know it does not contain child porn before you retrieve it? > seeding https://freenetproject.org/help.html#childporn

> Given a URL for an HTTP resource, how do you know it does not contain child porn before you retrieve it?

As clueless404 stated, on the http web you don't automatically seed the content that you accidentally retrieved. On IPFS you're distributing it.

As an example, another posted here provided an IPFS link to resources, some of which are a copyright violation in some regions. In IPFS you can discover the nodes that are seeding it:

    $ ipfs dht findprovs ...contenthash...
    QmfWQHVazH6so9p27z27rr8TJSdBFGpH7hunDcaZ1EAQ2c
    ...
These are the node id's sharing the content. You can find all the IP addresses published by the nodes, including private ones:

    $ ipfs id ...nodehash...
    {
      ...,
      "Addresses" : [
        "/ip4/127.0.0.1/tcp/4001/ipfs/...hash...",
	"/ip4/192.168.1.5/tcp/4001/ipfs/...hash...",
	"/ip4/172.17.0.1/tcp/4001/ipfs/...hash...",
	"/ip4/1.2.3.4/tcp/4001/ipfs/...hash..."
      ],
      ...
    }
If your node accidentally retrieved a hash containing content that was illegal or otherwise bad your physical IP is easily discoverable.

A database of bad hashes is easily calculated given existing content using:

    $ ips add -n foo.mp4
    added ...hash... foo.mp4
This generates a hash for a file without uploading it to IPFS. You can then use findprov to see if anyone is sharing it.

Re: IPFS is the Distributed Web

#178

Post by lukasb »

clueless404 wrote: post #134
lukasb wrote: post #132

Earlier quoted context omitted.

The idea is that some fraction of users will be configured to reshare content, which helps distribution for popular content scale. This seems to work in practice for bittorrent.

Yes, but only for suitably popular content, as all the dead torrents will testify. This doesn't make IPFS very appealing to Joe Blow, content maker unextraordinaire.

IPFS isn't meant to provide hosting. It's meant to help you scale distribution. If Joe Blow's content isn't that popular, he doesn't need IPFS anyway.

Re: IPFS is the Distributed Web

#179

Post by Taek »

traverseda wrote: post #125
Taek wrote: post #112

Earlier quoted context omitted.

A search engine via ethereum is not going to scale, is not easily upgraded, and will fall far short of any properly centralized search engine. If you want a competitve decentralized search engine, you're going to need a different technology.

I think that's why they talk about homomorphic encryption.

Homomorphic encryption as best I'm aware is more than a decade away from practical use. I believe the best libraries today have blowups of 100,000,000x in resource usage, meaning it's not even practical for basic crypto operations.

Multiparty computation makes some security sacrifices (breaks if M out of N people cheat, breaks undetectably iirc), but I think the blowup is less than 10x for some operations and less than 1000x for the others.

Still not pretty, but at least makes certain things possible. But not competitive search engines.

Post reply on HN