New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPFS Integration - Roadmap and discussion #9556

Closed
diasdavid opened this Issue Jun 19, 2017 · 34 comments

Comments

Projects
None yet
@diasdavid

diasdavid commented Jun 19, 2017

Hi there brave team! I'm David, from the IPFS project.

I'm looking into the IPFS integration into the Brave browser and I'm hoping you could clarify some design details, just so that I'm sure I understand how everything is pieced together.

Right now, the most straightforward way is to mimic what WebTorrent did and create an extension. I've noticed that it gets its own WebPage, located at https://github.com/brave/browser-laptop/tree/master/js/webtorrent and that this page gets bundled in with WebPack -- https://github.com/brave/browser-laptop/blob/master/webpack.config.js#L153-L169 --. I can create something similar, no problem.

  • Where do I capture ipfs://, dweb:// and even http(s)://ipfs.io/ipfs/ urls so that they get resolved through the IPFS Extension?
  • How do I create a control panel like the one I see Dashlane/1Password
    image
  • Currently, we have full web applications that are hosted and served through IPFS. We can start by just adding IPFS support for download of files but ideally, we would like to see pages be rendered. Any advice on how to hint Brave the content type? Drop it into the dom like it's 🔥?

Thanks in advance! Super excited to do this :)

@jonathansampson

This comment has been minimized.

Show comment
Hide comment
@jonathansampson

jonathansampson Jun 19, 2017

Collaborator

Hello, @diasdavid!

The magnet protocol is defined as navigable in the https://github.com/brave/browser-laptop/blob/f3b80609976d90ef120bdcffbd7cd466e8ff4fc5/js/lib/appUrlUtil.js component. It is there that you can also defined/direct the behavior of ipfs, and dweb protocols.

If you run into any issues from here, or have questions about the appUrlUtil component, please do not hesitate to revisit this issue. I'm happy to help, or find somebody who can.

Collaborator

jonathansampson commented Jun 19, 2017

Hello, @diasdavid!

The magnet protocol is defined as navigable in the https://github.com/brave/browser-laptop/blob/f3b80609976d90ef120bdcffbd7cd466e8ff4fc5/js/lib/appUrlUtil.js component. It is there that you can also defined/direct the behavior of ipfs, and dweb protocols.

If you run into any issues from here, or have questions about the appUrlUtil component, please do not hesitate to revisit this issue. I'm happy to help, or find somebody who can.

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Jun 24, 2017

Back on track!

I'm trying to mimic WebTorrents approach but as I follow the execution flow, I realize things that weren't obvious to me, for example:

  • Seems that WebTorrent has an instance running on the Node.js process and uses IPC to contact with all the pages that get load a magnet URI. This makes sense because you don't want to open a WebTorrent instance for every document you load. Where should I put an IPFS instance, but that is running on the window process?
  • I got your message, @jonathansampson, but I'm not being able to identify where those checks for 'what type of url is it" are being done to make check the check for IPFS ones is made.

It would help me a ton if I could get some time with someone in the team to get a bunch of questions answered. Another option would be getting an example of how I can capture the ipfs:// being captured and loading a simple page.

diasdavid commented Jun 24, 2017

Back on track!

I'm trying to mimic WebTorrents approach but as I follow the execution flow, I realize things that weren't obvious to me, for example:

  • Seems that WebTorrent has an instance running on the Node.js process and uses IPC to contact with all the pages that get load a magnet URI. This makes sense because you don't want to open a WebTorrent instance for every document you load. Where should I put an IPFS instance, but that is running on the window process?
  • I got your message, @jonathansampson, but I'm not being able to identify where those checks for 'what type of url is it" are being done to make check the check for IPFS ones is made.

It would help me a ton if I could get some time with someone in the team to get a bunch of questions answered. Another option would be getting an example of how I can capture the ipfs:// being captured and loading a simple page.

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Jun 24, 2017

Btw, I'm working on this branch: https://github.com/diasdavid/browser-laptop/tree/feat/ipfs

diasdavid commented Jun 24, 2017

Btw, I'm working on this branch: https://github.com/diasdavid/browser-laptop/tree/feat/ipfs

@feross

This comment has been minimized.

