Dear Friends,
Not sure if I’m at the right place. Feel free to provide me some guidance if necessary.
Right now I’m prototyping a browser app who reach IPFS with ipfs-companion and ipfs-provider.
My env has a local nginx proxy to a local go ipfs daemon.
While debugging I noticed this message :
commands directly on window.ipfs is deprecated and will be removed on 2019-09-01. Use API instance returned by window.ipfs.enable() instead.
We are quite close from this deadline. I don’t know right now if this message comes from ipfs-companion or ipfs-provider.
The provided link https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/window.ipfs.md do not describe any deadline or hints.
Thanks
1 Like
Hi, good catch!
The context is: window.ipfs is an ipfs-companion experiment, and we are in the process of switching it the async version (v2). Linked document already describes the new interface, however the old API is still available.
The message informing about deprecation comes from ipfs-companion and is caused by ipfs-provider’s lack of support for the new interface. ipfs-provider is still using the old one, triggering the deprecation warning.
Deprecation warning will go away when ipfs-provider switches to v2. Worry not, we won’t remove the old interface until ipfs-provider adds support for window.ipfs.enable(). As this API is a low priority experiment, we will probably update deprecation warning and push the deadline to the end of 2019.
Hi,
1 - Thanks for your detailed answers who confirmed what I thought.
I’ll definitely follow what happened to that package.
2 - I’ve been troubled with the following behavior
I started to load a local browserifyied html file and noticed that the window.ipfs property was not available on that page. It became available once I put this file behind my local nginx and served through http. Is there something I’m missing here ?
Thanks
@xmaysonnave potential explanation: window.ipfs is exposed only on Secure Contexts. It means you need HTTPS (HTTP with TLS encryption) in production. For local development you can use 127.0.0.1 (localhost IP), which does not require encryption, but is interpreted as a secure context by browser vendors.
Thanks for the Mozilla link. Not very familiar with this. I’m using Chromium and got the windows.ipfs property behind http. However it makes sense to provide secure context.
@lidel
In Chromium in the ipfs-companion extension properties there is an option who is deactivated called Allow access to file URLs. Once activated the window.ipfs property is available.
However in incognito mode this property is not available. Most of the extensions I use have the feature called Allow in incognito. I’m gonna open a feature request.
Thanks