ipfs / ipfs-companion

Browser extension that simplifies access to IPFS resources on the web

IPFS Companion Browser Extension

Harness the power of IPFS in your browser!

Firefox | Firefox for Android	Chrome | Brave | Opera | Edge

---

Table of contents

• About IPFS Companion
• Features
• Install
• Contribute
• Help & Troubleshooting
• Privacy & Licenses

About IPFS Companion

IPFS Companion harnesses the power of your locally running IPFS node (either through the IPFS Desktop app or the command-line daemon) directly inside your favorite Chromium-based or Firefox browser, enabling support for ipfs:// addresses, redirecting content-addressed websites and file paths to your local Gateway, easy IPFS file import and sharing, and more.

IPFS is a peer-to-peer hypermedia protocol designed to make the web faster, safer, more resilient, and more open. It enables the creation and dissemination of completely distributed sites and applications that don’t rely on centralized hosting and stay true to the original vision of an open, flat web. Visit the IPFS Project website to learn more.

IPFS Companion features

Automatically detect and redirect IPFS resources

Detect URLs with IPFS paths

IPFS Companion detects and tests requests for IPFS-like paths ( such as /ipfs/{cid} or /ipns/{peerid_or_host-with-dnslink}) on any website. If a path is a valid IPFS address, it is redirected to load from your local gateway. The gateway at localhost will also automatically switch to a subdomain to provide a unique origin for each website:

https://ipfs.io/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR → http://localhost:8080/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR → http://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi.ipfs.localhost:8080

Detect DNSLink-enabled URLs

