Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
IPFS Integration - Roadmap and discussion #819
Carried over from brave/browser-laptop#9556
What are the next steps to shipping Brave with IPFS?
My understanding is that Brave is going to use a custom build of Chromium because it does not support custom protocols without the
Quoted from arewedistributedyet/issues/23
However he road block is upstream; getting Chromium to support DWeb protocols - which seemingly has been officially started on Aug 17 2018
Assuming the protocols get supported and are included in a near future build of Chromium. What will the general integration process look like?
If it is used, is the sample code below seem close to the general concept? Redirecting ipfs:// traffic to a ipfs gateway?
On HTTP-based Protocol Handler
When requirement for
The problem with having
Still.. better than nothing :)
On Native Protocol Handler
As noted in brave/browser-laptop#9556 (comment) API at
An experimental, native protocol handler API is being designed as WebExtension API at mozilla/libdweb/#protocol-api and
It is in a relatively a far future, and we could plan for delivering integration without native handler (see below).
Short Term: Choosing HTTP backend for IPFS Companion
Without native protocol handler API we can't fetch data from IPFS directly and need to use HTTP gateway so URLs still work and can be opened by HTTP-based handler registered with
HTTP Gateway can be provided by either locally running go-ipfs or js-ipfs running in Node (js-ipfs running in browser context can't open TCP port to serve HTTP requests). We could also just use public HTTP Gateway (go-ipfs) at
In the short term I would go with go-ipfs due to reasons listed in ipfs-shipyard/ipfs-companion#312 (comment).
I see three ways to deliver integration:
If (1) is not possible then go with (2) to minimize maintenance burden and user confusion.
I would love to see (1) – what are the next steps to move in that direction?
Long Term: Adding Missing APIs for Native Handler, Discovery and Transport
To get all benefits of IPFS (and other p2p protocols) we need at least:
I really like shipping go-ipfs with Brave!
Not only is it great UX, but it add a competitive advantage to Brave from a product growth perspective. Similar to how Tor Tabs incentives users to move from the commercial browsers to Brave (because of its added feature set)
How do we go about adding a program the way Tor Tabs did.
Looking through the project in brave-laptop I find
which seems to pull the binaries from S3 (interesting)
Does this suggest we need to host the IPFS go binaries somewhere and these are pulled in and installed with Brave?
Is there someone who worked on TorTabs and has insight to the process of shipping a binary with Brave?
Looking at their commits pertaining to Tor build packaging and the build_tor_scripts I've pieced together these basic next steps:
i've added a repo at /drbh/ipfs_build_scripts as a starting point for the build scripts.
also i've created a fork of brave/browser-laptop and added a branch called ipfsPackageBuild at /drbh/browser-laptop with what seems like the necessary files for brave to fetch the binaries.
The signature need to be updated in package_ipfs after the binaries are correctly built, and some adjustments to ipfs version are needed.
I'm most confused about the build process for the ipfs_build_scripts, because the tor_build_scripts seem to add dependencies in a specific way like
If anyone has insight on the build process this would be greatly appreciated. I hope my boilerplate code is helpful.
@drbh thank you, the insight is really appreciated!
We also have https://github.com/ipfs/distributions which is responsible for fetching and publishing pre-built artifacts at https://dist.ipfs.io/#go-ipfs website. I can reach out to people and see how much of already existing process can be reused.
Before we dive into details, I have a question about
I ask because we already have pre-built go-ipfs binaries for platforms you target with Brave and we could download them from there just like it is done with Tor on win32 here. It would simplify entire setup by removing a lot of moving pieces.
Retrospectively it seems like overkill to build from source. I was doing so only because I was following the path that the Tor binaries needed.
I understand now that they only built them from source for dynamic linking purposes - it seems that the Windows binary doesn't need the same dyn linking that the
Based on this we have two paths forward - including some sample code to get close to the intended goals
It seems like the first way of fetching the binaries within Brave is the easiest path forward. However it is noted that Tor binaries have been compiled and pushed to a S3 location. Maybe there is value in this data flow, however it seems unneeded for IPFS because it doesn't depend on dynamic linking.
I can take on the
@drbh To keep momentum going let's go with direct download for now (1) and see if that works well enough. If it turns out we need custom build for some platforms or Brave decides they want to host files at S3 to control user experience end-to-end, we can always add step (2) at a later stage.
FYI dist.ipfs.io has a valid DNSLink, which means fetching from https://ipfs.io/ipns/dist.ipfs.io/go-ipfs/v0.4.17/ (or any other public gateway) will also work.
If we have that, next step would be making sure ipfs daemon is initialized and configured for Brave.
Looking in /brave-core/tree/master/browser/extensions I see a few files that reference Tor but they seem to only reference a Tor client update.
Any clarification is greatly appreciated! Thanks
In addition - the biniary is pulled via dist.ipfs.io
ipfs daemon starts when the
Above code that fails:
I don't exactly understand why the build fails when using
IPFS packaging and barebones daemon management - ipfsPackageBuild branch
@drbh apologies for not getting to it earlier, slipped thru my notifications.
The main use for
Are you still blocked by the above error?
Update: I think a safe path would be to create a PR to brave-core-crx-packager that creates CRX bundle with IPFS binary similar to one already present for Tor, and then get some feedback on what are the next steps for the Chromium version.
Will creators be able to earn Brave Rewards for content distributed over IPFS?
Creators could claim their IPNS by publishing the
The Brave client would have to recognize and attribute time spent on