Show comment
Hide comment
@feross

feross Jun 27, 2017

Collaborator

@diasdavid Just dropping in to say that you will probably find this PR useful: #5342 That is the initial PR that added WebTorrent support for magnet: links (but not for .torrent files).

Specifically, I think js/components/frame.js is the file you want to look at.

Also, listing all the commits for @feross and @dcposch will definitely include everything you need to capture a protocol and handle it with a custom page.

https://github.com/brave/browser-laptop/search?utf8=%E2%9C%93&q=author%3Afeross&type=Commits

https://github.com/brave/browser-laptop/search?q=author%3Adcposch&type=Commits&utf8=%E2%9C%93

Collaborator

feross commented Jun 27, 2017

@diasdavid Just dropping in to say that you will probably find this PR useful: #5342 That is the initial PR that added WebTorrent support for magnet: links (but not for .torrent files).

Specifically, I think js/components/frame.js is the file you want to look at.

Also, listing all the commits for @feross and @dcposch will definitely include everything you need to capture a protocol and handle it with a custom page.

https://github.com/brave/browser-laptop/search?utf8=%E2%9C%93&q=author%3Afeross&type=Commits

https://github.com/brave/browser-laptop/search?q=author%3Adcposch&type=Commits&utf8=%E2%9C%93

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Jun 27, 2017

@feross this is perfect! Thank you for this pointer.

as a note for whoever is following, js/components/frame.js is now app/renderer/components/frame/frame.js

diasdavid commented Jun 27, 2017

@feross this is perfect! Thank you for this pointer.

as a note for whoever is following, js/components/frame.js is now app/renderer/components/frame/frame.js

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Jun 30, 2017

Sharing an update on this thread.

Had a very productive chat with @bridiver and @NejcZdovc the other day, we realised that the best way to implement the integration was to have it fully as a chrome extension but with the ability to register protocol handlers from the background page of the extension. @bridiver had to patch muon to support this.

The development continues on: ipfs-shipyard#1

Next step: I'm not being able to load this extension properly, I haven't included any IPFS scripts at all, just the code to get an extension listed, but brave is just ignoring it. Any tips here?

diasdavid commented Jun 30, 2017

Sharing an update on this thread.

Had a very productive chat with @bridiver and @NejcZdovc the other day, we realised that the best way to implement the integration was to have it fully as a chrome extension but with the ability to register protocol handlers from the background page of the extension. @bridiver had to patch muon to support this.

The development continues on: ipfs-shipyard#1

Next step: I'm not being able to load this extension properly, I haven't included any IPFS scripts at all, just the code to get an extension listed, but brave is just ignoring it. Any tips here?

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Jun 30, 2017

image

Getting there \o/

diasdavid commented Jun 30, 2017

image

Getting there \o/

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Jul 6, 2017

Update: ipfs-shipyard#1 (comment)

I've successfully managed to install the extension and capture the ipfs:// protocol from an extension background page

image

Next steps:

diasdavid commented Jul 6, 2017

Update: ipfs-shipyard#1 (comment)

I've successfully managed to install the extension and capture the ipfs:// protocol from an extension background page

image

Next steps:

@luixxiul

This comment has been minimized.

Show comment
Hide comment
@luixxiul

luixxiul Aug 20, 2017

Contributor

@diasdavid Hi, everything looks good on your side? :-)

Contributor

luixxiul commented Aug 20, 2017

@diasdavid Hi, everything looks good on your side? :-)

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Aug 20, 2017

Hi @luixxiul, thanks for checking in!

I'm getting back on track on all my endeavours, I've been heads down in another project. That being said, this is going to be one of my priorities from now on.

I'll rebase the latest master on my PR ipfs-shipyard#1 (comment) and continue.

A couple of questions that would help me on this:

  • Could you check #9871? I was never successful loading tabby cat.
  • What is the state of migrating the code from the js folder into app? Last time I chatted with the team I learned that codebase structure and how things were being loaded was going to change, is that still part of the plan? Where can I can track it?

diasdavid commented Aug 20, 2017

Hi @luixxiul, thanks for checking in!

I'm getting back on track on all my endeavours, I've been heads down in another project. That being said, this is going to be one of my priorities from now on.

