Hacker News Reader

Comment by magila | Hacker News Reader

This has been the state of IPFS for years now. The protocol and client haven't been developed to where they can work reliably in a real P2P scenario. IPFS only appears to work because most requests go strait to one of the big gateways which already has the content cached.

Development of IPFS slowed to a crawl when most of Protocol Labs switched to working on Filecoin. It remains to be seen if either Filecoin or IPFS will ever be viable for their intended purpose.

View on HN

IPFS is the engine of Filecoin, though. Filecoin just incentivizes IPFS nodes to store things. So further IPFS development should still be necessary from the perspective of making Filecoin development/adoption happen.

(I say this, and yet I know it isn't true in practice. But why isn't it true?)

Pump up Filecoin price. Sell Filecoin. Move to Fiji. Don't do any coding while in Fiji

Ha. I was super surprised that my dad(almost 70) mentioned IPFS to me the other day. It turns out the people he know are running or thinking of running IPFS nodes because of filecoin incentive. Apparently, the people don't want to miss another bitcoin opportunity.

filecoin is also promoting in China. https://mp.weixin.qq.com/s/T0Qt2CEP7QsA6Zy9Vzvdkw

Yes, this is still the case. For a file which is on exactly one other computer, you have about 45 seconds lookup time before the download can start.

I'm not sure you are right about this. The following link will stream big buck bunny directly from the network with full P2P support. It is not using a gateway node for the video content.

https://bbb.fu.io/

You can run the following in the console to see all your peers

    for await (const peer of await node.swarm.peers()) { console.log(peer.addr.toString()) }

The console currently get's spammed pretty hard because they haven't implemented filtering out plain ws (non-wss) peers if you are connecting https. But it will use webrtc to find peers, and find all wss nodes in the network.

For me at least the vast majority of the data is being downloaded from various servers under bootstrap.libp2p.io or preload.ipfs.io. These are clearly dedicated servers not true peers.

The contact info for these servers appears to be retrieved via the DNS rather than the DHT. This isn't surprising because browser clients can't participate in the DHT, but the DHT is currently one of the biggest weak points of IPFS. IPFS's DHT is so chatty that it consumes over a megabit of throughput just to maintain an idle node. Lookups are excruciatingly slow and often fail completely.

Sorta, a peer can advertise dns addresses, and the browser can participate in the dht as a client. The example above uses webrtc-star for browser to browser discovery.

    $ ipfs dht findpeer 12D3KooWJxNHY6zE1KnzFdBJrTMCbhCVNtSLvjp7qR5Wsp49DnUC
    /dnsaddr/ipfs.scalable.io
    /dns4/ipfs.scalable.io/udp/4001/quic
    /dns6/ipfs.scalable.io/tcp/443/wss
    /dns6/ipfs.scalable.io/udp/4001/quic
    /dns4/ipfs.scalable.io/tcp/443/wss

Took a good 10 seconds until the video started playing. Anything over a second is too long in terms of UX expectations.

Reply on news.ycombinator.com