The Brave browser recently added support for the InterPlanetary File System (IPFS) protocol in its beta release channel (desktop only). IPFS is a peer-to-peer (P2P) protocol that can be used in web browsers to visit websites that are hosted by the website’s visitors instead of a central web server. This is called the distributed web. For the last two decades, the open web has been on a steady course into the hands of a few behemoth multinational companies. The distributed web is a tool that can wrangle back control from the few and hand it back to the many.
The distributed web still hasn’t gone mainstream, and Brave’s one percent market share won’t drastically change the web’s architecture overnight. Brave’s adoption of IPFS is notable because it’s the first time an externally developed P2P protocol makes it into a web browser. Previous attempts at a P2P web browser, such as BitTorrent Maelstrom, has always been lead by the developers of the protocol. No P2P protocol has convinced a web browser vendor to integrate their protocol before.
Previously, you’ve only been able to use IPFS in web browsers by installing a separate program and a companion extension in your web browser. Brave now comes with native built-in IPFS support. Its support isn’t quite equivalent to HyperText Transfer Protocol (HTTP) yet, but it’s a huge leap forward for IPFS. When you open an IPFS link (ipfs://example/) in Brave, it will open it using a public web-gateway server by default. Gateways are public web servers that proxy content from the IPFS network via a traditional web server. Brave will also prompt you to enable native IPFS support, and warns you about IPFS privacy issues. More on the IPFS privacy issues later.
Brave hasn’t developed a new implementation of IPFS. Instead, Brave ships the IPFS reference client and runs it as a helper process. I had wrongly assumed that js-ipfs, an almost fully-featured IPFS client written in JavaScript, would be the foundation of the first browser to ship with IPFS integration. Brave launches the IPFS daemon on demand when you access IPFS content. It doesn’t launch it with the browser when it’s not needed.
You can check on the IPFS daemon’s status by navigating to brave://ipfs. Advanced users can modify the brave_ipfs/config file in their Brave profile directories with information from the above page to gain access to the more advanced IPFS web administration interface.
Brave will cache up to 1 GB of content accessed over IPFS. The cached content is made available to others on the IPFS network as long as the daemon is running. Brave will automatically delete the cached content using the IPFS garbage collector (GC) process. There’s been no significant changes to IPFS’ GC since I discussed it . The GC deletes all cached content once 90 % of the 1 GB cache quota is filled. The IPFS cache is notably absent from the Delete browsing data dialog. (See issue #13302.) It’s entirely separate, and you’ll need to quit Brave and manually delete its directory from your device if you want to remove it.
Update (): Brave Software liked my feedback and are working on adding IPFS to the Delete browsing data dialog. See issue #7578 for details.
Peer-to-peer applications like IPFS can have negative impacts on device battery life. IPFS in particular has a bad reputation for consuming enormous amounts of RAM and bandwidth. However, Brave runs the IPFS daemon in distributed hash table (DHT) client mode instead of being a full participant in the DHT network. The DHT is a distributed database on what data each peer in a P2P network makes available to the network. DHT client mode drastically reduces the client’s participation in the DHT network and keeps resource use low.
Most other P2P applications make each peer a full participant in its DHT network. What makes IPFS so different is that the DHT is enormous. With P2P protocols like BitTorrent, the DHT network only stores one bit of data — the BitTorrent info hash — for a collection of files (the torrent file). In IPFS, every file is divided into smaller pieces, and the DHT network needs to store and exchange information about each piece of every file that is available in the network. This gives IPFS advantages such as higher availability and global de-duplication in the network, but it also requires a lot of work from DHT participants.
You have no anonymity or privacy when using IPFS. The IPFS network exchanges data using “content addresses”, a cryptographic hash that uniquely identifies a file. The content address of every file — or part of a file — you download over IPFS is broadcast into the DHT network. Anyone who knows a file’s content address or the hash of its contents can request a copy of it from the network. Anyone in a position to monitor your internet traffic — the local network operator, internet service provider, or government — can monitor what you download through IPFS. This isn’t specific to Brave’s implementation, but an issue with many P2P protocols including BitTorrent and IPFS. Other peer-to-peer protocols, such as the Hypercore Protocol, have found clever ways to address the problem.
The Brave browser also features a built-in Tor onion networking proxy. It can be accessed by opening a private window in Tor mode. In this mode, your internet traffic is encrypted in multiple layers and bounced around between different relay servers to hide its origin and its destination. IPFS in Brave can’t be accessed from within Brave’s Tor mode. Tor only supports TCP connections, and IPFS uses UDP and QUIC connections.
Brave shows the protocol in the address field as ipfs:// when accessing IPFS content through the native daemon. However, this is purely cosmetic. If you query the browser engine about the document origin (e.g. through window.location.origin), it’ll return http://hashcontenthash.ipfs.localhost:12345/ instead of ipfs://hashcontenthash/ as expected. (See issue #13303.)
The Chromium extension API sees the expected address, however. Which can cause conflicts in some extensions when it tries to correlate data from the browser engine and the extension API. Many extensions will also fail in unexpected ways anyway for documents that aren’t served from either https:// or http://.
With its new IPFS support, Brave is probably the preferred viewer for IPFS content. While Brave supports both the ipfs:// and ipns:// protocol schemes, it doesn’t register these protocol associations with the host operating system. This means that your operating system won’t try to open these links using Brave when clicking on a link in a third-party application. (See issue #13266.) You can’t just install Brave and then use it on-demand for IPFS when you click on an IPFS link inside Firefox, for example.
Brave enforces a strict security policy that blocks mixed-content IPFS on HTTPS origins. You can’t load e.g. a script, video, or iframe from an IPFS address on a webpage served over HTTPS. This limitation makes it more difficult to experiment with partially distributed websites where some of the content is served from a traditional web server and some content from IPFS.
I suggested to Brian Bondy, Chief Technology Officer at Brave Software, that websites could opt-in to allowing IPFS content to load in their context using a Content-Security-Policy (CSP) response header. CSP is a mechanism that allows websites to specify a list of sources that are allowed to load various resources on a website. (Read the discussion on Reddit.)
Brave natively supports the InterPlanetary Name System (IPNS), a DHT-powered alternative to the Domain Name System (DNS). An IPNS is a hash, like IPFS addresses, but unlike IPFS the hash can be changed later. An IPNS address can represent your website your time as its changing where as an IPFS address is a single snapshot in time. However, hashes aren’t human friendly and they’re difficult to remember.
To address this, IPFS developers came up with DNSLink, a system for publishing IPFS and IPNS addresses using DNS. The IPFS Companion extension uses DNSLink to look up IPFS address as you visit websites and redirect to the IPFS version if there is one available. Brave doesn’t support DNSLink, however.
It’ll be more interesting to experiment with IPFS now as the barrier to visiting an IPFS website has been lowered to “just install Brave on your computer.” IPFS needs to sort out a human-readable and memorable naming scheme, though. No one will see any success with their distributed websites if visitors need to access a website to look up a complex hash-based address to get to it. The absolute ban on loading mixed-content IPFS on HTTPS websites is a missed opportunity for websites to start experimenting with offloading portions to IPFS. It’ll be interesting to watch what happens in this space in the coming years.