I'll rebase the latest master on my PR ipfs-shipyard#1 (comment) and continue.

A couple of questions that would help me on this:

  • Could you check #9871? I was never successful loading tabby cat.
  • What is the state of migrating the code from the js folder into app? Last time I chatted with the team I learned that codebase structure and how things were being loaded was going to change, is that still part of the plan? Where can I can track it?
@bsclifton

This comment has been minimized.

Show comment
Hide comment
@bsclifton

bsclifton Aug 21, 2017

Member

@diasdavid we're still in progress (moving js into app). A good chunk has been moved already 😄 For anything new, please add the files into the appropriate folder under app

Member

bsclifton commented Aug 21, 2017

@diasdavid we're still in progress (moving js into app). A good chunk has been moved already 😄 For anything new, please add the files into the appropriate folder under app

@NejcZdovc

This comment has been minimized.

Show comment
Hide comment
@NejcZdovc

NejcZdovc Aug 21, 2017

Member

@bsclifton should we create a tracking issue and put it in one milestone? I received this question quite a lot when I am talking about our project and how it's structured.

Member

NejcZdovc commented Aug 21, 2017

@bsclifton should we create a tracking issue and put it in one milestone? I received this question quite a lot when I am talking about our project and how it's structured.

@bsclifton

This comment has been minimized.

Show comment
Hide comment
@bsclifton

bsclifton Aug 21, 2017

Member

