Provide API for other browser extensions

[lidel]

Interesting idea for WebExtension ecosystem:

I think extensions working together by providing APIs to each other is a really cool thing. APIs can either be a runtime.onMessageExternal (or onConnectExternal) protocol or a global injected into a website that other extensions and user scripts can interact with to augment functionality.

I’ve started a list with documented APIs (I know of a few more, but no documentation for them, at least yet): https://github.com/freaktechnik/awesome-extension-apis

Quick brain dump:

• In theory, ipfs-companion could provide an API for other extensions
  • additional incentive for installing the add-on
  • decrease complexity of other extensions
• As a PoC we could provide a small sub-set of interface-ipfs-core
  • eg. read-only files.get, swarm.peers etc.
  • think about security considerations
    (eg. should we avoid mutable actions until we have some kind of ACL?)
• Other extensions should be able to use the built-in management API to check if the ipfs-companion is installed, before request is sent, or just implement correct error handling

Potential client extensions

• https://addons.mozilla.org/en-US/firefox/addon/wayback-machine_new/ (https://dweb.archive.org/)
• https://addons.mozilla.org/en-US/firefox/addon/2read/

[olizilla]

This seems at least partially related to #330 in as much as we're talking about how much of the ipfs api we can expose, and how to do so safely.

[lidel]

Indeed, these two efforts will greatly overlap: everything we expose under window.ipfs should also be available to other extensions.

The main difference would be access controls:

• Is a pop-up confirmation dialog enough/correct UI for this use case?
• Should it grant a permanent permission to a specific extension? Does time-based one make any sense in this context?
  • perhaps a one-time global approval per extension would be enough

[lidel]

• Access to ipfs.files should be sandboxed the same way as when accessed via window.ipfs
  • chroot could be created at /dapps/webext/<extension_uuid>/

[travisperson]

This seems like it would be pretty simple to add this to an extension via the Ports. Create a client from ipfs-postmsg-proxy, and passing in custom options to communicate over the port would do it for the most part I believe.

Would need to update getScope to inspect the incoming port and pull out the extension id if it's there for scoping as mentioned above.

Should it grant a permanent permission to a specific extension? Does time-based one make any sense in this context?

I'm unsure of the properties around extensions. However, it would be nice to possibly require that each version of an extension is authorized. There is the management[0] API, which would allow IPFS Companion to inspect installed extensions and retrieve the version string. If the version string is uniquely mapped to a single publication of an extension (required to be incremented on very extension release), then IPFS Companion could issue permissions out and require re-authorization after an update.

The permissions themselves could also then be listed in the extension itself, and not require a dialog or other confirmation. Though it could be provided.

[0] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/management

[whyrusleeping]

cc @kumavis