[diggan]

The reason why window.ipfs is so great is that it opens up for a very easy migration path for when IPFS is embedded directly in the browsers.

So as a application developer, you would check if window.ipfs exists on the page, and if it doesn't, load js-ipfs and then the rest of the page can function the same way, no matter how ipfs was loaded on the page.

Unless we can be sure that when browsers implement IPFS, window.requestAPI('ipfs') would be the API, going the route we're taking now is the safest bet, unfortunately.

(Disclaimer: I work on IPFS)

[kybernetikos]

It's a pity that people aren't more concerned about the problems of leaking information to potentially hostile websites and polluting the window object with their project specific objects.

As the earlier poster mentioned, Metamask had this exact problem and it's been widely commented on. Of course the metamask problem is worse than the IPFS problem, as it marks a user as a potential target, whereas IPFS by itself probably doesn't do more than mark them as someone interested in the distributed web.

Your argument for why you do it seems to be a non-sequitur. Whatever you choose for how IPFS Companion exposes the api can be exactly the same as how the future browser exposes it. In fact as an early mover, you have an opportunity to do something positive and set a good direction for the built in functionality that comes later.

It's not a problem that there is consensus on how to solve yet, but I believe a standard solution built into browsers for exposing apis with capabilities we may not wish some sites to observe is needed. Polluting the window object with a host of api objects is likely to be a bad idea long term.