@NejcZdovc creating an issue to track that is a good idea 😄 It's important to have an issue document the strategy we'd like to have (it's less important to track the individual files)

Member

bsclifton commented Aug 21, 2017

@NejcZdovc creating an issue to track that is a good idea 😄 It's important to have an issue document the strategy we'd like to have (it's less important to track the individual files)

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Aug 28, 2017

In case you missed it, there was an update last week. tl;dr; We got it to work ipfs-shipyard#1 (comment) 🎉 (most of the issue was a CSP rule that was blocking the use of eval in a dep of dep of js-ipfs).

Next steps:

  • Improve the integration (refactor, make it read the hashes from the URL bar)
  • Create a proper background page to see IPFS stats (nodes connected, node id, size of the repo, etc)
  • Fix #10631
  • Support for response streams - #10629

Other:

diasdavid commented Aug 28, 2017

In case you missed it, there was an update last week. tl;dr; We got it to work ipfs-shipyard#1 (comment) 🎉 (most of the issue was a CSP rule that was blocking the use of eval in a dep of dep of js-ipfs).

Next steps:

  • Improve the integration (refactor, make it read the hashes from the URL bar)
  • Create a proper background page to see IPFS stats (nodes connected, node id, size of the repo, etc)
  • Fix #10631
  • Support for response streams - #10629

Other:

@olizilla

This comment has been minimized.

Show comment
Hide comment
@olizilla

olizilla Nov 17, 2017

I'm using @diasdavid's work to help make the existing ipfs chrome extension https://github.com/ipfs/ipfs-companion work well in Brave, see: ipfs-shipyard/ipfs-companion#312

It uses a handful of chrome extension apis that are not yet available, or at least, are throwing errors when called in brave. Who should I hug to get the

  • contextMenus.create
  • contextMenus.update
  • idle.queryState
  • runtime.openOptionsPage

...chrome extension apis available? Would you like me to open separate issues for them?

cc @luixxiul @bridiver

Also of note, the Brave shield classifies the webgl globe from ipfs webui as a Fingerprinting method and blocks it. The resource is from a url outside of the plugin; it's served by the ipfs daemon. Can the extension whitelist urls for the brave shield?

olizilla commented Nov 17, 2017

I'm using @diasdavid's work to help make the existing ipfs chrome extension https://github.com/ipfs/ipfs-companion work well in Brave, see: ipfs-shipyard/ipfs-companion#312

It uses a handful of chrome extension apis that are not yet available, or at least, are throwing errors when called in brave. Who should I hug to get the

  • contextMenus.create
  • contextMenus.update
  • idle.queryState
  • runtime.openOptionsPage

...chrome extension apis available? Would you like me to open separate issues for them?

cc @luixxiul @bridiver

Also of note, the Brave shield classifies the webgl globe from ipfs webui as a Fingerprinting method and blocks it. The resource is from a url outside of the plugin; it's served by the ipfs daemon. Can the extension whitelist urls for the brave shield?

@bsclifton

This comment has been minimized.

Show comment
Hide comment
@bsclifton

bsclifton Nov 17, 2017

Member

Hi there @olizilla 😄

The two devs with the most experience with extension APIs are @kevinlawler and @jonathansampson

cc: @diracdeltas for the fingerprinting question

Member

bsclifton commented Nov 17, 2017

Hi there @olizilla 😄

The two devs with the most experience with extension APIs are @kevinlawler and @jonathansampson

cc: @diracdeltas for the fingerprinting question

@jonathansampson

This comment has been minimized.

Show comment
Hide comment
@jonathansampson

jonathansampson Nov 17, 2017

Collaborator

@olizilla Here are the relevant issues for those APIs.

  • contextMenus.create #8331
  • contextMenus.update #8332
  • idle.queryState #12019
  • runtime.openOptionsPage #7812
Collaborator

jonathansampson commented Nov 17, 2017

@olizilla Here are the relevant issues for those APIs.

  • contextMenus.create #8331
  • contextMenus.update #8332
  • idle.queryState #12019
  • runtime.openOptionsPage #7812
@olizilla

This comment has been minimized.

Show comment
Hide comment
@olizilla

olizilla Nov 27, 2017

@diracdeltas could you point me to any info about what brave considerers a fingerprinting method so i can track down what's triggering it in the ipfs webui?

I'm seeing:

WebGL: http://127.0.0.1:5001/ipfs/QmPhnvn747LqwPYMJmQVorMaGbMSgA7mRRoyyZYz3DoZRQ/#/connections

...blocked and listed as a fingerprinting method. It loads a webgl globe and shows the approximate location of where your swarm peers are located.

olizilla commented Nov 27, 2017

@diracdeltas could you point me to any info about what brave considerers a fingerprinting method so i can track down what's triggering it in the ipfs webui?

I'm seeing:

WebGL: http://127.0.0.1:5001/ipfs/QmPhnvn747LqwPYMJmQVorMaGbMSgA7mRRoyyZYz3DoZRQ/#/connections

...blocked and listed as a fingerprinting method. It loads a webgl globe and shows the approximate location of where your swarm peers are located.

@bsclifton bsclifton added this to the Triage Backlog milestone Nov 27, 2017

@diracdeltas

This comment has been minimized.

Show comment
Hide comment
@diracdeltas

diracdeltas Nov 28, 2017

Member

@olizilla see app/extensions/brave/content/scripts/blockCanvasFingerprinting.js

the heuristic has a high false positive rate, so if you need webgl and are not actually fingerprinting, you can probably get away with hardcoding an exception for your origin

Member

diracdeltas commented Nov 28, 2017

@olizilla see app/extensions/brave/content/scripts/blockCanvasFingerprinting.js

the heuristic has a high false positive rate, so if you need webgl and are not actually fingerprinting, you can probably get away with hardcoding an exception for your origin

@diasdavid diasdavid changed the title from IPFS Integration to IPFS Integration - Roadmap and discussion Dec 18, 2017

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Dec 18, 2017

Ohai everyone o/

Good news! Things have been progressing quite well and we now have a working version of the IPFS Web Extension running on the Brave Browser with extra features thanks to how the Brave Browser was built.

If you are a user of the IPFS Web Extension on Chrome or Firefox, you now can get all of those features + IPFS protocol handler ipfs:// in Brave just by installing the same extension.

Enough with the talking, let's see a demo!

@olizilla @alanshaw and @olizilla have been working hard at this and prepared a video demo for us!

image-for-link

Youtube URL: https://www.youtube.com/watch?v=2cmbm6iABsI

Also, if you haven't checked the IPFS Web Extension update from the last IPFS All Hands:

.

Youtube URL: https://www.youtube.com/watch?v=xCMNgBzn5WI&feature=youtu.be&t=18m14s

What's next? Establishing the Roadmap to complete the integration.

The first milestone was to get IPFS running on Brave 🚀. Now, we want to improve the integration and focus on what should be the User Experience.

These are just the things we see in the horizon, however, I do think it would be best to get the IPFS and the Brave team in a call to sync up on next steps and identify priorities.

@jonathansampson @bsclifton @NejcZdovc @bridiver et al, when is a good time to chat? Shall I set up a doodle for this week? Thanks!

diasdavid commented Dec 18, 2017

Ohai everyone o/

Good news! Things have been progressing quite well and we now have a working version of the IPFS Web Extension running on the Brave Browser with extra features thanks to how the Brave Browser was built.

If you are a user of the IPFS Web Extension on Chrome or Firefox, you now can get all of those features + IPFS protocol handler ipfs:// in Brave just by installing the same extension.

Enough with the talking, let's see a demo!

@olizilla @alanshaw and @olizilla have been working hard at this and prepared a video demo for us!

image-for-link

Youtube URL: https://www.youtube.com/watch?v=2cmbm6iABsI

Also, if you haven't checked the IPFS Web Extension update from the last IPFS All Hands:

.

Youtube URL: https://www.youtube.com/watch?v=xCMNgBzn5WI&feature=youtu.be&t=18m14s

What's next? Establishing the Roadmap to complete the integration.

The first milestone was to get IPFS running on Brave 🚀. Now, we want to improve the integration and focus on what should be the User Experience.

These are just the things we see in the horizon, however, I do think it would be best to get the IPFS and the Brave team in a call to sync up on next steps and identify priorities.

@jonathansampson @bsclifton @NejcZdovc @bridiver et al, when is a good time to chat? Shall I set up a doodle for this week? Thanks!

@MirceaKitsune

This comment has been minimized.

Show comment
Hide comment
@MirceaKitsune

MirceaKitsune Dec 19, 2017

This is such wonderful news! I've been looking for a web browser that can fully support IPFS out of the box or at least using a single addon. This sounds like it might be it for now.

Any thoughts on supporting IPFS in Brave out-of-the-box? I've been hoping Firefox and Chromium can be convinced to do that, but until that happens Brave seems like an accepting candidate.

MirceaKitsune commented Dec 19, 2017

This is such wonderful news! I've been looking for a web browser that can fully support IPFS out of the box or at least using a single addon. This sounds like it might be it for now.

Any thoughts on supporting IPFS in Brave out-of-the-box? I've been hoping Firefox and Chromium can be convinced to do that, but until that happens Brave seems like an accepting candidate.

@retotrinkler

This comment has been minimized.

Show comment
Hide comment
@retotrinkler

retotrinkler Jan 11, 2018

Excited to see this!
Would it be possible to have isolated storage in brave per an ipfs hash/ipns name? This would be very useful for crypto keystorage of decentralised applications. Most non-ipfs application use storage isolated per domain but its is not possible for ipfs links!

retotrinkler commented Jan 11, 2018

Excited to see this!
Would it be possible to have isolated storage in brave per an ipfs hash/ipns name? This would be very useful for crypto keystorage of decentralised applications. Most non-ipfs application use storage isolated per domain but its is not possible for ipfs links!

@RangerMauve

This comment has been minimized.

Show comment
Hide comment
@RangerMauve

RangerMauve Jan 11, 2018

@retotrinkler Take a look at the access restriction conversation taking place for the window.ipfs global that ipfs-companion provides.
The short of it is that it will have access restrictions based on hash/name like you suggested.

I brought up that once it integrates with the new key API, it would make sense to have the access restrictions prompt the user for giving a page access to keys. This will enable applications to share keys when possible while keeping them isolated from each other by default.

Web APIs like localStorage still need browser changes in order to isolate it between IPFS pages, however.

RangerMauve commented Jan 11, 2018

@retotrinkler Take a look at the access restriction conversation taking place for the window.ipfs global that ipfs-companion provides.
The short of it is that it will have access restrictions based on hash/name like you suggested.

I brought up that once it integrates with the new key API, it would make sense to have the access restrictions prompt the user for giving a page access to keys. This will enable applications to share keys when possible while keeping them isolated from each other by default.

Web APIs like localStorage still need browser changes in order to isolate it between IPFS pages, however.

@retotrinkler

This comment has been minimized.

Show comment
Hide comment
@retotrinkler

retotrinkler commented Jan 11, 2018

nice thx @RangerMauve !

@diasdavid

This comment has been minimized.

Show comment
Hide comment
@diasdavid

diasdavid Mar 1, 2018

Saw today this exciting update from @alanshaw and @olizilla -- https://twitter.com/_alanshaw/status/969253866016591872 --

.@olizilla and I are building `chrome.protocol.registerStreamProtocol` in @brave and it actually now streams files **directly** from our #IPFS node via the #ipfsCompanion web extension. THIS IS A BIG EXCITEMENT FOR ME :D pic.twitter.com/bmodev2RfX

— Alan Shaw (@_alanshaw) March 1, 2018

image

diasdavid commented Mar 1, 2018

Saw today this exciting update from @alanshaw and @olizilla -- https://twitter.com/_alanshaw/status/969253866016591872 --

.@olizilla and I are building `chrome.protocol.registerStreamProtocol` in @brave and it actually now streams files **directly** from our #IPFS node via the #ipfsCompanion web extension. THIS IS A BIG EXCITEMENT FOR ME :D pic.twitter.com/bmodev2RfX

— Alan Shaw (@_alanshaw) March 1, 2018

image

@olizilla

This comment has been minimized.

Show comment
Hide comment
@olizilla

olizilla Mar 7, 2018

The changeset to port chrome.protocol.registerStreamProtocol from electron is over here brave/muon#507. Landing that PR will allow a WebExtension to register a custom protocol handler for ipfs:// that can return Content-Type headers and stream the response to the Brave, which'll both remove the blocker around non-text responses (images / webfonts / videos) and better support large files, streamed directly from an ipfs node.

It's of value to other protocol implementors too. @pfrazee of Beaker Browser has expressed an interest in getting that api ported to muon to open up the possibility of creating a dat protocol handler for Brave.

olizilla commented Mar 7, 2018

The changeset to port chrome.protocol.registerStreamProtocol from electron is over here brave/muon#507. Landing that PR will allow a WebExtension to register a custom protocol handler for ipfs:// that can return Content-Type headers and stream the response to the Brave, which'll both remove the blocker around non-text responses (images / webfonts / videos) and better support large files, streamed directly from an ipfs node.

It's of value to other protocol implementors too. @pfrazee of Beaker Browser has expressed an interest in getting that api ported to muon to open up the possibility of creating a dat protocol handler for Brave.

@olizilla

This comment has been minimized.

Show comment
Hide comment
@olizilla

olizilla Mar 28, 2018

Brave is moving from Muon to Chromium!
https://brave.com/development-plans-for-upcoming-release/

This is going to impact on IPFS integration. It should mean that ipfs-companion will work without significant modification on nu-brave, but it also means that our work to allow Brave to have the best IPFS integration possible, via registerStreamProtocol will get derailed, which is a shame as the PR works today.

Longer term, we'll have to work with Chromium to get support for programmable custom protocol handlers for that to work.

olizilla commented Mar 28, 2018

Brave is moving from Muon to Chromium!
https://brave.com/development-plans-for-upcoming-release/

This is going to impact on IPFS integration. It should mean that ipfs-companion will work without significant modification on nu-brave, but it also means that our work to allow Brave to have the best IPFS integration possible, via registerStreamProtocol will get derailed, which is a shame as the PR works today.

Longer term, we'll have to work with Chromium to get support for programmable custom protocol handlers for that to work.

@mathiasrw

This comment has been minimized.

Show comment
Hide comment
@mathiasrw

mathiasrw Jul 12, 2018

Sad to hear lots of good work regarding IPFS will have to be redone with the change to chromium.

Does the change mean that the code for normal chrome plugins can be used? If so https://github.com/ipfs-shipyard/ipfs-companion can be used as a good starting point for implementing IPFS support in the next Brave version.

I imagine a copy of the code for the plugin could be included when installing Brave - and then gradually being expanded until its integrated in a seamless way.

mathiasrw commented Jul 12, 2018

Sad to hear lots of good work regarding IPFS will have to be redone with the change to chromium.

Does the change mean that the code for normal chrome plugins can be used? If so https://github.com/ipfs-shipyard/ipfs-companion can be used as a good starting point for implementing IPFS support in the next Brave version.

I imagine a copy of the code for the plugin could be included when installing Brave - and then gradually being expanded until its integrated in a seamless way.

@mathiasrw

This comment has been minimized.

Show comment
Hide comment
@mathiasrw

mathiasrw Jul 12, 2018

I guess one way of implementing the ipfs:// scheme in a non-invasive way would be to use the registerProtocolHandler(...) method in a pre-installed/always-installed plugin.

window . navigator . registerProtocolHandler(scheme, url, title)
Registers a handler for the given scheme, at the given URL, with the given title.

The string "%s" in the URL is used as a placeholder for where to put the URL of the content to be handled.

Throws a "SecurityError" DOMException if the user agent blocks the registration (this might happen if trying to register as a handler for "http", for instance).

Throws a "SyntaxError" DOMException if the "%s" string is missing in the URL.

In the chromium email list it looks like the implementation follows the list of whitelisted schemes defined by the WHATWG specification.

I have contacted WHATWG by email suggesting that "ipfs" is added to safelisted schemes, after which browsers like chrome can adopt the change, letting the ipfs:// scheme be managed via registerProtocolHandler.

mathiasrw commented Jul 12, 2018

I guess one way of implementing the ipfs:// scheme in a non-invasive way would be to use the registerProtocolHandler(...) method in a pre-installed/always-installed plugin.

window . navigator . registerProtocolHandler(scheme, url, title)
Registers a handler for the given scheme, at the given URL, with the given title.

The string "%s" in the URL is used as a placeholder for where to put the URL of the content to be handled.

Throws a "SecurityError" DOMException if the user agent blocks the registration (this might happen if trying to register as a handler for "http", for instance).

Throws a "SyntaxError" DOMException if the "%s" string is missing in the URL.

In the chromium email list it looks like the implementation follows the list of whitelisted schemes defined by the WHATWG specification.

I have contacted WHATWG by email suggesting that "ipfs" is added to safelisted schemes, after which browsers like chrome can adopt the change, letting the ipfs:// scheme be managed via registerProtocolHandler.

@mathiasrw

This comment has been minimized.

Show comment
Hide comment
@mathiasrw

mathiasrw Jul 12, 2018

Looks like WHATWG does not accept additions to the list unless one or more of the major browsers intend to implement it. We might be able to convince chromium that its a good idea.

In the meantime: if Brave is building chromium from source ipfs could be added to the list in https://github.com/chromium/chromium/blob/c803b8978405c0dd15d46a9f047ff4e4bd318d0a/third_party/blink/renderer/modules/navigatorcontentutils/navigator_content_utils.cc#L41

This would demand some governance on how this is re-added when upgrading to a new version of chromium.


Update: This would need to be implemented in the build flow of https://github.com/brave/brave-browser

mathiasrw commented Jul 12, 2018

Looks like WHATWG does not accept additions to the list unless one or more of the major browsers intend to implement it. We might be able to convince chromium that its a good idea.

In the meantime: if Brave is building chromium from source ipfs could be added to the list in https://github.com/chromium/chromium/blob/c803b8978405c0dd15d46a9f047ff4e4bd318d0a/third_party/blink/renderer/modules/navigatorcontentutils/navigator_content_utils.cc#L41

This would demand some governance on how this is re-added when upgrading to a new version of chromium.


Update: This would need to be implemented in the build flow of https://github.com/brave/brave-browser

@lidel

This comment has been minimized.

Show comment
Hide comment
@lidel

lidel Jul 14, 2018

@mathiasrw FYSA Firefox whitelisted ipfs://, ipns://, ssb://, dat:// and dweb: some time ago (Firefox 59):

Does it count as "one major browser implementing it" ?

navigator.registerProtocolHandler is only a redirect (not a real handler), but it is better than nothing :)

Should I create a separate issue for whitelisting non-prefixed versions of mentioned protocols?

Does the change mean that the code for normal chrome plugins can be used?

Yes, ipfs-companion built for the generic target should work the same in Chromium and Chromium-based Brave.
Basic redirect to local gateway will work, but the regression is that we no longer have ipfs:// in location bar.

lidel commented Jul 14, 2018

@mathiasrw FYSA Firefox whitelisted ipfs://, ipns://, ssb://, dat:// and dweb: some time ago (Firefox 59):

Does it count as "one major browser implementing it" ?

navigator.registerProtocolHandler is only a redirect (not a real handler), but it is better than nothing :)

