I have two JS-IPFS nodes running:
Node 1 - In the browser
Node 2 - Running on CLI
Node 1 and 2 are not directly connected.
In Node 1, I add a file to IPFS and get hash (H1).
In Node 2, I try jsipfs cat H1. The call hangs and doesnât return.
After waiting a long time and the call not returning I visit https://ipfs.io/ipfs/H1. The IPFS gateway CAN retrieve the file and displays it in the browser.
Furthermore, my call to jsipfs cat H1 immediately returns the file.
Why can Node 2 not see the file until I have retrieved the file via the ipfs.io gateway?
(Also note, this issue is still present even if Node 2 is a Go-IPFS node)
So why therefore can Node 1 not see Node 2 via the IPFS.io gateway? My understanding is that Node 1 and Node 2 donât need to be direct peers. As they are both part of the network as a whole they should be able to connect each other indirectly. Please correct me if my assumptions are wrong!
This is planned, itâs called connection relaying, but the spec is not finalized.
Right now IPFS needs a direct connection to work, so there are a bunch of issues with NATs and transport-incompatible peer implementations.
Hello all! I think, my question related to this topic so i`ll ask here.
I`m developing simple client-server architecture that uploads files from client to IPFS through server using js-ipfs api.
After uploading to local repo and pinning file, i`m trying to get access to this files through gateways but each of them hangs and thats all.
Can you clarify for me how gateway searches for files that was uploaded to another node?
And, also, clarify, please, do I need to do pinning to get access to file, or just uploading will provide access to file via Internet?
And, if I need to directly ask for file node that uploaded it - it means that this node should be with port forwarded from router so someone outside can get access?