js-ipfs bundled into browser extensions

[jbenet]

Bunch of thoughts are elsewhere, but here to track this specific effort.

Now that https://github.com/ipfs/js-ipfs is ready, we can bundle it directly into browser extensions to provide an IPFS node resolving things directly from the browser. This is different than just in a tab; it's a less expensive version where connections are shared, but does require users installing the extension.

[jbenet]

i did some poking around js-ipfs chrome extension.

i found https://github.com/rynomad/protochrome which is a good hack. the idea is to use chrome's "web protocol handlers" https://developers.google.com/web/updates/2011/06/Registering-a-custom-protocol-handler?hl=en which redirects a protocol of the form web+<scheme>: to a webpage that can handle it. This codebase runs a chrome packaged app to run an http server that we can register as the handler, locally. The unfortunate part is that web+fs:/ipfs/Qmfoo turns into something localhost:5000/?web+fs:/ipfs/Qmfoo and it shows up on the address. AFAIK there's no way to avoid this, which is very annoying.

Another option i considered was to use https://developer.chrome.com/apps/manifest/url_handlers -- but these seem only to work with http? maybe i'm wrong.

Firefox is different, firefox allows custom protocols. @lidel — of https://github.com/lidel/ipfs-firefox-addon fame — probably knows exactly where to add js-ipfs. I think that's the way to go.

@diasdavid @dignifiedquire maybe ask @lidel where to add js-ipfs based resolution to the firefox extension, so that users can browse fs:/ipfs/.... natively.

[jbenet]

There's this for firefox addons. looks old but may work https://github.com/Gozala/jetpack-protocol

Do we know what are the easiest and best ways to add protocols to Firefox is now?

cc @Gozala

[lidel]

Regarding Firefox Addons:

The jetpack-protocol can't be used: it relies on things like direct access to XPCOM.
Mozilla decided to deprecate it along with XUL. The state of Firefox Addon ecosystem is a little bit demotivating right now.

The only future-proof API/SDK for writing Firefox Addon "today" is WebExtensions (WE). There will be a grace period when old SDK is still supported, but all addons using XPCOM (inluding ipfs-firefox-addon) will have to be migrated to WE, eventually.

I created a plan for moving to WE some time ago: ipfs/ipfs-companion#20, but no actual work has been done yet. Still waiting for WE to provide similar functionality as the old SDK (checked few moths ago: I was unable to find any info about custom protocols nor socket API in WebExtensions API).

tl;dr most of my Firefox SDK know-how is outdated and I did not learn WebExtensions yet, sorry :/

@jbenet if you want solid feedback on this, the add-ons/development at mozilla-community.org seems to be the best place to ask about current state of custom protocol support in WebExtensions.

[qxotk]

I am a bit out of my league here, but I am wondering if
http://offlinefirst.org/ might be an overlapping set of concerns. It seems
they use webworkers to manage a browser ux around times of connectivity.
Perhaps an offline approach could connect to local #ipfs which would manage
on and offline connectivity to #ipfs resources.

---

james mcfarland
james@jamesmcfarland.com
www.jamesmcfarland.com
On Jun 4, 2016 8:58 AM, "Marcin Rataj" notifications@github.com wrote:

Regarding Firefox Addons:

The jetpack-protocol https://github.com/Gozala/jetpack-protocol can't
be used: it relies on things like direct access to XPCOM
https://github.com/Gozala/jetpack-protocol/blob/master/xpcom.js.
Mozilla decided to deprecate it along with XUL
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/.
The state of Firefox Addon ecosystem is a little bit demotivating right
now.

The only future-proof API/SDK for writing Firefox Addon "today" is
WebExtensions http://arewewebextensionsyet.com/ (WE). There will be a
grace period when old SDK is still supported, but all addons using XPCOM
(inluding ipfs-firefox-addon https://github.com/lidel/ipfs-firefox-addon)
will have to be migrated to WE, eventually.

I created a plan for moving to WE some time ago:
ipfs/ipfs-companion#20
ipfs/ipfs-companion#20, but no actual
work has been done yet. Still waiting for WE to provide similar
functionality as the old SDK (checked few moths ago: I was unable to find
any info about custom protocols in WebExtensions API
http://arewewebextensionsyet.com/).

tl;dr most of my Firefox SDK know-how is outdated and I did not learn
WebExtensions yet, sorry :/

@jbenet https://github.com/jbenet if you want solid feedback on this,
the add-ons/development at mozilla-community.org
https://discourse.mozilla-community.org/c/add-ons/development seems to
be the best place to ask about current state of custom protocol support in
WebExtensions.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#132 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABzw8cfDFdDNDdN-1eU-XFvZ23LltLCwks5qIXZngaJpZM4IuFk3
.

[jbenet]

i think this happened

[lidel]

Yes, you can opt-in and play with js-ipfs embedded in ipfs-companion:

IPFS Node Type selection on Preferences screen

Keep in mind that js-ipfs in browser context comes with some limitations, some of them will be addressed in Q3.
More details: https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/node-types.md

[daviddias]

@lidel you should share a big update here :)