Earlier this week I spent a morning listening to Ron Evan’sintroduction to computer vision with Go course through Safari. Following my belief that every course should should have at least one project, I hacked up an application to deface images and webcam streams with hats: Lotsohats.
The course walked through several GoCV example applications to apply filters to images and use deep-learning packages with pre-trained models for image classification. To me, it seemed like an obvious easy assignment was mimic a certain alcohol-advertising crowd-cam app used at the local hockey arena and drop hats on people in images.
It was my first experience with Go, but the proof of concept took a morning to hack something together, learning Go unit testing and exploring the GoCV and Standard Go Library APIs along the way, and this morning was spent polishing, tweaking, and documenting. The Donovan and Kernighan Go book is also a good resource.
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.
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.