Should I create a separate issue for whitelisting non-prefixed versions of mentioned protocols?

Does the change mean that the code for normal chrome plugins can be used?

Yes, ipfs-companion built for the generic target should work the same in Chromium and Chromium-based Brave.
Basic redirect to local gateway will work, but the regression is that we no longer have ipfs:// in location bar.

@mathiasrw

This comment has been minimized.

Show comment
Hide comment
@mathiasrw

mathiasrw Jul 14, 2018

Hi @lidel - thank you for providing useful insights.

navigator.registerProtocolHandler is only a redirect (not a real handler), but it is better than nothing :)

I maybe misunderstood this. My impression was that myScheme://abc would be shown in the address bar while the content would be fetched from the http(s) url given (for example https://whatever.com/?myScheme=abc). In any case, I agree; this is not a final solution, but a (small) step.

I was not aware that Firefox has whitelisted "ipfs" already. Very useful information. Thank you for taking the time to find the actual patches. I have written a new email to the WHATWG mail list with the information. The thread can be seen here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2018Jul/0000.html (my last email does not show yet)

mathiasrw commented Jul 14, 2018

Hi @lidel - thank you for providing useful insights.

navigator.registerProtocolHandler is only a redirect (not a real handler), but it is better than nothing :)

I maybe misunderstood this. My impression was that myScheme://abc would be shown in the address bar while the content would be fetched from the http(s) url given (for example https://whatever.com/?myScheme=abc). In any case, I agree; this is not a final solution, but a (small) step.

