8 ms·

IPFS Companion 2.2.0 brings window.ipfs to your Browser

93 points by lidel 8y ago

johnhenry 8y ago
I'd really love to see something like this show up as a proposal with the W3C (or the WHATWG -- I'm not entirely sure who's the authority on this?).
- Matheus28 8y ago
  It would be truly amazing to have ipfs built into browsers, it'd very quickly expand into other areas.
- diggan 8y ago
  Yes, this is definitely something we're planning to once we get closer to a v1 of all the parts. Today it's probably a bit too early but specifications are a core part of our general pipeline (but we can still get better) The goal is to end up with standardized implementations so we can have multiple implementations and a open protocol. (Disclaimer: I work on IPFS)
fogzen 8y ago
Dat+Beaker is way ahead of IPFS in tooling, developer mindshare, consumer friendly UI, etc. With $250 million it's pretty shocking they don't seem more worried/focused on that.
- sosuke 8y ago
  Interestingly I've heard of IPFS many many times and this is the first I've heard of Dat+Beaker. Do you have a starting point you suggest to get an idea of what it is or does?
  - citrusui 8y ago
    Here are the official websites of the Dat Project and Beaker Browser: https://datproject.org https://datproject.org https://beakerbrowser.com https://beakerbrowser.com And a short video for Beaker: https://www.youtube.com/watch?v=U2B9mwRFE8U https://www.youtube.com/watch?v=U2B9mwRFE8U
    - braderhart 8y ago
      So you have to install a custom web browser? Why don't they offer an extension as well? Also, IPFS is built in Go and pretty fast this way. From what I can see, most of Dat is built in JavaScript.
    - donttrack 8y ago
      I might have visited those sites before, but thought it was some kind of new token bullshit. Got a white paper link up at the top and some graphics of some decentralized nodes, so probably hit the back button faster than I delete spam from my inbox.
- StavrosK 8y ago
  Can dat be accessed without that browser? I haven't found something like the IPFS node, and that's what made me not want to run dat. Also, ZeroNet seems more advanced than both in terms of things that actually work today.
  - carussell 8y ago
    Hashbase exists, and in theory most Dat web apps could do a read-only version for legacy browsers, but since the tooling isn't there, you'd have to work out something by hand. The Dat ecosystem has pretty bad support for polyfills and bridging to the HTTP web right now. Many Dat demos I see today just fail hard over HTTP, maybe with a best-viewed-in message if the dev took some effort, but in principle it doesn't need to be that way.
  - stringer 8y ago
    Sure, here you go https://www.npmjs.com/package/dat https://www.npmjs.com/package/dat
- kodablah 8y ago
  How about adoption, e.g. Dat+Beaker vs IPFS+existing browser? Arguably, for these use cases, adoption matters more than all of the other items combined.
- gpdpocketer 8y ago
  Neither of these services are going to work to solve our current dilemna until we can drop a .framework in and use it from a mobile app.. this is really the space that needs adoption strategies.
- johnhenry 8y ago
  It's interesting to point out that in addition to Dat support, Beaker initially had support for IPFS as well, but dropped it. Currently Dat's browser integration model requires the use of a specific browser (Beaker). Not that Beaker isn't awesome; I think Dat would garner more mindshare if it moved to browser-extension-based model like IPFS and didn't require a full installation of a new browser.
  - zaarn 8y ago
    I think there is a plugin for firefox in development to enable the usage of dat:// urls. I recall seeing that in my mastodon feed.
- diggan 8y ago
  Dat and Beaker seems to be more focused on building products than us currently (I work on IPFS) so the more consumer friendly UIs does not surprise me. However, we're (Protocol Labs) are trying to build standardized protocols that can be shared across projects rather than just for us, hence it's currently more focused on lower-level technologies. With that said, we also have higher-level projects, most of them can be found over here: https://github.com/ipfs-shipyard/ https://github.com/ipfs-shipyard/ (Disclaimer: I work on IPFS)
  - alwillis 8y ago
    I've been playing with command line IPFS since the early days, but a menu bar IPFS app for my Mac? Now that's pretty damn sweet. Kudos!
amq 8y ago
How do I know that the embedded mode works? It says "IPFS resource loaded via Public Gateway".
- StavrosK 8y ago
  I think you can click "switch to local node" or something like that. At least that's what I did with my external gateway and it worked and started to redirect locally.
- lidel 8y ago
  Keep in mind that HTTP gateways are provided just for convenience. Due to WebExtension API limitations embedded node can't act as a local HTTP gateway and extension falls back to public gateway. I imagine it was what you were experiencing. Use window.ipfs property to play with pure IPFS (without HTTP gateway): window.ipfs.id(console.log) window.ipfs.add(Buffer.from('hello')).then(console.log) window.ipfs.cat('/ipfs/QmWfVY9y3xjsixTgbd9AorQxH7VtMpzfx2HaWtsoUYecaX').then((data) => console.log(new String(data))) More info: https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/window.ipfs.md https://github.com/ipfs-shipyard/ipfs-companion/blob/master/...
asymmetric 8y ago
Is it possible to completely/selectively prevent websites from knowing I have IPFS running in my browser? Or does this extensions have the same issues as Metamask[0], which means there's no way to hide the fact that one has the extension installed? This is a pretty important privacy feature, because I'm pretty sure the presence of such an extension massively increases the accuracy of targeting.
- kybernetikos 8y ago
  I agree, and looking at their site, they don't seem to have taken steps to avoid this problem. I wonder if we could have a standard api, like window.requestAPI('ipfs' or 'eth' or whatever) returns a Promise, and the user gets a 'page is requesting' bar like we do with location requests. That way, you wouldn't be leaking information about your browser capabilities to pages that you don't wish to use those capabilities on.
  - diggan 8y ago
    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 8y ago
      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.

