Hacker News Reader

Comment by lordofgibbons | Hacker News Reader

A note of caution for those unfamiliar with how IPFS works.

It's very similar to BitTorrent with how content distribution happens. Your local node will broadcast which content it has available (downloaded).

If you access a piece of content you automatically become a host for it so you still need to use a VPN if you live in a country where you can get sued.

View on HN

I think your post needs to clarify this is true only if you use the ipfs client to access things hosted on ipfs.

Accessing ipfs.io/ipfs/ doesn’t do anything you mentioned. Its just a gateway.

You could take the link on the main submission. And replace ipfs.io with any (most, because some are offline) of the links here https://ipfs.github.io/public-gateway-checker/

And it will still work.

That's true, and I should have clarified that.

However, is using a proxy like ipfs.io really using ipfs?

If everyone did that, there's no point to using this protocol. The strength of the network comes from the fact that the content gets replicated/distributed when accessed. That doesn't happen when accessed through a proxy.

The benefit is ease of access, if content gets blocked on one mirror (ipfs.io), it may be available on another (cloudflare-ipfs.com/ipfs/, etc)

>However, is using a proxy like ipfs.io really using ipfs?

Yes! Because the gateway can go down and you can still access the content via local IPFS node or by using another gateway.

Tangential, but does anyone know what's happening with the JS IPFS implementation? when I tried it a while ago it seemed broken.

The implementation works well, but has limitations. It only works from browser to node and not browser to browser. Depending on what you are looking for it is more or less fast

Using Brave it makes this very clear, the above link won't open by default without the user choosing to run a local node or use a public gateway instead. It explains the implications of both options.

Screenshot: https://i.imgur.com/ZP6AgPp.png

Most browsers don't support the ipfs protocol and instead only use the gateway.

I love Brave, so useful.

That might be how some client(s) work, but I don't think that is how IPFS works.

If you access a piece of content over ipfs.io for example, I would think you just make https requests like to every other website.

Because its using a gateway. I think if you are accessing it natively through IPFS, it will default to adding you as a peer.

That would hold true if IPFS would be a specific application.

But it is a protocol.

I would not expect that the protocol specifies that a complient client shares what it downloaded. That sounds more like a choice the client developers make on their own.

But I'm happy to be corrected if someone has a link to the protocol definition and it says different.

By default, what the GP says is true. If you can point to specific popular clients that do not have that behavior by default then I think that would be more convincing than saying "Well technically there's no requirement" when it's impossible to avoid in practice without writing your own custom implementation from scratch

Afaiu, [Lassie](https://github.com/filecoin-project/lassie/) is the latest and greatest of IPFS clients and it does not store/provide any data that you access

AIUI Lassie uses indexers to locate content instead of using a distributed hash table (DHT). So a content identifier (CID) might be present on IPFS (and downloadable by a regular IPFS client), yet 'invisible' to Lassie.

If my understanding is correct, it can't be considered a complete IPFS client.

https://docs.filecoin.io/storage-provider/architecture/netwo...

https://en.wikipedia.org/wiki/Kademlia

I think it uses indexer and saturn (which ought to fall back to the DHT if it hasn’t cached the content of a CID already). That said they have a GitHub issue tracking CIDs that are retrievable via Kubo (fka go-ipfs) that aren’t yet retrievable via Lassie - it suggests to your point that there must be some difference; it also suggests they intend for retrievability parity though, so fingers crossed!!

This issue, right?

https://github.com/filecoin-project/lassie/issues/136

Yes and the many IPFS implementations (I've tried them all) consume tremendous amounts of bandwidth and require shocking levels of system resources (considering what it does fundamentally).

There's an entire cottage industry of IPFS pinning and gateway providers that exist largely because of the challenges of running your own IPFS node for anything beyond casual use.

Ipfs is is a neat project with a lot of interesting ideas. but, yeah, the deamon is often way too resource hungry. I would like to see a lite/embedded mode that would better run in resource constrained or casual setups.

If you access a piece of content over ipfs.io, and you don't have your browser set up to actually do those requests over a local IPFS daemon, you are not using IPFS. You are just using a normal centralized website.

It depends if you run a node or are accessing via a proxy/gateway

Is it recommended to run my own proxy then, and is there any boilerplate project out there? I could also use OpenVPN, but seems like I just want to proxy ipfs, not my whole connection.

Also AFAIK if no one acceses the content for a long time, it can get lost, like torrents.

But now, I dont know why, theres a lot of IPFS pinning service I got HUGO hosting in GH and deploying in FTPS from fleek.com. It has nothing on it but it works like a charm.

No, you are actually accessing the web. But you have to download using torrent, so to some extent it is true what you note.

Reply on news.ycombinator.com