I was not aware that Firefox has whitelisted "ipfs" already. Very useful information. Thank you for taking the time to find the actual patches. I have written a new email to the WHATWG mail list with the information. The thread can be seen here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2018Jul/0000.html (my last email does not show yet)

@lidel lidel referenced this issue Aug 17, 2018

Open

Whitelisting DWeb Protocols #23

2 of 6 tasks complete
@lidel

This comment has been minimized.

Show comment
Hide comment
@lidel

lidel Aug 17, 2018

FYSA I am revisiting redirect-based navigator.registerProtocolHandler as a part of arewedistributedyet/arewedistributedyet#23:

  • Opened issue for changing WHATWG HTML Spec at whatwg/html#3935
    • There is a lot of red tape, so we want to safelist key DWeb protocols together:
      "ssb", "dat", "ipfs", "ipns" and "dweb"
  • After DWeb Summit Chromium team seems to be supportive to the idea, so we will try to introduce change upstream
    • Update: Chromium confirmed support for HTML Spec change and we got first positive review on PR 👍

lidel commented Aug 17, 2018

FYSA I am revisiting redirect-based navigator.registerProtocolHandler as a part of arewedistributedyet/arewedistributedyet#23:

  • Opened issue for changing WHATWG HTML Spec at whatwg/html#3935
    • There is a lot of red tape, so we want to safelist key DWeb protocols together:
      "ssb", "dat", "ipfs", "ipns" and "dweb"
  • After DWeb Summit Chromium team seems to be supportive to the idea, so we will try to introduce change upstream
    • Update: Chromium confirmed support for HTML Spec change and we got first positive review on PR 👍
@bsclifton

This comment has been minimized.

Show comment
Hide comment
@bsclifton

bsclifton Aug 23, 2018

Member

Hey there folks- I opened an issue to keep this discussion going in our new brave-core repository:
brave/brave-browser#819

Let's migrate the discussions over to there 😄 Apologies for the disruption

Member

bsclifton commented Aug 23, 2018

Hey there folks- I opened an issue to keep this discussion going in our new brave-core repository:
brave/brave-browser#819

Let's migrate the discussions over to there 😄 Apologies for the disruption

@bsclifton bsclifton closed this Aug 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment