Browser-laptop: IPFS Integration - Roadmap and discussion

[daviddias]

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
  
• 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]

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.

[daviddias]

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.

[daviddias]

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

• [x] I've added the extension placeholder to https://github.com/diasdavid/browser-laptop/commit/7d905387d506320af4c1ec5e83d94ccaee0e8ca7
• [x] Added the funcs to translate between source and target IPFS Paths https://github.com/diasdavid/browser-laptop/commit/9ef1d5a79331388a2afc15417f7bedc61a401e12
• [ ] Now I just want to be able to capture the dweb: and ipfs:// to print this https://github.com/diasdavid/browser-laptop/commit/869dff92a9540275e53f6816dbd2b69275dd214c

[feross]

@diasdavid Just dropping in to say that you will probably find this PR useful: https://github.com/brave/browser-laptop/pull/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

[daviddias]

@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

[daviddias]

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: https://github.com/diasdavid/browser-laptop/pull/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?

[daviddias]

Getting there \o/

[daviddias]

Update: https://github.com/diasdavid/browser-laptop/pull/1#issuecomment-313306408

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

Next steps:

• [ ] validate IPFS path
• [ ] [instantiate successfully an IPFS node from this context](https://github.com/diasdavid/browser-laptop/pull/1#discussion_r125822933)

[luixxiul]

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

[daviddias]

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 https://github.com/diasdavid/browser-laptop/pull/1#issuecomment-313306408 and continue.

A couple of questions that would help me on this:

• Could you check https://github.com/brave/browser-laptop/issues/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]

@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]

@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]

@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)

[daviddias]

In case you missed it, there was an update last week. tl;dr; We got it to work https://github.com/diasdavid/browser-laptop/pull/1#issuecomment-324087667 🎉 (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:

• [x] Improve the integration (refactor, make it read the hashes from the URL bar)
• [x] Create a proper background page to see IPFS stats (nodes connected, node id, size of the repo, etc)
• [ ] Fix https://github.com/brave/browser-laptop/issues/10631
• [ ] Support for response streams - https://github.com/brave/browser-laptop/issues/10629

Other:

• [ ] https://github.com/brave/browser-laptop/issues/10630

[olizilla]

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: https://github.com/ipfs/ipfs-companion/issues/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]

Hi there @olizilla 😄

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

cc: @diracdeltas for the fingerprinting question

[jonathansampson]

@olizilla Here are the relevant issues for those APIs.

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

[olizilla]

@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.

[diracdeltas]

@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

[daviddias]

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!

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.

• [ ] Expose a comple IPFS Dashboard (Possibly the WebUI https://github.com/ipfs/webui)
• [ ] Support loading large files with .registerStreamProtocol - https://github.com/brave/browser-laptop/issues/10629
• [ ] Support for images and other types of data that have specific mime types through adding .registerBufferProtocol support to muon - https://github.com/electron/electron/blob/master/docs/api/protocol.md#protocolregisterbufferprotocolscheme-handler-completion
• [ ] Document how users can get IPFS integrated into their Brave Browser - https://github.com/ipfs/ipfs-companion/issues/340
• [ ] Ship Brave with IPFS
• Moar at https://github.com/ipfs/ipfs-companion/issues/312

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 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]

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]

@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]

nice thx @RangerMauve !

[daviddias]

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

[olizilla]

The changeset to port chrome.protocol.registerStreamProtocol from electron is over here https://github.com/brave/muon/pull/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]

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]

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]

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]

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]

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

• https://bugzilla.mozilla.org/show_bug.cgi?id=1428446
• https://blog.mozilla.org/addons/2018/01/26/extensions-firefox-59/
• https://hg.mozilla.org/mozilla-central/rev/c2cb8a06bcf1

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]

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]

FYSA I am revisiting redirect-based navigator.registerProtocolHandler as a part of https://github.com/arewedistributedyet/arewedistributedyet/issues/23:

• Opened issue for changing WHATWG HTML Spec at https://github.com/whatwg/html/issues/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 :+1:
  
  

[bsclifton]

Hey there folks- I opened an issue to keep this discussion going in our new brave-core repository:
https://github.com/brave/brave-browser/issues/819

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