Scraping the web for cheap transfer of database content to web pages, I got stuck on the number of products with the name WebDB, many essentially running something like SQLite backed by web local storage…. one of them drives Beaker Browser, a peer-to-peer web browser using DAT built upon Electron. The rabbit hole along my search to find a corporate IT alternative surfaced into a hacker community. So, what are DAT and peer-to-peer browsing?

Share…. FTP or BitTorrent ish

Dat is a peer-to-peer file-sharing protocol that builds a distributed directory to publically readable filesystems. There is a Node command-line implementation to share and clone directories and a NPM package for programatic access. Dat is similar to BitTorrent, but it’s lighter-weight, since Dat clients can choose to download and share portions of filesystems. The requirements are so minimal that Dat can even run from my Chromebook after a minor configuration twiddle and installation of python2, gcc, et al…. via pkg from Termux.

The Dat Project has a tutorial to install Dat and install files. The TLDR; is

• use npm to install dat (repeatedly until you satisfy all the gyp requirements),
• run dat create to share a directory,
• populate the directory with your stuff,
• and run dat clone to access the directory elsewhere.

If you want your files to persist beyond your terminal session, HashBase will host your data, the first 100MB is free. There’s a Dat podcast, DAT;Cast, with Dat enthusiasm and events from January 2018 onward.

Interface…. _Browser_

Dat ships with a web server, just run “dat sync –http“. More generally, running dat-gateway will bridge content to your browser, but now we’re back to server land. Beaker Browser merges a Dat node with a web-browser.

What makes this a happy marriage? Along with providing basic editing tools, Beaker provides Dat to its rendered web applications. Without Beaker, a web app’s I/O is limited to HTTP or Websockets, which require a third-party adaptor (e.g. dat-gateway). I’ve failed at using a couple of Websocket-based approaches, much of the browser support is out of date, so I’d advise starting with Beaker or dat-node.

Sadly, Beaker won’t run on most Chromebooks anytime soon. Beaker is built on Electron, which runs poorly on Google’s high-end PixelBook (only in development mode?), but not on lesser Chromebooks, and the Electron team turns away requests to accommodate Chrome OS. So this next step requires a lap or desktop computer…..

How Dat…. A Sample P2P App

Here’s a simple peer-to-peer application to support consensus: Cahoots! The basic idea is that each voting-bloc member controls and publishes her own ballot containing her opinion, notes, and optionally references to other bloc members she has invited. Each bloc member can traverse the web of references starting from a master or config ballot to listen for ballot updates and count the common opinions.

{ "displayName":
  "issueName":
  "participants": [
    
  ],
  "proposal":
  "notes": [
    [ 1531859696122, "I don't like cold soup"]
  ]
}

Entrance to the election is controlled through the write permission of the config ballot. Other ballots can contain additional invites, but we (each member, even) can choose to limit the entrance by the distance from the config.

Continuing on a tilt from my previous post on developing from a Chromebook, there are still lots of rough edges, even for developing toy projects, primarily stemming from file-system access. A simple rule has kept me out the weeds: for Node.js projects develop only from Android apps using Android app-private storage.

The File System

The Termux documentation partitions storage into three categories: private-app, shared-internal, and external. You won’t see the shared-internal storage from Termux until you run termux-setup-storage.

It appears that under Chrome OS, all Android apps have the same file permissions, which will allow you to edit source files using vim to be read by Node.js, for example. There are, however, lots of operations from Android that fail with shared-internal storage. Creating symbolic links (ln) and updating permissions fail (chmod). Running npm from the shared-internal storage results in lots of errors of the form “Error: EPERM: operation not permitted…”

The default Chrome OS document root used for file selection runs on top of the Storage Access Framework, but the default root only provides access to video, music, and SD-card, not to the private Android emulator storage. Here lies the obstacle between using Chrome apps to build executables for Termux or Crouton.

Editors

Given the rift between Android app-private and shared storage, I find it’s easiest to edit files using Android apps. There are several editors available within a few keystrokes of Termux, e.g. vim, though I wish I knew how to have multiple Termux windows open at once.

A work around to multiple windows is to use another Android app as an editor. Turbo Editor can access Termux private data once you enable the storage-access-framework option under settings. It provides syntax highlighting for HTML and JavaScript files. Under my installation, it periodically pauses, sometimes forgetting to remove the dialog box announcing the pause.

Other Directions

I’ve been scurrying about today looking for alternative methods of editing source code and general file-system access from Chromebooks:

• Use window.webkitRequestFileSystem() Chrome has supported HTML5 file-system operations for several years now. File access is partitioned by the requesting website and stored locally in Chrome private storage.
• Chrome app file storage. Google has discontinued support for Chrome apps outside of Chrome OS. Will they do the same within Chrome OS? chrome.fileSystem is not available to Chrome extensions.
• Chrome storage. Chrome provides a key-value service similar to window.localStorage, except that the data are synced with the user across machines.
• Expose file-operations to a web client. noide is an Node.js application that provides a web interface to edit source files. It has gyp dependencies that are broken from Chrome OS. There are a couple of projects that provide web-client editor widgets, one could leverage to present a front-end for a file server build with Express.
• Use Eclipse Che or Cloud 9, but that’s not really developing on a Chromebook….
• Switch to developer mode and replace Termux with Crouton, which reportedly yields a more faithful Linux experience, including running Electron.
• Drop any notion of keeping local files.

Yesterday I started to collect some notes on setting up React, Typescript, Babel, Webpack, Karma…. Holy cow! How many tools do you need just to get hello-react running? Fortunately, a web search short circuited most of that when the Interweb powers showed me Facebook’s create-react-app script “bundled” with recent versions of npm.

pkg install git    # you have to save your work
pkg install nodejs
npx create-react-app lookout-unicorns
cd lookout-unicorns
npm start

A couple of command-line entries later, node was scanning a directory, transpiling Typescript, running tslint and unit tests, and serving up the results. It was so easy, you must be able to do this on a Chromebook….

There aren’t many steps here. First install Termux, nominally an Android terminal emulator, but green-circle gateway to Linux from Chrome OS. We’ll briefly use its package manager to bootstrap into the npm world.

Now point your browser to http://localhost:3000. Chrome, surprisingly doesn’t recognize the URL, but Firefox for Android running on Chrome OS does.If you want to use Chrome to view your fruits…. Chrome OS assigns the Android emulator a private IP address which you can get from ifconfig in Termux or Crouton. This won’t be the same IP address assigned to your Chromebook by the network, but oddly Chrome OS will expose port 3000 to the world on your Chromebook’s IP address to the rest of the network, just not to its own Chrome browser….