Support chrome.sockets.* APIs #664

lidel · 2019-01-21T10:50:45Z

About APIs

Chromium OS exposes chrome.sockets.* for its apps:

https://developer.chrome.com/apps/manifest/sockets#manifest

We can access those APIs in Brave by adding ipfs-companion (beta+stable) as blessed_extension in brave-core/../_api_features.json (suggested by @bbondy)

See also my notes on bringing IPFS to Brave in 2019: brave/brave-browser#819 (comment)

Potential use

Exposing HTTP Gateway to embedded js-ipfs node
Making js-ipfs basically as useful as go-ipfs for regular user
I imagine we want to detect Brave in js-ipfs/.../config-browser.js#L8
Local Discovery and UDP/TCP Transports
(similar to @alanshaw's libdweb experiments on Firefox)

Relevant libraries

Created for and used in webtorrent:

https://github.com/feross/chrome-net follows Node.js net (TCP) API
https://github.com/feross/chrome-dgram follows Node.js dgram (UDP) API
Use with browserify: webtorrent/package.json#L28-L30

MVP: Exposing HTTP Gateway

Quick notes about first steps:

Create Brave build that exposes chrome.sockets.* APIs to temporary extensions
- Check it it works by default. If not, find Brave build instructions here: https://github.com/brave/brave-browser/wiki and whitelist rules are around brave-core/../_api_features.json
Detect js-ipfs is running in Brave and enable Gateway by providing a valid multiaddr instead of empty string
- config-nodejs.js#L10 vs config-browser.js#L8
Try building ipfs-companion/js-ipfs with chrome-net and chrome-ngram as replacements for Node APIs in browser contexts
Start ipfs-companion in Brave, switch to embedded js-ipfs node
- did it start and open Gateway on TCP port specified in step 2? is HTTP Gateway working as expected?
  - if yes, then we are lucky and this it! :)
  - if not, then we need to write additional code for exposing Gateway over chrome.sockets.*
Continue in Embedded JS-IPFS in Brave (experiment) #716

cc #312

The text was updated successfully, but these errors were encountered:

lidel · 2019-01-25T20:15:06Z

Baby steps :) With some help I was able to confirm APIs are available in ipfs-companion background page after whitelisting extension. Notes below.

How To Develop with Local (Unpacked) Extension (old `master`)

Click to expand

(prerequisite) Created bundle:brave build script that adds sockets section to extension manifest – this is already in this branch
Built (npm run dev-build) and started Brave (npm start). First build takes 4h+, but following ones are faster.
Enabled "Developer mode" and loaded an unpacked extension with , it got assigned ID paanflafljinkomjoheoobkeigpakegp.

Generated ID shortcut in format expected by Brave..

$ echo -n paanflafljinkomjoheoobkeigpakegp | openssl sha1 | tr '[:lower:]' '[:upper:]'
(STDIN)= CEBF34BE446B77F39E2C535566F8C27F9A460B1E

..and added it to whitelists for sockets.* APIs in two files in src/brave (brave-core):

--- a/common/extensions/api/_api_features.json
+++ b/common/extensions/api/_api_features.json
@@ -61,17 +61,17 @@
   "sockets.tcp": {
     "dependencies": ["manifest:sockets"],
     "contexts": ["blessed_extension"],
-    "whitelist": ["3D9518A72EB02667A773B69DBA9E72E0F4A37423"]
+    "whitelist": ["3D9518A72EB02667A773B69DBA9E72E0F4A37423","CEBF34BE446B77F39E2C535566F8C27F9A460B1E"]
   },
   "sockets.tcpServer": {
     "dependencies": ["manifest:sockets"],
     "contexts": ["blessed_extension"],
-    "whitelist": ["3D9518A72EB02667A773B69DBA9E72E0F4A37423"]
+    "whitelist": ["3D9518A72EB02667A773B69DBA9E72E0F4A37423","CEBF34BE446B77F39E2C535566F8C27F9A460B1E"]
   },
   "sockets.udp": {
     "dependencies": ["manifest:sockets"],
     "contexts": ["blessed_extension"],
-    "whitelist": ["3D9518A72EB02667A773B69DBA9E72E0F4A37423"]
+    "whitelist": ["3D9518A72EB02667A773B69DBA9E72E0F4A37423","CEBF34BE446B77F39E2C535566F8C27F9A460B1E"]
   },
   "braveRewards": {
     "channel": "stable",
diff --git a/common/extensions/api/_manifest_features.json b/common/extensions/api/_manifest_features.json
index fcacdb73..db024427 100644
--- a/common/extensions/api/_manifest_features.json
+++ b/common/extensions/api/_manifest_features.json
@@ -6,6 +6,6 @@
   "sockets": {
     "channel": "stable",
     "extension_types": ["extension", "platform_app"],
-    "whitelist": ["3D9518A72EB02667A773B69DBA9E72E0F4A37423"]
+    "whitelist": ["3D9518A72EB02667A773B69DBA9E72E0F4A37423","CEBF34BE446B77F39E2C535566F8C27F9A460B1E"]
   }
 }