IPFS Companion detects DNSLink info in the DNS records of websites. If a site uses DNSLink (a few examples are https://docs.ipfs.io, https://ipld.io, and http://tr.wikipedia-on-ipfs.org), IPFS Companion redirects the HTTP request to your local gateway:

http://docs.ipfs.tech → http://localhost:8080/ipns/docs.ipfs.tech → http://docs.ipfs.tech.ipns.localhost:8080/

Detect pages with x-ipfs-path headers

IPFS Companion also upgrades transport to IPFS if it finds the x-ipfs-path in any HTTP response headers; this also acts as a fallback for cases when an IPFS path is not present in the URL. Learn more.

Toggle redirects globally or per site

You can disable and re-enable local gateway redirects by several means:

• Suspend redirects globally in IPFS Companion's preferences
• Suspend redirects per site using the toggle under "Current tab" (illustrated below) or in IPFS Companion's preferences
• Add x-ipfs-companion-no-redirect to the URL itself as a hash (example) or query parameter (example)

Access frequently-used IPFS actions from your browser bar

IPFS Companion enables you to quickly and easily access common actions from your browser bar with just a few clicks:

• See how many peers you're connected with a glance at the cube icon in your browser bar
• Check your IPFS API and gateway status by clicking the cube icon to reveal the main menu
• Right-click images and other page assets to easily add them to IPFS (including the option to preserve file names)
• Choose the Import option in the main menu for quick drag-and-drop import from a browser tab
• Pin or unpin IPFS resources (via API) directly from the main menu
• Copy shareable public gateway links, IPFS content paths, or CIDs of IPFS resources directly from the main menu
• Launch the IPFS Web UI dashboard from the main menu with a single click
• Toggle gateway redirects or switch all IPFS Companion features on/off quickly and easily from the main menu (illustrations below)

Toggle gateway redirects on a per-website basis

You can toggle redirects (of any IPFS sub-resources) for an individual website under the Current Tab section of the main menu. If that site uses DNSLink, toggling off will restore the site's original URL, too.

Switch all IPFS Companion features on/off

To temporarily suspend all IPFS integrations (redirects, API status content scripts, protocol handlers, etc.), use the on/off button at the top of the IPFS Companion menu.

Try out experiments!

IPFS Companion ships with a variety of experimental features. Some are disabled by default, so be sure to check out IPFS Companion's Preferences to see them all.

• Make plaintext IPFS links clickable (demo)
• Re-route requests made via the following experimental protocols to an HTTP gateway (public or custom):
  • ipfs://$cid
  • ipns://$cid_or_fqdn

Install IPFS Companion

Latest stable release

Firefox | Firefox for Android	Chrome | Brave | Opera | Edge

Important! Make sure you have IPFS installed on your computer as well. Because IPFS Companion (in its standard configuration) talks to your computer’s local IPFS node to work its browser magic, you’ll need to have IPFS running on your computer, too.

It's also possible to grab vendor-specific packages for each release, but these builds are not signed, nor will automatically update. .zip bundles are meant only to be manually loaded via chrome://extensions (Chromium) or about:debugging (Firefox) for smoke-testing.

Development

To work on IPFS Companion's code, you'll need to install it from source. Quick steps are below, but see the full developer notes for more detailed instructions and tips.

1. Clone https://github.com/ipfs-shipyard/ipfs-companion.git
2. Run this all-in-one dev build to install dependencies, build, and launch in the browser of your choice:
   • Chromium

     $ npm run dev-build chromium

   • Firefox

     $ npm run dev-build firefox    # firefox:nightly works too!

Contribute

All are welcome to help make IPFS Companion even better!

• Check out the contribution guide for how to get started as a developer
• Open an issue
• Make sure you read and abide by the IPFS Code of Conduct

Release Process

The release process has been documented here.

Help & troubleshooting

Ask a question

The best place to ask about IPFS Companion (or IPFS in general!) is in the official IPFS Forums, where you can search past discussions for others who may have had the same questions, too. There's also an active #ipfs community on IRC.

Common troubleshooting steps

These frequently encountered troubleshooting situations may be helpful:

• Import via right-click does not work in Firefox: See this workaround.
• HTTP-to-HTTPS redirects fail when using Ghostery: Ghostery is known to toy with HTTP-to-HTTPS redirect, which in some setups breaks websites utilizing public gateways (more details). Until this is fixed upstream, a workaround is to whitelist affected sites.
• NoScript breaks IPFS Companion: By default, NoScript breaks IPFS Companion by blocking assets loaded from an IPFS gateway running on localhost. To fix this, extend the SYSTEM ruleset and prepend it with IPFS whitelist (feel free to modify this, but get familiar with ABE rule syntax first):

# Enable IPFS redirect to LOCAL
Site ^http://127.0.0.1:8080/(ipfs|ipns)*
Anonymize

# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

Privacy & license info

• IPFS Companion Privacy policy
• The IPFS logo belongs to the IPFS Project and is licensed under a CC-BY-SA 3.0 license
• is-ipfs, js-multihash, and other npm dependencies are under MIT license, unless stated otherwise
• IPFS Companion itself is released under CC0; to the extent possible under law, the author has waived all copyright and related or neighboring rights to this work, effectively placing it in the public domain

ipfs-companion's Issues

Manual checksum verification

It should be possible to build .xpi from a specific tag and compare some kind of checksums with .xpi provided on releases page.

One can't just checksum XPI (zipped archive) as it changes on each build:

$ cfx xpi ; sha256sum ipfs-firefox-addon.xpi
Exporting extension to ipfs-firefox-addon.xpi.
28d36735dfc0ae98124580fc17d1255b0a1466d8dc8966dad13f3b43b640d360  ipfs-firefox-addon.xpi
$ cfx xpi ; sha256sum ipfs-firefox-addon.xpi
Exporting extension to ipfs-firefox-addon.xpi.
2345d6d78138b4575b0784c2d08026e2ce6c7b0a797249b51bb32d7d95524a8e  ipfs-firefox-addon.xpi

Release v1.5.0 to AMO

The purpose of this issue is to track release progress of version 1.5.0

• Tag
• Update README & screenshot
• Submit to AMO for Full Review
• Full Review passed
• Update AMO page

Minimize use of custom protocol handler

While having thesupport for 'virtual' URI like ipfs:QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D is handy and provides us with nice abstraction, we should always redirect from virtual protocol to real URI from a HTTP gateway.

Gist is this: always display real URI in address bar (but also provide an easy way of obtaining IPFS links).

Refine Regex match (https, gateway. prefix dropped)

The 'gateway.'-prefix was obsoleted recently (ipfs/infra#4) and the addon doesn't catch these links yet. HTTPS was also enabled on the public gateways (ipfs/infra#71) these don't match either, I think.

Add Localization via l10n API

Right now GUI is in English only.
The short-term goal here is to have English and Polish translations + support for potential Pull Requests with other locales 🎁

References:
https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/l10n

Fix CORS error when loading HTML page via fs: protocol handler

Opening page with JavaScript via ipfs: protocol handler results in CORS error.
Example: ipfs:QmSrCRJmzE4zE1nAfWPbzVfanKQNBhp7ZWmMnEdbiLvYNh/mdown#sample.md

Bit late today, will look into this later this week.

Add-on Compatibility for Firefox 44

Just a reminder to go over changes 44 and redactor things if this add-on use deprecated features.

Ref. https://blog.mozilla.org/addons/2015/12/29/compatibility-for-firefox-44/

Add support for IPNS

Right now we only support http://gateway.ipfs.io/ipfs/<hash>, the goal is to support http://gateway.ipfs.io/(ipfs|ipns)/<hash>

Test and Adapting to Multiple Processes

Dear add-on developer,

You might have heard the news[1] that future versions of Firefox will run the browser UI separately from web content. This is called Multi-process Firefox (also "Electrolysis" or "e10s")[2], and it is scheduled for release in the first quarter of 2016[3].

If your add-on code accesses web content directly, using an overlay extension[4], a bootstrapped extension[5], or low-level SDK APIs[6] like window/utils or tabs/utils, then you will probably be affected.

To minimize the impact on users of your add-ons, we are urging you to test your add-ons[7] for compatibility. You can find documentation on how to make them compatible here[8].

Starting Nov. 24, 2015, we are available to assist you every Tuesday in the #addons channel on irc.mozilla.org[9]. Click here[10] to see the schedule. Whether you need help testing or making your add-ons compatible, we're here to help!

Sincerely,
The Add-ons Team

[1] https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
[2] https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox
[3] https://wiki.mozilla.org/Electrolysis#Schedule
[4] https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions
[5] https://developer.mozilla.org/en-US/Add-ons/Bootstrapped_extensions
[6] https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs
[7] https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox#Testing
[8] https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox#Updating_your_code
[9] irc://irc.mozilla.org/addons
[10] https://atsay.github.io/e10s_office_hours/

TravisCI: eslint:standard fails

Line 461:

Running "eslint:target" (eslint) task
Warning: standard:
    Configuration for rule "no-labels" is invalid:
    Value "2,[object Object]" has more items than allowed.
Referenced from: /home/travis/build/lidel/ipfs-firefox-addon/.eslintrc.json� Use --force to continue.
Aborted due to warnings.

Probably need to bump node version, tests are running on an ancient one.

ReferenceError: AddonManager is not defined

An error in Browser Console.

Repro: this happens when dnslookup is executed while gateway is offline:

console.error: ipfs-firefox-addon: 
Object
    - _errorType = ReferenceError
    - message = AddonManager is not defined
    - fileName = javascript:AddonManager.getAddonByID("[email protected]", function(aAddon) {unsafeWindow.gViewController.commands.cmd_showItemDetails.doCommand(aAddon, true);});
    - lineNumber = 1
    - stack = @javascript:AddonManager.getAddonByID("[email protected]", function(aAddon) {unsafeWindow.gViewController.commands.cmd_showItemDetails.doCommand(aAddon, true);});:1:1|
    - name = ReferenceError

Sites under public gateways list can't make XHR request

I have site http://bin.kubuxu.ovh, its A records are same as ipfs.io. If I add it to the public gateways list XHR request to /ipfs/[some hash] fails because it is rerouted to local gateway which breaks AJAX somehow. In my case solution would be to redirect site to: http://localhost:8080/ipns/bin.kubuxu.ovh/ then XHR will be allowed to fetch data from /ipfs/....

The solution for this problem might be tricky as for example http://ipfs.pics has to make requests to severs itself (it does not have dnslink).

Add support for HTTP Gateway root

When ipfs/kubo#807 is implemented, this addon could provide an easy UI for going to the page with one click (if custom gateway is enabled).

Create basic tests

There should be a set of basic smoke-tests that make sure the redirect and protocol handlers work as expected.

Zopfli optimization of PNG assets

Just check if there is any saving in comparison to current -- already optimized -- version.

Ref. http://blog.codinghorror.com/zopfli-optimization-literally-free-bandwidth/

Replace regexes with proper IPFS path/multihash validation

• Find a way of using NPM packages within JPM-based addon
• Replace regexes with proper IPFS path/multihash validation via common library

---

As suggested in ipfs/notes#92 (comment) and #43 we should stop using regexes for detecting IPFS paths and come up with something more future-proof that involves js-multiaddr and js-multihash.

First step would be to create internal PoC in lib/ipfs-path-validation.js with isValidIPFSPath(path) method and then refactor addon to use it instead of gateways.IPFS_RESOURCE and protocols.IPFS_PATH regexes.

Add support for web+ schema prefix

As in chrome 'web+' is only allowed prefix for JS schema handling then most sites will be using it (and using JS to rewrite it to gateway). Accepting it and rewriting it to plain fs would be optional solution.

Expose some information to JS in the site

Possibly in collaboration with chrome addon, expose some useful data to sites wanting to use more of IPFS:

• is (web+)fs:/ handled - for rewriting or local protocol handlers
• js-ipfs-api
  some more?

EDIT: changed after discussion

Enable redirect for domains with dnslink in TXT record

DNS query API is ready (ipfs/kubo#1054 (comment)) which means we could implement it as a part of #16 effort.

• While user browses the web addon should query API regarding newly discovered hostnames and load site resources from IPFS if dnslink is present (and custom gateway redirect is enabled) – 037ea98
• Initially it should be an experimental feature (disabled by default) – 037ea98
• API responses should be cached in-memory for some time – 49a00cc
  • Note that we redirect to /ipns/ address and ignore dnslink path from DNS. Thanks to this, we can cache DNS responses for a long time.
    It is up to the gateway to get the latest version
• Tests
• Do not cache dnslink lookup when API is offline – 2c37516

---

Site with dnslink:

GET http://localhost:5001/api/v0/dns/ipfs.io

{"Path":"/ipfs/QmSrk8wCZ9oUgSCxJq4TXyJnPBYfoLDpKLGn7hLPNzauVX"}

---

Site without dnslink in TXT record:

GET http://localhost:5001/api/v0/dns/google.com:

{"Message":"could not resolve name.","Code":0}

Move to the "standard" JS linter & formatter

As of now we use raw ESLint (with some opinionated settings simply copied from my other projects) while /ipfs/community/js-contribution-guidelines (#59) suggests http://standardjs.com to be used across IPFS-related projects, where possible.

I think it may be beneficial to switch and enforce it via standard-format as a pre-commit hook.

(I did a dry run and the main change from current style is the removal of semicolons.)

I'll leave this open for a week or so and if there will be no cons raised – commit the change.

Linkify ipfs-ish text

options to turn plain /ipfs/ and ipfs:// text into links and context menu entries to open any highlighted multihash as ipfs links would be nice.

Support unix-like URI /ipfs/ in address bar

For lazy copy&paste ;-)
It should work the same way as currently exiting ipfs:

Add ipfs: protocol handler

We should support ipfs://<hash> and forward such requests to HTTP Gateway

bug in pathing redirection

ipfs://ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg

goes to

http://127.0.0.1:8080/ipfs/ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg

it should go to

http://127.0.0.1:8080/ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg

Copypaste public gateway URL from location bar

I'm accustomed to copying URLs with Ctrl-L Ctrl-C. This gives me the custom gateway URL (http://localhost:8080/etcetera), rather than the public gateway URL (https://ipfs.io/etcetera).

If possible, it would be nice to be able to copy the public gateway URL from the location bar. Ideally, the location bar should still visually display the custom gateway URL (or, optionally, the canonical address), similarly to how it normally displays e.g. "example.com" but copies as "http://example.com/".

Keep IPFS URIs?

Is it possible to keep the IPFS urls instead of redirecting to gateway? i.e. proxy the request in the extension to the local gateway so url bar remains the same.

Verify multihash in the browser

No matter if it is a public gateway or a custom one, add-on should calculate hash for received data and compare it with the one from URL.

Not sure what should happen when hash does not match. Probably HTTP Server Error Code (5xx).

Refs.

• Source of idea: https://botbot.me/freenode/ipfs/msg/36342455/
• https://github.com/jbenet/js-multihash
• https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_Error

False-positive href rewrites (when "Extended IPFS link support" is enabled)

It breaks on ipfs's github as it starts with /ipfs/....

On solution would be to push ipfs/notes#92 forward and resolve it in case of /ipfs/... or /ipns/... to confirm if redirection to local gateway should take place.

API port should be configurable

It should be possible to set it up just like the HTTP Gateway one.

Option to copy IPFS links

It should be possible to quickly get an URL pointing to a page at public HTTP gateway: http://gateway.ipfs.io/(ipfs|ipns)/<hash_of_curently_loaded_resource>.
This would be very handy for sharing on IM etc.

We could also provide second option, that copies link in this format:
ipfs:<hash_of_curently_loaded_resource> (or ipns:<hash_of_curently_loaded_resource>)

References:
https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/clipboard

Move to WebExtensions

Why?

We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers. [..]

Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback. Add-ons that are built using the new WebExtension API will continue to work. We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.

Source: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

ipfs-companion Migration Status

• make sure current version runs fine in multiprocess firefox (#18, #26)
• confirm WebExtension add-ons can be uploaded to and signed on addons.mozilla.org (AMO)
• create webextensions branch
• create addon boilerplate (moved to #144)
• update JPM(web-ext?) to a version capable of building WebExtension addon
• find a way to write and run test suite (moved to #145)
• switch development to master branch, delete webextensions one, move legacy code to legacy-sdk
• [MVP done] Rewrite add-on as WebExtension
  • All activities are tracked in a dedicated project:
    https://github.com/lidel/ipfs-firefox-addon/projects/1
  • There is also Milestone view for v2.0.0 with remaining Issues:
    https://github.com/lidel/ipfs-firefox-addon/milestone/3
• 🚧 [in progress - awaiting review] 🚧 release WebExtension to stable channel at http://addons.mozilla.org/

References:

• https://wiki.mozilla.org/Electrolysis#Enabling_and_Disabling_Electrolysis
• https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html
• https://blog.mozilla.org/addons/2016/03/14/webextensons-whats-in-it-for-developers/
• https://developer.mozilla.org/en-US/Add-ons/WebExtensions
  • Comparison with the Add-on SDK
  • Comparison with XUL/XPCOM extensions
• https://wiki.mozilla.org/Add-ons/developer/communication
• https://compatibility-lookup.services.mozilla.com/
• http://arewewebextensionsyet.com/
• https://blog.mozilla.org/addons/2016/07/21/new-webextensions-guides-and-how-tos-on-mdn/
• https://blog.mozilla.org/addons/2016/07/27/linting-and-automatically-reloading-webextensions/
• https://blog.mozilla.org/addons/2016/08/25/webextensions-in-firefox-50/
• https://wiki.mozilla.org/WebExtensions/Experiments
• https://trello.com/b/PC9kB14s/webextensions-roadmap
• https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/
• https://github.com/mdn/webextensions-examples

Support for fs:/* protocol handler

As discussed in ipfs/kubo#1678 (comment)

TravisCI fails with `Should not be any unexpected windows open`

While tests run fine locally, TravisCI fails additional harness test run by SDK:

..console.error: ipfs-firefox-addon: 
  fail:
  Should not be any unexpected windows open
console.trace: ipfs-firefox-addon: 
_ecated/unit-test.js 108 fail
_ecated/unit-test.js 342 done/<
_/Promise-backend.js 934 Handler.prototype.process
_/Promise-backend.js 813 this.PromiseWalker.walkerLoop
_/Promise-backend.js 747 this.PromiseWalker.scheduleWalkerLoop/<
console.log: ipfs-firefox-addon: Windows open:
console.log: ipfs-firefox-addon: chrome://browser/content/browser.xul - about:blank
console.log: ipfs-firefox-addon: Location {"href":"chrome://global/content/alerts/alert.xul","origin":"chrome://global","protocol":"chrome:","username":"","password":"","host":"global","hostname":"global","port":"","pathname":"/content/alerts/alert.xul","search":"","hash":""}

A wrapper script will detect and ignore this (there is no point in debugging JPM if we will move to WebExtensions anyway)

Automatic Mode

Disabling gateway redirection if IPFS is non functional would be nice feature.

Local gateway redirection could be disabled if:

• ipfs.io responses to /version (we have connection with alternative) and
• local gateway has no peers in swarm

potential issues with https sites / https gateway

When this is used with an https site & https gateway, it throws a mixed content error, like:

Blocked loading mixed active content "http://localhost:8080/ipfs/QmSSPK25wLZ7JmJ2qE6ECK5veiTHVD7UVze9Nx6LB2o681/jquery.min.js"

...Since localhost is on http. Obviously loading from localhost via http is fine, since it never actually goes over the network, but firefox will throw an error anyway.

Also, this isn't an error with the current version, but rather a problem that arises if it is modified and a gateway other than http://gateway.ipfs.io is used, or if gateway.ipfs.io supports https in the future.

Custom protocol handlers do not work with first request on an empty browser session

TL;DR: just read #33 (comment)

---

I noticed that protocol handlers (ipfs:// etc) do not work under FF 44.

I thought it is related to #28 and this error from lib/child-main.js:

console.error: 
  Message: Module `@test/options` is not found at resource://gre/modules/commonjs/@test/options.js
  Stack:
    @resource://gre/modules/commonjs/sdk/test/options.js:10:17
@resource://gre/modules/commonjs/sdk/addon/window.js:15:17
@resource://gre/modules/commonjs/sdk/net/xhr.js:12:24
@resource://gre/modules/commonjs/sdk/request.js:17:56
@resource://ipfs-firefox-addon-at-lidel-dot-org/lib/gateways.js:41:17
@resource://ipfs-firefox-addon-at-lidel-dot-org/lib/protocols.js:8:10
@resource://ipfs-firefox-addon-at-lidel-dot-org/lib/child-main.js:3:15
@resource://gre/modules/commonjs/sdk/remote/child.js:81:3
emitOnObject@resource://gre/modules/commonjs/sdk/event/core.js:112:9
emit@resource://gre/modules/commonjs/sdk/event/core.js:89:38
messageReceived@resource://gre/modules/commonjs/sdk/remote/child.js:67:37

BUT:

I reverted to v1.3.1 and the same code does not work with unsigned add-on under Developer's FF 44, but does work with signed one and Official FF 42 (the one from Mozilla addon store). It also works fine with unsigned add-on and older FF 40.

I see three options:

• there is no bug, there is something wrong with my local setup
• custom protocol handlers do not work / require some additional code in FF > 42
• custom protocol handlers do not work when extension is unsigned

I would appreciate if someone try to replicate this issue by running against specific Firefox versions:

jpm -b /path/to/firefox-45.0a2/firefox run

and checking if ipfs://QmTAsnXoWmLZQEpvyZscrReFzqxP3pvULfGVgpJuayrp1w redirects to local gateway (for me, it redirects to Google search instead).

Option to set custom HTTP Gateway URL

It should be possible to specify HTTP Gateway URL (different than http://127.0.0.1:8080/ipfs/).
This should be persisted via simple-prefs

Rule to work with NoScript with ABE enabled

I just started playing with IPFS and noticed that NoScipt blocks objects from loading after the addon does it's magic. I've only tested this rule a little bit, and I'm not sure if it's as secure or inclusive as it should be, but it's worked for me so far.

It'd be nice to have the rule in the documentation at least for users who aren't interested in reading the ABE syntax docs, etc.

In the SYSTEM Rulset I added the first three lines of the following before the existing local deny rule.

# Enable IPFS redirect to LOCAL
Site ^http://127.0.0.1:8080/(ipfs|ipns)*
Anonymize

# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

You can find more info about the ABE rule syntax at https://noscript.net/abe/abe_rules.pdf

Set up Travis CI

Set it up to run tests (#9) on Push or PR.

Open Preferences from Toolbar Menu

There should be an easy access to "Preferences" screen.
Adding it as a link under "Open WebUI" one should be enough.

Ref. https://stackoverflow.com/a/22601737

Support website hints to reroute HTTP query to IPFS

Summary of Open Ideas

• Detect host names with dnslink and redirect requests to IPFS (/ipns/<fqdn>)
  • PoC in #16 (comment)
• ipfs/notes#92: Recognize IPFS gateways running on arbitrary websites
  • idea(1): run some kind of validation for URL that contain /ipns/ or /ipfs/ segment (risk of false-positives for IPNS namespace)
  • idea (2): read TXT DNS record and check if it contains dnslink (no false-positives)
• ipfs/notes#104 A hint that site assets with names being valid IPFS multihashes can be loaded from IPFS
  • idea: use RFC 6249: Metalink/HTTP: Mirrors and Hashes as a way to provide hint via HTTP headers

Semi-related:

• ipfs/in-web-browsers#55: IPFS runs as a Service Worker!

Signing XPI package

The cheapest universally supported (Mozilla, Java, Microsoft) certificate seems to be the Comodo Instant-SSL offering. You can get a free certificate for open-source developers from Unizeto Certum, in 2010 it is a Certum Level III CA.

Refs:

• So you want to sign your XPI package?
• Obtaining a valid software developer code-signing certificate
• Incorporating signing into your build process

Toolbar button click should display menu

As for the ToggleButton improvements, this is what I have in mind:

The popup panel would have all items from the context menu (copy link, pin resource etc) + on/off switch for entire plugin (current onClick behaviour).

Store and restore prefs between each test case

Otherwise we run into tests breaking other tests when run via jpm -b $FIREFOX_BIN test --times 3

Follow ECMAScript 5's strict mode

ECMAScript 5's strict mode is a way to opt in to a restricted variant of JavaScript.

Ref.

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
• "Securing" JavaScript
• http://caniuse.com/#feat=use-strict

Release v1.4.0 to AMO

The purpose of this issue is to track release progress of version 1.4.0.

We did some serious changes since v1.3.1, and it is a good idea to make a checkpoint and deliver this new functionality to all users (>200 according to stats from Mozilla).

I'll try to write missing tests and clean-up code to be ready for Full Review by the end of the week.

Gateway Status and Diagnostics

The menu should include information about currently running local gateway.

For starters, we should display:

• custom gateway hostname and version info from /api/v0/version
• number of connected peers

Next steps:

• go over station projects and add missing functionality to this tasklist
• Improve UX
  • make diagnostics more compact
  • provide visual feedback for enabled/disabled redirect (perhaps reuse on/off icon in some way)
  • Instead of "ON" badge should show how many peers are connected – 2fc5480
    • API Polling (interval configurable via Preferences)
      Gateway should be polled in background and there should be a method that returns its current status – it will enable us to make some optimizations when it is disabled

Feature inspiration:

• https://github.com/ipfs/station
• https://github.com/xicombd/ipfs-chrome-station/

Multiprocess Firefox (e10s)

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running each content tab in a different one. This should improve responsiveness and overall stability, but it also means many add-ons will need to be updated to support this.

We will be talking more about these changes in this blog in the future. For now we recommend you start looking at the available documentation.

– https://blog.mozilla.org/addons/2015/04/08/add-ons-update-63/

Customize 'public' gateway URLs (whitelist)

(Right now only gateway.ipfs.io and ipfs.io are supported.)

An idea from #ipfs:

064413        gendale_ │ cryptix: what part of the addon is scanning for code? I ask because we're building our own network of gateways, and this would be a
                       │ great asset for us
064509        gendale_ │ is it currently only gateway.ipfs.io?
064515          clever │ gendale_: https://github.com/lidel/ipfs-firefox-addon/blob/master/lib/gateways.js
064550          clever │ looks like gateway.ipfs.io and ipfs.io
064811        gendale_ │ interesting. thanks.
064847          clever │ should be simple to extend and send a PR
064907        gendale_ │ it'd be advantageous to be able to have a whitelist feature for multiple gateways   
064911        gendale_ │ yeah. absolutely

Expand range of supported Firefox versions

Basically I need to smoke-test plugin with Firefox ESR and update minimal version number if it works fine.