Browser Plugin/Extensions

[Viv Rajkumar]

Hey Guys,

Please note this topic is a work in progress and doesn't in any way affect the C++ side of timelines for launch

As many of you might know, we've had a few discussions on https://www.maidsafe.org/ and the mailing list about creating a browser plugin/extension to allow access to the SAFE network. We recently(Friday) got a chance to chat with Andre about the same and explore a few possibilities to create such a plugin for Firefox.

I'll list the main points Andre mentioned and hopefully keep this thread updated with progress.

Objective: 

Allow Firefox browser(other browsers...eventually) to be able to access data from the SAFE network. This includes Interpreting a custom url schema from the browser(either from the url entered by the user or from html) and if matched with a SAFE network schema, get the corresponding data from the network and pass it back to the browser.

Given: (In Firefox)

Extensions - JS Only

Plugins - Can use native code(C/C++,..)

Limitation:

Plugins cannot use udp(possibly any network comms).

Plugins cannot access the filesystem directly.

Extensions can tackle both the above limitations, however extensions have to be in JS. As for filesystem access, Andre mentioned firefox extensions use a local database to mock/simulate a filesystem provided the user has allowed it from his preferences. UDP connections can be mapped directly from JS. UDP available from JS, if it can do everything RUDP lib can do from C++ is something that needs to be looked into.

Approach 1: Hybrid Extension with Plugin

Have an extension<->plugin bundle wherein the extension handles the plugin's limitations and the plugin does the rest of the work. This possibly means having to strip out the RUDP library / tweak it in place so any network requests can be sent from the plugin to the JS extension. Same applies for any library dealing directly with the local filesystem.

We've been told that the JS extension layer to handle the UDP/filsystem operations wouldn't be a significant task. Getting the C++ libs to be able to interface with the extension to perform these operations is a question that needs to be looked into.

How CRUX ties into this would also be interesting to find out. Having an API at these layers from C++ to be able to plug the extension into would be ideal to achieve this requirement.

Approach 2:  Extension alone

This approach was to compile the current C++ code into something like asm.js. Maybe use https://github.com/kripken/emscripten . If(not sure) this allows the code to be ported directly to JS, then the entire code set could possibly reside as an extension in Firefox. Might definitely be worth to check into this approach to scope out if it's feasible or applicable here.

Sidenote: WebRTC

One other point that was raised was to switch UDP network comms maybe even for browsers to WebRTC. If the C++ code can work with either WebRTC/UDP then it makes it that much easier for web integrations considering WebRTC already is handling what RUDP might need.

This is something Eric has been working on(his scope is to implement every lib in JS, but it does involve using WebRTC), so hopefully his experience into this section should help. 

To summarise, Andre's idea with this is to expose the SAFE network to browsers as another mode of storage similar to local/remote -> "peer-storage". Please do let us know what you think of such a plugin and any pointers(pro/con) into the approaches if you're familiar with them.

[bol...@gmail.com]

Allow Firefox browser(other browsers...eventually) to be able to access data from the SAFE network.

-> My objective is to implement both client and server parts of MaidSafe as an extension to FF. That's why I mentioned IndexDB or LocalStorage as an alternative to accessing the file system (which is forbidden from both native plugins and JS extensions). IndexDB or LocalStorage are both standard JS APIs that exist in both FF and Chrome.

Andre mentioned firefox extensions use a local database to mock/simulate a filesystem provided the user has allowed it from his preferences.

-> More exactly it's about IndexDB or LocalStorage, and they are key/value storage. Capacity is limited by design to 4MB I believe, unless user gives special permissions.

UDP available from JS, if it can do everything RUDP lib can do from C++ is something that needs to be looked into.

-> UDP can't do what RUDP does. RUDP uses UDP underneath. So one solution is to keep the C++ code that makes RUDP, but have the underlying UDP calls abstracted through IPC calls to the JS extension which can make UDP (native code runs into a sandbox that doesn't allow network access).
-> Another solution is that RUDP could be replaced by WebRTC as both are intended at NAT traversal (but maybe RUDP does more than that). In that case skip RUDP code and abstract calls to it to calls to WebRTC (through IPC calls to the JS extension again).

[Vijayee Kulkaa]

So it occurred to me that with all the limitations that maybe hacking the browser to work better with the safe network might be an option. Breach (http://breach.cc/) is a module based node version of chromium that lends itself to this level of hacking. Since it is in javascript it should be pretty easy to edit and C++ bindings for node could be created for the existing safe network code with SWIG.

[Viv Rajkumar]

Hey Vijayee,

Welcome to the mailing list.

We actually have the MaidSafe-Ports setup for nodejs. https://github.com/maidsafe/MaidSafe-Ports/tree/master/src/nodejs Scope is currently limited to ms-rudp lib until we cover the rest of the languages.

The Breach browser seems interesting(will have a look into it), however I'm certainly interested in also integrating to existing "large" browsers as well than focussing exclusively for a mod-able one. I'm very much on the side of saying "if you ask users to let go of their already familiar browsers just for the SAFE network/any extra feature, you're not gonna hit as large a target group as otherwise just cos it hinders their current UX"

I think the limitations that firefox/chrome exposes for plugins(sandboxing) have a worthy reasoning and from initial discussion with Andre they provide you the tools to be able to do what we need albeit with a lil more effort. Think the sweet spot here might very well be that our goal to expose the network on browsers such as Firefox end up supporting mod-able browsers in the same path(maybe sooner than the target browsers). 

[Vijayee Kulkaa]

I agree leveraging the existing browser is much more ideal for adoption. I could tackle working on a chrome extension. I don't have the familiarity yet with the repo yet. I don't know what to do with the built code but it is building. You have now given me some insight into its node code.

[krishn...@maidsafe.net]

We have created an initial POC and thus sharing the approach what we took,

Extension:

Available approaches to build an Extension,

1. Add-on SDK

2. Restartless

3. XUL Overlay

XUL is deprecated and Add-On SDK is the suggested approach from Firefox. Thus, we decided to use the Add-on SDK to build the extension.

Interception of the SAFE: schema can be handled by the extension. Once the schema  is intercepted, the data must be retrieved from the network and passed back.

For intercepting the SCHEMA, we had to implement a Custom Protocol Handler, through this we could be able to stream the contents back to the caller.

In the custom handler, we created a Channel using nsIPipe (To handle the I/O stream between the caller and the network).

We did emulate to this by writing a byte array through the channel stream, whenever a SAFE: schema is intercepted from the address bar of the browser and also from the DOM.

Plugin:

Available approaches for building plugins for interacting with native code,

1. NPAPI

2. XPCOM

3. JS-Ctypes

4. emscripten

NPAPI seems to not be available Cross Browser since Chrome currently does not support it. Moreover it also has restrictions with network operations and file system access. XPCOM is being used by Firefox, but again there is an uncertainty hanging around it, that Firefox might not support custom made XPCOM binaries some time soon.

Emscripten seemed to be promising. But porting can become more complicated, considering all the dependencies with MAIDSafe.

Thus we decided to try out our initial POC with JS-Ctypes.

Created a layer with JS-ctypes which provides a bridge between Javascript and the native code. Using the ctypes API from the extension, the native code is invoked. JS-ctypes supports only C, thus, we are accessing the C++ functions through a C wrapper. To have a completely isolated non-blocking operation, we also used ChromeWorker (Similar to WebWorker).

We have tested the MAIDSafe port sample with the extension so far :) scope is currently limited to MaidSafe-RUDP from the MaidSafe-Port layer

Github Repository:

https://github.com/shankar2105/CustomProtocolHandlerSample_Firefox