IPFS Integration - Roadmap and discussion

Carried over from https://github.com/brave/browser-laptop/issues/9556

@diasdavid wrote:

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 😃

[lidel]

Notes on bringing IPFS to Brave in 2019

I had a chat with @bbondy about ways we can deliver better IPFS experience in Brave, given where both projects are right now.

Below is a short (well, I tried…) summary of takeaways and low hanging fruits we were able to identify to speed up IPFS integration.

Today: IPFS works in Brave, but UX could be much better

IPFS Companion extension can be installed in Brave from Chrome Store, with some caveats:

• to use real IPFS transport it requires external daemon to be installed on localhost as well (current options: go-ipfs or ipfs-desktop).
• (Problem 1) even if user has a local daemon installed and running, IPFS URLs in location bar will start with http://127.0.0.1:8080/ipfs/ instead of ipfs:// and origin-based security perimeter will be shared by all IPFS websites.

Future: how it could work

We want to ship native IPFS support with Brave in 2019. What we mean by that in UX terms is:

MVP:

• Brave ships with IPFS detection and gives user an option to enable support for it
  • Detects the first time user tries to access IPFS resource and asks if support for IPFS should be installed (in form of IPFS Companion)
  • Explicit opt-in via an informative screen – flow similar to Widevine (screenshot), but more friendly and educational
  • After IPFS install embedded IPFS node is started and the initially requested URL is loaded over IPFS
  • User can turn IPFS node on/off at any time via UI of IPFS Companion extension (screenshot)

Ideal:

• keep ipfs:// in location bar (native protocol handler)
• local discovery and p2p transport (to see and talk to other IPFS nodes in LAN without centralized signaling server)

How to get there?

In 2019 there are two ways to do enable it, each comes with own set of challenges:

(A) Bundling go-ipfs binary with Brave and talking to it via ipfs-companion

• requires additional orchestration to start/stop/upgrade go-ipfs daemon binary
• ipfs-companion talks to daemon over HTTP API exposed on localhost TCP port
• go-ipfs node talks to IPFS swarm over TCP/QUIC transports
• separate process, huge surface, harder to audit
• (Problem 1) keeping ipfs:// scheme in location bar would solve Origin-based security, but requires (currently missing) protocol handler API in WebExtension context

(B) Embedded js-ipfs running in ipfs-companion (WebExtension context)

• (JS implementation matured a lot, our browser extension is able to use it as a drop-in replacement for go-ipfs)
• no binary, pure JS implementation
• managing in-memory node via programmatic JS API
• easier to audit, reusing most of WebExtension sandbox
• regular JS cant open raw TCP sockets, so js-ipfs node talks to the swarm over websockets (or webrtc)
  • Brave enables huge improvement here: ipfs-companion can be marked as blessed_extension and gain access to raw socket APIs, which would enable local discovery and p2p transports (see relevant PoC for Firefox: libdweb discovery and transport)
• (Problem 1) keeping ipfs:// scheme in location bar would solve Origin-based security, but requires (currently missing) protocol handler API in WebExtension context
• (Problem 2) Important caveat: js-ipfs running in browser context is unable to open TCP port to provide HTTP Gateway, nor can ipfs-companion inject responses via webRequest API. How do we return payload (regular websites) then?
  • (Fix 1 - the best): If we have ipfs:// and proper protocol handler API, then this is not an issue, as payload can be injected inside of the handler. We already confirmed this approach works in libdweb experiment: protocol handler API.
  • (Fix 2 - second best): if ipfs-companion is blessed_extension in Brave, then access to sockets.tcpServer, enables us to expose js-ipfs HTTP Gateway over a regular TCP port. Not as good as (Fix 1), but as good as Gateway exposed by (go-ipfs) and does not require changes to Brave.
  • (Fix 3 - backup option): it might be possible to pass payload into Service Worker-based Access Point exposed at our public gateway (relevant approach currently researched by @Gozala in lunet experiment, and we want to make HTTP-Gateway-as-a-function in https://github.com/ipfs/js-ipfs/issues/1820 to make it even easier).

Which one is more feasible?

While (A) was the way we planned to integrate in 2018, (B) is self-contained (execution context is limited to ipfs-companion extension), which may be easier to manage, audit and ship today, as IPFS project has a lot of relevant plumbing in place in js-ipfs and ipfs-companion thanks to mozilla/libdweb and other work that happened in recent months.

Shipping Brave-powered js-ipfs node in ipfs-companion being blessed_extension (B) may simply take less work.

Sidenote: both (A) and (B) can benefit from native Protocol Handler API:

• the use case for IPFS handler is demonstrated in libdweb experiment: protocol handler API (tl;dr: watch this 4 minute live demo)
• worth noting, this type of generic handler API could enable other DWeb projects (DAT, SSB) to create native client extensions for Brave, so this may be delivered as a community effort, similar to mozilla/libdweb

What are the next steps?

IPFS roadmap for bringing IPFS to Brave in 2019 will include (P0 - priority):

• Marking ipfs-companion as blessed_extension and making use of raw socket APIs for:
  • (P0) (MVP) Exposing localhost HTTP Gateway (making js-ipfs node running in WebExtension is as useful as go-ipfs)
  • (P3) Local Discovery and better p2p transports
• (P1) Onboarding experience in Brave (“Detects the first time user tries to access IPFS resource and asks if support for IPFS should be installed”)
• (P2) Creating protocol handler API for Chromium (porting libdweb experiment from Firefox)

Note: “Bundling go-ipfs with Brave” is still a possibility, and work done on extension responsible for binary updates may be resumed and used in the future, but we want to see if we can expose HTTP Gateway over chrome.sockets.tcpServer. If that is possible, we may be able to ship sooner than later.

If js-ipfs approach takes too much time, or (P0/MVP) does not work as expected, we can always focus back on bundling go-ipfs.

[da2x]

Will creators be able to earn Brave Rewards for content distributed over IPFS?

Creators could claim their IPNS by publishing the brave-payments-verification.txt under their IPNS. Brave could verify this using a public HTTP gateway such as https://cloudflare-ipfs.com/ipns/<id>/.well-known/brave-payments-verification.txt.

The Brave client would have to recognize and attribute time spent on http://127.0.0.1:8080/ipns/<id>/*, https://*/ipns/<id>/* (public gateways), ipns://<id>/*, and dweb://ipns/*<id> to a normalized address like ipns://<id> and handle this in the rewards system.