Targeted Grant: Native Protocol Handler API for Browser Extensions #30

lidel · 2020-02-28T22:35:56Z

Project Description

Browser extensions are unable to register handlers for URIs such as ipfs://<cid>

This grant aims to create a new API that enables browser extension to register
a native protocol handler capable of returning streaming responses without redirecting to a third party server.

This is wip, needs input from Igalia
cc @autonome

PREVIEW: https://github.com/ipfs/devgrants/blob/master/targeted-grants/protocol-handler-api-for-browser-extensions.md

This is initial devgrant draft, not the final form.

autonome

Looks great, thanks for pointing them in the right direction at the start!

fred-wang

Hi. Thanks for the detailed description. We started to read the documentation and are analyzing things, but here are some quick comments/questions.

fred-wang · 2020-03-24T17:03:59Z

targeted-grants/protocol-handler-api-for-browser-extensions.md

+    - Displays user prompt, asking for confirmation if a handler should be registered
+- Requires unknown protocols names to be prefixed with `web+` ([MDN](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#Permitted_schemes))
+   - Firefox whitelisted `ipfs://` ([bug 1428446](https://bugzilla.mozilla.org/show_bug.cgi?id=1428446))
+   - Chromium requires prefix `web+ipfs://` ([bug 651311](https://bugs.chromium.org/p/chromium/issues/detail?id=651311), [intent-to-implement](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/29sFh4tTdc))


The link to the intent-to-implement seems broken. Are you able to provide the correct link or at least the feature name?

I guess this is https://groups.google.com/a/chromium.org/d/msg/blink-dev/29sFh4tTdcs/K4XroilVBAAJ

Probably a new list item that references to the WHATWG issue should be added here as that's what seems to be blocking the decision: whatwg/html#3998 ; Reading the comments, I don't think anything will be implemented in browsers until Chromium and Mozilla projects reach an agreement on the spec change.

Correct. I'll update the groups link and added whatwg/html#3998 to this section.

We are aware of the stalemate and hope that going browser extension route, discussing a new, generic API could provide incentive to unblock this discussion on the vendor side.

fred-wang · 2020-03-24T17:05:15Z

targeted-grants/protocol-handler-api-for-browser-extensions.md

+
+<!-- What are the acceptance criteria for each milestone and for the final deliverables? These should be as objective as possible. They will be used to determine whether or not a grantee will receive payment for work completed for a milestone.  -->
+
+- API specificiation document is approved by IPFS project


nit: specification

Do we want to standardize this specification? Is there a place where to put WebExtensions API specifications (where does Mozilla put such specifications) ?

I guess we want to add "and discussed with Mozilla and Chromium projects" here? At least it seems important to get the feedback of the project maintainers early if we want to increase the chance to get the API to be accepted upstream.

Yes, we definitely want this API to be created with Mozilla and Chromium being in the loop.
I've added a note to "API proliferation" section.

fred-wang · 2020-03-24T17:11:43Z

targeted-grants/protocol-handler-api-for-browser-extensions.md

+    - reuses HTTP semantics for caching, content type, headers and error codes
+- API implementation in form of patches for Chromium codebase
+    - allows JS running in browser extension context to register `ipfs://` and `ipns://` protocol handlers, process every request made with them and return arbitrary bytes 
+    - released under [PL's Permissive License Stack](https://protocol.ai/blog/announcing-the-permissive-license-stack/)


I would need to read more about this license, but any code that is intended to land in Chromium (or WebKit and Gecko) should be under an open source license and more specifically the license (and sometimes copyright holder) suggested by the corresponding project. For Chromium it's the BSD-like one at https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/LICENSE and copyrighted "The Chromium Authors".

I guess the text of the license might also need to be a under some open license, maybe Mozilla has rules too.

Ack. By default, PL releases everything under both MIT+Apache 2.0 to ease the adoption. This grant includes contribution to a third party project – we can be flexible here. I've updated this point to allow for a license suggested by Chromium project.

targeted-grants/protocol-handler-api-for-browser-extensions.md

fred-wang · 2020-03-25T06:48:38Z

targeted-grants/protocol-handler-api-for-browser-extensions.md

+
+- Works only when executed on matching Origin
+    - User needs to be on `example.com` to registration to work
+    - Displays user prompt, asking for confirmation if a handler should be registered


I guess such a confirmation will probably be asked during the extension installation with a native API? I don't remember exactly how WebExtensions works with this kind of permission.

Install process displays the list of permissions requested by the extension, for example on which URLs it is allowed to run etc. I imagine on the UX side provided protocol schemes could be just another item on that list (eg. ipfs://*).

Yes, that would be my guess too.

targeted-grants/protocol-handler-api-for-browser-extensions.md

fred-wang · 2020-03-25T07:46:31Z

targeted-grants/protocol-handler-api-for-browser-extensions.md

+- API proliferation
+    - can be enabled at a build time by browser vendors such as Brave or Edge
+    - patches submitted to the Brave project
+    - patches submitted to the upstream Chromium / Blink projects


again, this need to be checked (as this is just a WebExtensions API) but new platform features follow https://www.chromium.org/blink/launching-features

Yeah, it was unclear to me if browser extension APIs fall under "web API":

You do not need to use this process if:

Your change does not affect web API behavior to the point that developers need to be aware of it.
[..]

Is there any precedent for an extension API landing in Chromium but only shipping in non-Chrome browser? Might be entering some uncharted water. Hopefully can make it clearer for those following.

In general, I don't believe any new web platform feature are landing in Chromium without being enabled in Chrome. But again, I'm not sure for web extension, I would need to talk to people who are more familiar with that.

fred-wang · 2020-03-25T07:47:50Z

targeted-grants/protocol-handler-api-for-browser-extensions.md

+
+<!-- What are the acceptance criteria for each milestone and for the final deliverables? These should be as objective as possible. They will be used to determine whether or not a grantee will receive payment for work completed for a milestone.  -->
+
+- API specificiation document is approved by IPFS project


I guess we want to add "and discussed with Mozilla and Chromium projects" here? At least it seems important to get the feedback of the project maintainers early if we want to increase the chance to get the API to be accepted upstream.

fred-wang · 2020-03-25T07:50:33Z

targeted-grants/protocol-handler-api-for-browser-extensions.md

+## Resources
+
+<!-- Link any resources that might be helpful for an implementer who is working on this project. -->
+


nit: should numbers + id be used so that the links used above can just point to the corresponding reference in the resources section?

fred-wang · 2020-03-25T08:02:33Z

targeted-grants/protocol-handler-api-for-browser-extensions.md

+
+If possible, the API should be compatible with `manifest.json/protocol_handlers` API already present in Firefox 
+(registering handler on extension install) but with option to omit `uriTemplate` and provide a self-hosted,
+programmatic handler via `chrome.protocol.registerProtocol` instead. 


Do you have a reference link for chrome.protocol.registerProtocol? It does not seem obvious to me what this paragraph is referring to.

I meant future API which does not exist yet. Updated the section to make it clear.

I see. I think this is my main interrogation right now as without further investigation it's a bit difficult to estimate how much work is needed to implement the backend code or if there is anything we can rely on.

@lidel To clarify my interrogation, https://blog.ipfs.io/2019-10-08-ipfs-browsers-update mentions

Chromium OS has a raw sockets API, but it’s disabled in the Chrome browser. Brave has modified their build to whitelist those APIs for IPFS Companion to use - and this gives us superpowers compared to any other browser at this point."

So do you expect we would essentially just enable & expose these ChromiumOS APIs via a new chrome.*.registerProtocol? Or is a more significant effort needed on the backend code?

@fred-wang I know this part is bit confusing, so let me elaborate: chrome.* namespace in Chromium-based browsers is populated by both Browser Extension APIs and Chrome OS/Apps APIs, but in this grant we care only about the browser ones.

Situation looks like this:

chrome apps: https://developer.chrome.com/apps/api_index
Avoid in the long term, as Google deprecated them and will remove support by 2022.

browser extensions: https://developer.chrome.com/extensions/api_index
These APIs were reimplemented by Firefox when they move away from XUL-based extensions. This is where we want to add the new protocol handler API
We would not change any of existing APIs on chrome.*, we would only add a new API to that namespace because that is where other browser extension APIs are)

The new API should enable browser extension to register handler for foo:// and return arbitrary bytes as stream, and if possible, with mandatory/optional content-type (so if content type is stored in IPFS we can avoid mime-type sniffing and provide it with the response).

Examples of streaming "protocol handler API":

https://github.com/mozilla/libdweb#protocol-api

https://www.electronjs.org/docs/api/protocol#protocol

We did not write any specifics about the API as we don't want to be overly prescriptive, but we can add something as a starting point, if you feel it will make it easier to discuss this further.

Thanks for the clarification ! That's how I had understood the Chrome API stuff, my doubt was about the backend effort/size needed for a "generic Protocol Handler API" exactly. I don't think we need the detailed API in the grant description but probably a simple sketch/example of the desired behavior like you commented here is enough, maybe saying it would be similar to the one mentioned in "Firefox Nightly + libdweb" (incidentally I suspect using modern async iterators is probably what we want). From what I get now, we don't need to add complex network stuff in the backend, we can rely on existing JS async generators or similar and the API would be gluing things together ; most of the actual network work will done by the users.

One thing that confused me was that I forgot this is "generic" and not specific to ipfs at all. Perhaps "Project Description" and "Value" sections should be tweaked a bit to highlight that it would allow people to register any (whitelisted) "foo://" protocol, and IPFS ones in particular. I think this is a strong argument to use, for the grant request and for Chromium/Mozilla review.

I'll continue discussion with my colleagues at Igalia and we are going to follow-up privately.

fred-wang · 2020-03-25T08:03:48Z

cc @bkardell

#30 (review) License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

#30 (comment) License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

targeted-grants/protocol-handler-api-for-browser-extensions.md

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

Create protocol-handler-api-for-browser-extensions.md

c26dcb2

This is initial devgrant draft, not the final form.

lidel requested a review from autonome February 28, 2020 22:35

lidel added the type:targeted-grant A grant made directly to a specific recipient label Feb 28, 2020

autonome approved these changes Mar 10, 2020

View reviewed changes

fred-wang reviewed Mar 24, 2020

View reviewed changes

fred-wang reviewed Mar 25, 2020

View reviewed changes

lidel added 6 commits March 30, 2020 15:18

addressing the review

1aa4d81

#30 (review) License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

clarify web+ whitelisting in manifest.json/protocol_handlers

5c98528

#30 (comment) License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

add TOC

6b5e986

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

Prior art: Opera's native ipfs:// URI backed by a Subdomain Gateway

86a8b32

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

Add Milestones 1 and 2 as suggested by Igalia

32bc9a8

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

Clarify Milestones & Funding

9a0b31e

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

lidel marked this pull request as ready for review April 13, 2020 22:48

parkan approved these changes Apr 14, 2020

View reviewed changes

targeted-grants/protocol-handler-api-for-browser-extensions.md Outdated Show resolved Hide resolved

fix: to → for

9f46930

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

parkan merged commit 929a8f3 into master Apr 15, 2020

lidel deleted the protocol-handler-api-for-browser-extensions branch April 16, 2020 17:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Targeted Grant: Native Protocol Handler API for Browser Extensions #30

Targeted Grant: Native Protocol Handler API for Browser Extensions #30

lidel commented Feb 28, 2020 •

edited

Loading

autonome left a comment

fred-wang left a comment

fred-wang Mar 24, 2020

fred-wang Mar 25, 2020

lidel Mar 30, 2020

fred-wang Mar 24, 2020

fred-wang Mar 25, 2020

lidel Mar 30, 2020

fred-wang Mar 24, 2020

lidel Mar 30, 2020

fred-wang Mar 25, 2020

lidel Mar 30, 2020

fred-wang Mar 30, 2020 •

edited

Loading

fred-wang Mar 25, 2020

lidel Mar 30, 2020

autonome Mar 30, 2020

fred-wang Mar 30, 2020

fred-wang Mar 25, 2020

fred-wang Mar 25, 2020

fred-wang Mar 25, 2020

lidel Mar 30, 2020

fred-wang Mar 30, 2020

fred-wang Mar 30, 2020

lidel Apr 1, 2020 •

edited

Loading

fred-wang Apr 2, 2020

fred-wang commented Mar 25, 2020


		<!-- What are the acceptance criteria for each milestone and for the final deliverables? These should be as objective as possible. They will be used to determine whether or not a grantee will receive payment for work completed for a milestone. -->

		- API specificiation document is approved by IPFS project

		## Resources

		<!-- Link any resources that might be helpful for an implementer who is working on this project. -->

Targeted Grant: Native Protocol Handler API for Browser Extensions #30

Targeted Grant: Native Protocol Handler API for Browser Extensions #30

Conversation

lidel commented Feb 28, 2020 • edited Loading

Project Description

autonome left a comment

Choose a reason for hiding this comment

fred-wang left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fred-wang Mar 30, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lidel Apr 1, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fred-wang commented Mar 25, 2020

lidel commented Feb 28, 2020 •

edited

Loading

fred-wang Mar 30, 2020 •

edited

Loading

lidel Apr 1, 2020 •

edited

Loading