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

IPFS and Their Gateways

daniel.haxx.se

Post reply on HN
Print view View original

21–30 of 63 posts

Re: IPFS and Their Gateways

#21

Post by bananskalhalk »

janandonly wrote: post #4

So basically CURL will get support for IPFS by using a proxy service (which is bad for user privacy). And said proxy could bounce your request around for max 30 hops before a random IPFS-proxy honors the request. This is horrible for user privacy. Brave browser [1] at least has a native support for IPFS and no need for proxies at all. > Other IPFS privacy concerns: Brave, the browser, has actual native IPFS support (…

Max redirs in curl defaults to 50. Most browsers default to around 20. 30X (in the article) is a range of status response codes. You would probably benefit by rereading the article.

Re: IPFS and Their Gateways

#22

Post by londons_explore »

sneak wrote: post #19
londons_explore wrote: post #16

IPFS isn't fit for purpose. It needs censorship-resistance added. It needs user privacy added. Both of those could be enabled by combining data blocks semi-randomly. Ie. rather than downloading the data you're looking for, you download a block of data containing what you're looking for and some other data. Then nobody knows what it was you were looking at. Some combined blocks might contain a few bytes of data from t…

ipfs is a transport, not a storage system. you don't store things "on ipfs" any more than you store things "on http". http and tcp, other transport systems, also do not have censorship resistance. it's the wrong place for it. you can use ipfs to build a censorship resistant system, just like you can with tcp, but that is the purview of a higher layer.

A new version of IPFS would be both transport system and storage.

I don't think it's possible to reasonably to maintain layering while adding privacy and censorship resistance.

Re: IPFS and Their Gateways

#24

Post by waynenilsen »

This article made a false statement

> the gateway is in full control and can inspect and tamper with the data as much as it likes. And there is no way for the client to know or detect if it is happening.

Regarding data tampering;

IPFS uses content based addressing, the point is that the client _can_ know by computing a message digest of the incoming data. The verification is fast and cheap.

Re: IPFS and Their Gateways

#25

Post by danpalmer »

waynenilsen wrote: post #24

This article made a false statement > the gateway is in full control and can inspect and tamper with the data as much as it likes. And there is no way for the client to know or detect if it is happening. Regarding data tampering; IPFS uses content based addressing, the point is that the client _can_ know by computing a message digest of the incoming data. The verification is fast and cheap.

> The verification is fast and cheap.

And yet the most widely used IPFS client, Brave, does not implement this.

The blog post is technically wrong, but I think it's worth accounting for the general state of the ecosystem in these decisions, and in whether to include IPFS in cURL, and it sounds like the general state of the ecosystem is not up to the standards that cURL should reasonably expect from a protocol asking for inclusion.

Re: IPFS and Their Gateways

#26

Post by Nemo157 »

waynenilsen wrote: post #24

This article made a false statement > the gateway is in full control and can inspect and tamper with the data as much as it likes. And there is no way for the client to know or detect if it is happening. Regarding data tampering; IPFS uses content based addressing, the point is that the client _can_ know by computing a message digest of the incoming data. The verification is fast and cheap.

The hash you have is computed from the hash of the content and other data. You would need to send that additional data out-of-band to allow the client to compute the overall hash and verify it. (Not to mention with urls like ipfs:///some/path you only have the hash of some arbitrary parent node, so there's even more additional data necessary to be able to verify that the content at that path under the hash you have is valid).

Re: IPFS and Their Gateways

#27

Post by jstanley »

danpalmer wrote: post #25
waynenilsen wrote: post #24

This article made a false statement > the gateway is in full control and can inspect and tamper with the data as much as it likes. And there is no way for the client to know or detect if it is happening. Regarding data tampering; IPFS uses content based addressing, the point is that the client _can_ know by computing a message digest of the incoming data. The verification is fast and cheap.

> The verification is fast and cheap. And yet the most widely used IPFS client, Brave, does not implement this. The blog post is technically wrong, but I think it's worth accounting for the general state of the ecosystem in these decisions, and in whether to include IPFS in cURL, and it sounds like the general state of the ecosystem is not up to the standards that cURL should reasonably expect from a protocol asking…

Brave uses its own local gateway running go-ipfs. go-ipfs verifies the content, so Brave does not have to.

You only have to verify the content yourself if it is not being verified by someone you trust (i.e. a local gateway that you're running yourself).

Re: IPFS and Their Gateways

#28

Post by jstanley »

xd1936 wrote: post #5

This is silly. You could say the same for files CURLd from servers over http today. Did you know that when you download files from the internet, you're putting yourself at risk of the server tampering with your file before serving it to you??

But the point of IPFS is to do better than this.

The point of IPFS is that the server can't tamper with the content because it would break the hash, but if you're using an untrusted proxy then it is just as bad as using an untrusted proxy for your normal web browsing.

Re: IPFS and Their Gateways

#29

Post by hickimsedenolan »

londons_explore wrote: post #16

IPFS isn't fit for purpose. It needs censorship-resistance added. It needs user privacy added. Both of those could be enabled by combining data blocks semi-randomly. Ie. rather than downloading the data you're looking for, you download a block of data containing what you're looking for and some other data. Then nobody knows what it was you were looking at. Some combined blocks might contain a few bytes of data from t…

Or you could just use Freenet, thus not re-inventing the wheel.

Re: IPFS and Their Gateways

#30

Post by cowtools »

danpalmer wrote: post #9
neilalexander wrote: post #3

> the gateway is in full control and can inspect and tamper with the data as much as it likes Inspect, yes, but tamper? IPFS content IDs are hashes, so it seems like it should be possible to verify what you have been sent if you really cared enough to do so.

Possible, yes, but probably the most widely used IPFS implementation – the Brave browser – does not implement this yet. They say they plan to in the future.

I would think that the browser plugin + daemon is the most common implementation.
Post reply on HN