This memo is a summary of various conversations we had during Lab Week for Q4 2017, starting with unconf session on Monday.
TL;DR
- Right now, ipfs-companion requires external daemon and just pretends to support
ipfs://
,dweb:
protocols,- we've identified Three Problems that need to be solved to have IPFS running natively in browser extension,
- creation of Programmable Protocol Handler API would solve all of them.
It is possible to run js-ipfs node in extensions background page, but when it comes to major players in browser space we are missing WebExtension API that "enables the extension to satisfy hijacked HTTP request by injecting response read by js-ipfs".
As of now (2017) browser.webRequest
API makes it possible to:
- cancel the request in
onBeforeRequest
,onBeforeSendHeaders
andonAuthRequired
- redirect the request in
onBeforeRequest
,onHeadersReceived
- modify request headers in
onBeforeSendHeaders
- modify response headers in
onHeadersReceived
- supply authentication credentials in
onAuthRequired
What is missing are means of providing response payload instead of redirection
in onBeforeRequest
step of request life cycle.
Web security model relies on Same-origin policy.
This introduces two major inconveniences for websites loaded via IPFS2HTTP gateways (serving content from /ipfs/
and /ipns/
paths):
- every IPFS gateway has different Origin, making it impossible for a user to persist state while switching gateways
- an Origin of a single gateway is shared by all sites loaded from it, making it impossible to write secure web apps
Some people solve this by creating artificial subdomains that have URL-safe CID
in them ($cid.ipfs.dweb.link
). A subdomain provides separate Origin and
creates an isolated security context.
Unfortunately, this is not possible for a gateway running on 127.0.0.1
.
This is a major UX issue.
We should have:
dweb:/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR
instead of:
http://127.0.0.1:8080/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR
Problem #1 might be (partially) solved with:
We could have js-ipfs running inside of a Service Worker acting as a 'proxy' for HTTP requests to the public gateway.
See demo and PoC at IPFS runs as a Service Worker.
- Good:
- service worker can inject responses for a host it was installed from
- if we provide Service Worker for the public gateway, and browser extension redirects everything to public gateway, then we are able to handle all IPFS requests
- transparent for the end user
- Bad
In theory, extending existing browser.webRequest
APIs to support response
generation (e.g. from within onBeforeRequest
hook) would enable us to hijack
requests and respond with data read via js-ipfs.
There is a very low probability that such API change will happen, these APIs were designed this way with certain security constraints in mind.
Even if it would happen, it would not address problems #2 and #3.
What we really need is a new WebExtension API that lets us define a programmable protocol handler.
Such API should enable browser extension to do three things:
-
Respond to
dweb:
requests with actual payload (no redirect to HTTP).To be more specific, WebExtension should be able to provide function that takes a URI and returns
new Response(data, headers)
-
Control how Origin is calculated.
In case of
/ipfs/$cid
, every CID would have its own Origin. -
Display and support use of
dweb:
address in GUI (location bar, bookmarks, etc)This would not only improve user experience but also enable us to use
dweb:
links by default.
The good news is that creation of such API was already proposed in Bug 1271553: Add ability to implement programmable custom protocol handler.
The bad news is that it won't happen this year, as most of the engineering efforts at Mozilla are focused on Firefox Quantum release.
Still, this is the best way to solve our Three Problems.
We should advocate creation of such API, as it would not only enable us to do great things with IPFS browser extension, but could enable Firefox to become an application platform.