# Ipfs-companion and ipfs-provider **URL:** \ **Category:** Help\ **Created:** [August 16, 2019, 10:23am UTC](https://discuss.ipfs.tech/t/ipfs-companion-and-ipfs-provider/6112 "2019-08-16T10:23:30Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![xmaysonnave](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/xmaysonnave/32/3304_2.png) [@xmaysonnave](https://discuss.ipfs.tech/u/xmaysonnave)\ **Post date:** [August 16, 2019, 10:23am UTC](https://discuss.ipfs.tech/t/ipfs-companion-and-ipfs-provider/6112/1 "2019-08-16T10:23:30Z")
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](https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/window.ipfs.md) do not describe any deadline or hints. Thanks ---
**Author:** ![lidel](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lidel/32/9853_2.png) [@lidel](https://discuss.ipfs.tech/u/lidel)\ **Post date:** [August 17, 2019, 10:26am UTC](https://discuss.ipfs.tech/t/ipfs-companion-and-ipfs-provider/6112/2 "2019-08-17T10:26:48Z")
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)](https://github.com/ipfs-shipyard/ipfs-companion/issues/589). Linked [document](https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/window.ipfs.md) 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](https://github.com/ipfs-shipyard/ipfs-provider/issues/1). 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. ---
**Author:** ![xmaysonnave](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/xmaysonnave/32/3304_2.png) [@xmaysonnave](https://discuss.ipfs.tech/u/xmaysonnave)\ **Post date:** [August 19, 2019, 3:40am UTC](https://discuss.ipfs.tech/t/ipfs-companion-and-ipfs-provider/6112/4 "2019-08-19T03:40:02Z")
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 ---
**Author:** ![lidel](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lidel/32/9853_2.png) [@lidel](https://discuss.ipfs.tech/u/lidel)\ **Post date:** [August 19, 2019, 12:39pm UTC](https://discuss.ipfs.tech/t/ipfs-companion-and-ipfs-provider/6112/5 "2019-08-19T12:39:35Z")
@xmaysonnave potential explanation: `window.ipfs` is exposed only on [Secure Contexts](https://developer.mozilla.org/en-US/docs/Web/Security/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. ---
**Author:** ![xmaysonnave](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/xmaysonnave/32/3304_2.png) [@xmaysonnave](https://discuss.ipfs.tech/u/xmaysonnave)\ **Post date:** [August 20, 2019, 3:40am UTC](https://discuss.ipfs.tech/t/ipfs-companion-and-ipfs-provider/6112/6 "2019-08-20T03:40:37Z")
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. ---
**Author:** ![xmaysonnave](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/xmaysonnave/32/3304_2.png) [@xmaysonnave](https://discuss.ipfs.tech/u/xmaysonnave)\ **Post date:** [August 23, 2019, 5:52am UTC](https://discuss.ipfs.tech/t/ipfs-companion-and-ipfs-provider/6112/7 "2019-08-23T05:52:30Z")
@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