Rebuilt Brave via npm run build
Started it via npm start
Loaded extension again, it got the same ID (paanflafljinkomjoheoobkeigpakegp)
Opened Console for Companion's background page via "Inspect views" on chrome://extensions and confirmed chrome.sockets API is present 🎉

How To Develop with Local (Unpacked) Extension (`ipfs` branch of Brave)

Switch extension to feat/brave-build-with-chrome-sockets branch and run npm run build bundle:brave build script to produce extension manifest with sockets section.
Switch Brave to ipfs branch, build (npm run build) and start Brave (npm start). First build takes 4h+, but following ones are faster.
Enabled "Developer mode" and loaded an unpacked extension.
Opened Console for Companion's background page via "Inspect views" on chrome://extensions and confirmed chrome.sockets API is present 🎉

let http = require('http')
let server = http.createServer(function (req, res) {                                                                                                                                                                                        
  res.writeHead(200, { 'Content-Type': 'text/plain' })                                                                                                                                                                                      
  res.end('Hello from ipfs-companion exposing HTTP via chrome.sockets in Brave :-)\n')                                                                                                                                                      
})                                                                                                                                                                                                                                          
server.listen(9091, '127.0.0.1')

start raw http server (http.createServer)
start raw hapi server (Hapi.Server) (screenshot below)
- after some troubleshooting I managed to start raw Hapi server but got internal error for all responses
return valid response from hapi server running in browser extension
- got it to work by replacing url with iso-url during webpack build

Demo: hapi v18 (HTTP server) running in ipfs-companion

TypeError: this._dht.on is not a function comes from libp2p, see Next below

start embedded js-ipfs with Gateway exposed by embedded Hapi server
- right now new Ipfs(..) fails due to TypeError: this._dht.on is not a function, which is quite surprisingly not related to HTTP server (which should just work). It seems libp2p does not disable DHT fully when we polyfill net/dgram using chrome.sockets, which results in TypeError around js-libp2p/src/index.js#L404
start js-ipfs-http-client
- Does not work for now due to TypeError: res.req.getHeaders is not a function – http API mismatch triggered in js-ipfs-http-client/src/utils/send-request.js#L41

drbh · 2019-02-27T14:37:31Z

@lidel great progress! How'd you get the Hapi route response to not throw an error? When I try to get a response from :9092/ I get a 500 and the console says TypeError: Uncaught error: Cannot read property '_replied' of null

Aside from that, what are the next steps for handling the roadblocks you noted above?

If we completely disable DHT - should the embedded js-ipfs Gateway run?

lidel · 2019-02-27T15:27:54Z

@drbh I believe _replied error went away when I switched to new hapi/js-ipfs. Try:

fetching recent updates from feat/brave-build-with-chrome-sockets branch
rebulding Companion via npm run dev-build bundle:brave

As for remaining roadblocks:

