I am trying to make a website that will let visitors run some tests accessing content on the IPFS network vs content on the web.
At the moment I am using ipfs.io links to access IPFS resources from the browser. It is my understanding that If the visitor has the IPFS companion and server running on their computer, then ipfs.io links will be intercepted and resolved by the IPFS network. However, if the visitor doesn’t have these installed, then it will go to an IPFS HTTP gateway instead, which will give the wrong test results.
Is there a way to check whether or not the user has IPFS companion and a server running / or a way to check if requests are being served through the IPFS HTTP gateway as opposed to the IPFS network directly?
I think I found a way to check if the chrome or firefox extension is installed in the first place, but I don’t think that’s sufficient to know if the desktop server is also running correctly and using the IPFS network vs http gateways. Is that the best I can do?
Below is a link I found that I think should let me tell if the IPFS companion chrome extension is installed for example.
twilio com /blog/2018/03/detect-chrome-extension-installed.html
Basically, it tests if a local node / IPFS companion is available, and if not, it loads in js-IPFS and runs it in the browser without having to have the extension at all.
This definitely helps with part of it and we might run some speed tests with js-IPFS too now just out of curiosity and maybe let visitors of the site test js-IPFS too!
No problem! Let us know when you have a demo to share!
There is definitely an issue where I’d LIKE to just include ipfs:\\hash\image.jpg as the output in a system, and then this gets transformed into a full gateway path or used to load IPFS natively, but I haven’t dug in to how to do this.
I was trying it out and noticed that it uses a check for window.ipfs to see if the extension is there. I then noticed that my IPFS companion (the chrome version) has window.ipfs disabled by default (https://docs.ipfs.io/how-to/companion-window-ipfs/).
Because of this, I think the window.ipfs check will always fail even if the companion is installed in your browser. Right now, I am still looking into other ways of checking if a local node is running (hopefully automatically since I hope to not require users to turn on window.ipfs again for it to work if I can avoid it).
Actually, I just realized that the chrome extension doesn’t let the user elect to inject window.ipfs (even though it will probably be broken). So I think there isn’t a workaround that uses window.ipfs at the moment.
Hey @booksock I maintain get-ipfs. You’re right IPFS companion no longer injects window.ipfs (as of April). Altho it looks like they’re planning to readd the functionality in Q3 this year.
This seems to be because they haven’t upgraded the companion api to async/await which js-ipfs implemented in 0.41.
I don’t think there’s a way around this as the APIs are completely out of sync at the moment.
The good news: get-ipfs will still work in the meantime (falling back to an in-browser daemon) and will start using ipfs-companion again once the user upgrades to a version of IPFS Companion that supports window.ipfs
In terms of detecting ipfs-companion, my understanding is that the companion intercepts requests to IPFS resources and redirects them to your local daemon. You could probably make a GET request to a known IPFS resource, and check the response to see where the request was actually sent (was it sent to a server? or to your local ipfs node?).