93 points by lidel 8y ago

I'd really love to see something like this show up as a proposal with the W3C (or the WHATWG -- I'm not entirely sure who's the authority on this?).

Matheus28 8y ago
It would be truly amazing to have ipfs built into browsers, it'd very quickly expand into other areas.
diggan 8y ago
Yes, this is definitely something we're planning to once we get closer to a v1 of all the parts. Today it's probably a bit too early but specifications are a core part of our general pipeline (but we can still get better) The goal is to end up with standardized implementations so we can have multiple implementations and a open protocol. (Disclaimer: I work on IPFS)

fogzen 8y ago

Dat+Beaker is way ahead of IPFS in tooling, developer mindshare, consumer friendly UI, etc. With $250 million it's pretty shocking they don't seem more worried/focused on that.

sosuke 8y ago
Interestingly I've heard of IPFS many many times and this is the first I've heard of Dat+Beaker. Do you have a starting point you suggest to get an idea of what it is or does?
- citrusui 8y ago
  Here are the official websites of the Dat Project and Beaker Browser: https://datproject.org https://datproject.org https://beakerbrowser.com https://beakerbrowser.com And a short video for Beaker: https://www.youtube.com/watch?v=U2B9mwRFE8U https://www.youtube.com/watch?v=U2B9mwRFE8U
  - braderhart 8y ago
    So you have to install a custom web browser? Why don't they offer an extension as well? Also, IPFS is built in Go and pretty fast this way. From what I can see, most of Dat is built in JavaScript.
  - donttrack 8y ago
    I might have visited those sites before, but thought it was some kind of new token bullshit. Got a white paper link up at the top and some graphics of some decentralized nodes, so probably hit the back button faster than I delete spam from my inbox.
StavrosK 8y ago
Can dat be accessed without that browser? I haven't found something like the IPFS node, and that's what made me not want to run dat. Also, ZeroNet seems more advanced than both in terms of things that actually work today.
- carussell 8y ago
  Hashbase exists, and in theory most Dat web apps could do a read-only version for legacy browsers, but since the tooling isn't there, you'd have to work out something by hand. The Dat ecosystem has pretty bad support for polyfills and bridging to the HTTP web right now. Many Dat demos I see today just fail hard over HTTP, maybe with a best-viewed-in message if the dev took some effort, but in principle it doesn't need to be that way.
- stringer 8y ago
  Sure, here you go https://www.npmjs.com/package/dat https://www.npmjs.com/package/dat
kodablah 8y ago
How about adoption, e.g. Dat+Beaker vs IPFS+existing browser? Arguably, for these use cases, adoption matters more than all of the other items combined.
gpdpocketer 8y ago
Neither of these services are going to work to solve our current dilemna until we can drop a .framework in and use it from a mobile app.. this is really the space that needs adoption strategies.
johnhenry 8y ago
It's interesting to point out that in addition to Dat support, Beaker initially had support for IPFS as well, but dropped it. Currently Dat's browser integration model requires the use of a specific browser (Beaker). Not that Beaker isn't awesome; I think Dat would garner more mindshare if it moved to browser-extension-based model like IPFS and didn't require a full installation of a new browser.
- zaarn 8y ago
  I think there is a plugin for firefox in development to enable the usage of dat:// urls. I recall seeing that in my mastodon feed.
diggan 8y ago
Dat and Beaker seems to be more focused on building products than us currently (I work on IPFS) so the more consumer friendly UIs does not surprise me. However, we're (Protocol Labs) are trying to build standardized protocols that can be shared across projects rather than just for us, hence it's currently more focused on lower-level technologies. With that said, we also have higher-level projects, most of them can be found over here: https://github.com/ipfs-shipyard/ https://github.com/ipfs-shipyard/ (Disclaimer: I work on IPFS)
- alwillis 8y ago
  I've been playing with command line IPFS since the early days, but a menu bar IPFS app for my Mac? Now that's pretty damn sweet. Kudos!

amq 8y ago

How do I know that the embedded mode works? It says "IPFS resource loaded via Public Gateway".

StavrosK 8y ago
I think you can click "switch to local node" or something like that. At least that's what I did with my external gateway and it worked and started to redirect locally.
lidel 8y ago
Keep in mind that HTTP gateways are provided just for convenience. Due to WebExtension API limitations embedded node can't act as a local HTTP gateway and extension falls back to public gateway. I imagine it was what you were experiencing. Use window.ipfs property to play with pure IPFS (without HTTP gateway): window.ipfs.id(console.log) window.ipfs.add(Buffer.from('hello')).then(console.log) window.ipfs.cat('/ipfs/QmWfVY9y3xjsixTgbd9AorQxH7VtMpzfx2HaWtsoUYecaX').then((data) => console.log(new String(data))) More info: https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/window.ipfs.md https://github.com/ipfs-shipyard/ipfs-companion/blob/master/...

asymmetric 8y ago

Is it possible to completely/selectively prevent websites from knowing I have IPFS running in my browser? Or does this extensions have the same issues as Metamask[0], which means there's no way to hide the fact that one has the extension installed? This is a pretty important privacy feature, because I'm pretty sure the presence of such an extension massively increases the accuracy of targeting.

kybernetikos 8y ago
I agree, and looking at their site, they don't seem to have taken steps to avoid this problem. I wonder if we could have a standard api, like window.requestAPI('ipfs' or 'eth' or whatever) returns a Promise, and the user gets a 'page is requesting' bar like we do with location requests. That way, you wouldn't be leaking information about your browser capabilities to pages that you don't wish to use those capabilities on.
- diggan 8y ago
  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 8y ago
    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.