this._dht.on is not a function – I tried to disable DHT via config passed to new Ipfs(), but the error remained – not sure why. It is something I will be looking next (need to understand code around js-libp2p/src/index.js#L404 first)
res.req.getHeaders is not a function – this is a low priority (we want to get js-ipfs online first), but my current guess is this will probably require update of http-node (http api shim which is 3 years old)

lidel · 2019-03-13T14:29:43Z

Changes in feat/brave-build-with-chrome-sockets branch:

Synchronized codebase with latest master/v2.7.5.753
After some debugging I managed to fix this._dht.on is not a function by disabling DHT in options.libp2p.config (instead of options.config):

{
  config: {
    Addresses: {
      Swarm: [],
      API: '/ip4/127.0.0.1/tcp/5002',
      Gateway: '/ip4/127.0.0.1/tcp/9090'
    }
  },
  libp2p: {
    config: {
      dht: {
        enabled: false
      }
    }
  }
}

Switched to js-ipfs 0.35.0-rc.0
- Starts fine, but does not start HTTP server with API/Gateway
  This is because HTTP endpoints are initialized only by jsipfs daemon called from command-line.
  - We need to refactor src/cli/commands/daemon.js and make it possible to start it programmatically in browser environment (WIP), but it seems we resolved all polyfill-related blockers for now.

In the past API was exposed via HTTP Server only when jsipfs daemon was run from the commandline, so src/http/index.js was also responsible for orchestration that is not related to HTTP itself. This refactor moves code that is not related to HTTP Servers into standalone-daemon.js, which is easier to reason about, and unlocks use of HttpApi in contexts other than commandline jsipfs daemon, such as Firefox with libdweb or Chromium-based web browser with chrome.sockets APIs. Refs. ipfs/ipfs-companion#664 License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

lidel · 2019-03-19T23:37:07Z

Changes in feat/brave-build-with-chrome-sockets branch:

After some refactoring in ipfs/js-ipfs#1950, pinojs/pino#612 and some ah-hoc polyfills, I am stoked to present..

Embedded js-ipfs with self-hosted HTTP API and Gateway! 🎉

Gateway: dir listing	API: `/api/v0/id`

\o/

Known Issues

If you have an old js-ipfs config without API and Gateway ports, go to Preferences of the extension, scroll to the bottom and click on
Gateway: only directory listing works ATM, fetching raw file data returns some JSON artifacts instead (probably need to tweak some polyfils related to buffers/streams)
"power button" from browser action menu does not stop the js-ipfs, it hangs in "stopping state" (need to look into this)
Switching to "external" ipfs node does not work (but I believe it will be an easy fix)

This changes browser.js to expose symbols and serializer methods used by hapi-pino. This is extremely niche use case, but some people want to run Hapi.js (HTTP server) in WebExtension context using chrome.sockets APIs. Ref. ipfs/ipfs-companion#664

lidel · 2019-04-03T15:19:22Z

Changes in feat/brave-build-with-chrome-sockets branch:

Solved the problem with fetching raw file data

Hapi's stream detection via stream instanceof Stream does not work correctly in browser context, especially when different polyfils are used and mixed together.

I created a patch to detect browserified streams in Chrome App environment, which replaces instanceof check with feature-detection. This enables Hapi to consume stream-like objects, as long they match proper contract.

tl;dr loading data from embedded gateway works:

Fixed streaming of compressed payload

There is a WIP js-ipfs patch to do proper streaming and content-type sniffing. It simplifies code responsible for streaming response and makes the streaming actually work by telling the payload compression stream to flush its content on every read(). IIUC previous version was buffering entire thing in Hapi's compressor memory, so the payload was returned when entire thing was fetched.

Known Issues

If you have an old js-ipfs config without API and Gateway ports, go to Preferences of the extension, scroll to the bottom and click on
"power button" from browser action menu does not stop the js-ipfs, it hangs in "stopping state" (need to look into this)
Switching to "external" ipfs node does not work (but I believe it will be an easy fix)
Uncaught Error: Cannot call write after a stream was destroyed on refreshing already loaded payload
- I confirmed it does not occur when we remove content-type sniffing based on buffer-peek-stream, there is a race-condition around its use
content-type sniffing needs refinement, current version was ported from libdweb experiment
Artifact created by npm run dev-build bundle:generic is not compatible with regular Chrome yet. We need to switch to chrome.sockets feature-detection at runtime, so it can be installed from regular Chrome Store.

Companion UI is now aware of embedded Gateway

Embedded node is now the default if chrome.sockets are present.
Both main menu and onboarding pages use it and all features are enabled:

Implemented feature-detection for `chrome.sockets`

We can now run the same code in Chrome and Brave, and more advanced embedded node will be enabled automatically when Brave runtime is detected.

This work included:

Patched chrome-net: lidel/chrome-net@838ffde

chrome-net did not check if chrome.sockets.* actually exist. This caused problems with extensions built for Chromium-based browsers that tried to maintain the single codebase and do feature-detection at runtime.
Feature detection for embedded js-ipfs:

If chrome.sockets is available, embedded-brave.js will be used instead of regular embedded.js
Refactored initial boot logic on clean install

When extension started for the very first time, the node got restarted multiple times due to config updates/migrations happening in lib/options.js.

I simplified boot process to the point no restarts are triggered by config updates on the first run. JS on landing page is also tweaked to properly receive notification about new peers being available. Tests for relevant code paths are updated.
Added new ipfsNodeType named embedded:chromesockets

For now we do naive check if chrome.sockets.tcp* APIs are available and switch to ipfsNodeType=embedded:chromesockets if true.
User can customize configuration of embedded js-ipfs node via Preferences screen where embedded:chromesockets supersedes regular embedded on Brave:

API and Gateway ports used by extension will follow configuration of embedded js-ipfs.

Made it play nice with go-ipfs and js-ipfs daemons

Switching to External node works again, user can switch between embedded (default in Brave) and external IPFS nodes
Notify user about socket errors:

If port is already taken, a notification "port already in use" is displayed.
We will most likely improve this soon (eg. by finding the next free port) but is good enough for now.
Use custom ports by default

Embedded js-ipfs with chrome.sockets now listens on custom ports, removing the need of changing configuration if someone is already running go-ipfs or js-ipfs.

Web UI works!

Web UI can be opened from Companion's main menu and works as expected:

Sidenote: ipfs-webui connects to embedded js-ipfs over HTTP API, but we could make it work via window.ipfs by blessing Web UI's CID to work over it without scoping/sandboxing.

Known Issues

Key blockers in bold

Content discovery is sometimes extremely slow when preload nodes are under load and slow to respond
We may mitigate this by enabling relay and other existing discovery methods such as webrtc or stardust
This will just go away when we add p2p transport that can interop with go nodes
DNSLink websites (e.g. /ipns/docs.ipfs.io/) are not supported by js-ipfs yet (tracked in Resolving DNSLink Paths: /ipns/<fqdn> js-ipfs#1918)
DNS lookups switched to ipfs.io/api/v0/dns for DNS resolution until DNSLink support lands in js-ipfs and we get better understanding how to operate chrome.sockets.udp* API.
HAMT-shareded directories, eg. /ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/ do not work with js-ipfs (tracked in HTTP Gateway fails to load sharded website js-ipfs#1963)
... in directory listing points at current directory instead of its parent
HTTP Range requests do not seem to be supported by js-ipfs
Broken bandwidth graph in Web UI

In the past API was exposed via HTTP Server only when jsipfs daemon was run from the commandline, so src/http/index.js was also responsible for orchestration that is not related to HTTP itself. This refactor moves code that is not related to HTTP Servers into standalone-daemon.js, which is easier to reason about, and unlocks use of HttpApi in contexts other than commandline jsipfs daemon, such as Firefox with libdweb or Chromium-based web browser with chrome.sockets APIs. Refs. ipfs/ipfs-companion#664 License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

* refactor: decouple HttpApi from cli/commands/daemon In the past API was exposed via HTTP Server only when jsipfs daemon was run from the commandline, so src/http/index.js was also responsible for orchestration that is not related to HTTP itself. This refactor moves code that is not related to HTTP Servers into standalone-daemon.js, which is easier to reason about, and unlocks use of HttpApi in contexts other than commandline jsipfs daemon, such as Firefox with libdweb or Chromium-based web browser with chrome.sockets APIs. Refs. ipfs/ipfs-companion#664 License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org> * fix: print HTTP listeners only when run as daemon This changes behavior in web browser. Instead of printing to console.log, it uses proper debug-based logger. Old behavior in terminal (when run via `jsipfs daemon`) does not change. License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org> * test: use StandaloneDaemon in test/http-api,gateway This replaces durect use of HttpApi with StandaloneDaemon, restoring all existing tests to operational state. License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org> * refactor: rename StandaloneDaemon to Daemon License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

lidel · 2019-04-22T22:23:24Z

Feature-detection for chrome.sockets works as expected, landed in v2.8.1.778 (Beta) 🚀

Remaining work around supercharging Embedded JS-IPFS in Brave 🦁 is tracked in #716

Detection via `stream instanceof Stream` does not work correctly in browser context, especially when different polyfils are used and mixed together. This change replaces instanceof check with feature-detection of stream-like objects. It enables Hapi to be used in Chrome Apps (browser environments with additional chrome.sockets APIs) Real life example: ipfs/ipfs-companion#664

lidel mentioned this issue Jan 25, 2019

Whitelisting access to chrome.sockets API for local dev with unpacked extension brave/brave-browser#3102

Closed

lidel mentioned this issue Feb 13, 2019

Act as HTTP PROXY for http://<cidv1b32>.ipfs.localhost ipfs/js-ipfs#1877

Closed

lidel self-assigned this Feb 27, 2019

lidel added status/in-progress In progress and removed status/ready Ready to be worked labels Feb 27, 2019

lidel mentioned this issue Mar 18, 2019

Allow IPFS Companion Beta to have chrome.sockets.* brave/brave-core#1988

Merged

This was referenced Mar 19, 2019

Add pino-browser support for hapi-pino pinojs/pino#612

Merged

Decouple HTTP Servers from cli/commands/daemon ipfs/js-ipfs#1950

Merged

lidel added P1 High: Likely tackled by core team if no one steps up and removed exp/intermediate Prior experience is likely helpful help wanted Seeking public contribution on this issue labels Mar 19, 2019

lidel pinned this issue Mar 19, 2019

This was referenced Mar 22, 2019

Redirect of CID-in-subdomain and DNSLink websites #667

Closed

Improve onboarding on Firefox for Android #690

Open

This was referenced Apr 16, 2019

Feature-detection of chrome.sockets #711

Merged

feat: unlimited storage for embedded js-ipfs #714

Merged

WIP: IPFS extension brave/brave-core#425

Closed

Embedded JS-IPFS in Brave (experiment) #716

Closed

lidel unpinned this issue Apr 22, 2019

lidel closed this as completed Apr 22, 2019

ghost removed the status/in-progress In progress label Apr 22, 2019

lidel added the area/brave Issues related to Brave Browser label Apr 23, 2019

This was referenced Apr 26, 2019

Improved feature-detection of chrome.sockets feross/chrome-net#36

Merged

Improve browser support hapijs/hapi-pino#76

Merged

lidel mentioned this issue Apr 26, 2019

Add support for Chrome Apps and WebExtensions hapijs/hapi#3946

Merged

lidel mentioned this issue May 26, 2019

IPFS Integration - Roadmap and discussion brave/brave-browser#819

Closed

lidel mentioned this issue Jul 12, 2019

Request flood in web browser libp2p/js-libp2p-delegated-content-routing#12

Closed

lidel mentioned this issue Sep 8, 2019

fix: feature detection for Google Chrome feross/chrome-dgram#16

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support chrome.sockets.* APIs #664

Support chrome.sockets.* APIs #664

lidel commented Jan 21, 2019 •

edited

Loading

lidel commented Jan 25, 2019 •

edited

Loading

lidel commented Jan 28, 2019

lidel commented Feb 27, 2019 •

edited

Loading

Demo: hapi v18 (HTTP server) running in ipfs-companion

drbh commented Feb 27, 2019

lidel commented Feb 27, 2019

lidel commented Mar 13, 2019 •

edited

Loading

lidel commented Mar 19, 2019

lidel commented Apr 3, 2019 •

edited

Loading

lidel commented Apr 10, 2019 •

edited

Loading

lidel commented Apr 22, 2019 •

edited

Loading

Support chrome.sockets.* APIs #664

Support chrome.sockets.* APIs #664

Comments

lidel commented Jan 21, 2019 • edited Loading

About APIs

Potential use

Relevant libraries

MVP: Exposing HTTP Gateway

lidel commented Jan 25, 2019 • edited Loading

How To Develop with Local (Unpacked) Extension (old master)

How To Develop with Local (Unpacked) Extension (ipfs branch of Brave)

Next

lidel commented Jan 28, 2019

Next

lidel commented Feb 27, 2019 • edited Loading

Demo: hapi v18 (HTTP server) running in ipfs-companion

Next

drbh commented Feb 27, 2019

lidel commented Feb 27, 2019

lidel commented Mar 13, 2019 • edited Loading

lidel commented Mar 19, 2019

Embedded js-ipfs with self-hosted HTTP API and Gateway! 🎉

Known Issues

lidel commented Apr 3, 2019 • edited Loading

Solved the problem with fetching raw file data

Fixed streaming of compressed payload

Known Issues

Next

lidel commented Apr 10, 2019 • edited Loading

Companion UI is now aware of embedded Gateway

Implemented feature-detection for chrome.sockets

Made it play nice with go-ipfs and js-ipfs daemons

Web UI works!

Known Issues

Next

lidel commented Apr 22, 2019 • edited Loading

lidel commented Jan 21, 2019 •

edited

Loading

lidel commented Jan 25, 2019 •

edited

Loading

How To Develop with Local (Unpacked) Extension (old `master`)

How To Develop with Local (Unpacked) Extension (`ipfs` branch of Brave)

lidel commented Feb 27, 2019 •

edited

Loading

lidel commented Mar 13, 2019 •

edited

Loading

lidel commented Apr 3, 2019 •

edited

Loading

lidel commented Apr 10, 2019 •

edited

Loading

Implemented feature-detection for `chrome.sockets`

lidel commented Apr 22, 2019 •

edited

Loading