I have a problem understanding why IPFS behave in a specific way in the following scenario:
I have two nodes - js-ipfs webapp and go-ipfs daemon running.
I’m adding a photo file using the webapp - no problem here.
I then try to use the cat command to get the photo using the go-ipfs node, I’ve try both HTTP API endpoint and command line, both behave in the same way - they get stuck.
When I use gateway.ipfs.io to ask for the same hash I get the photo file between 5s - 50s.
Once the gateway returns the photo file I can then ask the same hash from the daemon and now it returns it instantly.
In the discussion they talk about opening firewalls, in my usecase I can’t expect anyone to open any firewalls because the end users will use the app from anywhere, including their home network and they should not have to touch anything related to firewalls.
Why is the gateway nodes are able to retrieve the content while the go-ipfs node doesn’t?
I’ll check but I’m pretty sure they are not part of each other swarms.
I did check that each of the nodes has at least one common peer in their swarm, even though I don’t think it’s required - the whole point of P2P network is that a path between the node is found, am I wrong?
Absolutely - a major weakness till it gets fixed. If someone puts something into IPFS on GO or JS and it doesn’t appear on any other place that trys to find it, then that takes away the whole point of a distributed file system in my opinion. (Unless one of the two nodes is intentionally in a private net)