Re: OverbiteNX

[Ciprian Dorin Craciun <ciprian.craciun@gmail.com>]

On Sun, Jan 21, 2018 at 9:31 AM, Cameron Kaiser <spectre@floodgap.com> wrote:
> However, WebExtensions on both Firefox and Chrome does provide for a native
> messaging connection to an existing client. This would require installing
> an executable (probably a Perl script, at least on macOS and Linux/*BSD),
> but would also mean I could get around the entire problem.
>
> [...]
>
> Before I embark on this, do people object to this method? The script would
> be open-sourced so you can install it yourself and examine the code rather
> than simply trusting an installer.




I had to "jump" through this hoops (as a user) for the OpenWith
Firefox extension, and these are my thoughts:

* as a "more security conscientious" user I didn't want to just
"download this script, run it, and hope nothing goes wrong"...  thus I
had to peek inside the script to see exactly what it does and install
it myself;  (basically it involves creating a JSON file, but it took
me more to find that out than to create the file...)  thus first tip:
provide the exact steps needed to install it for the "paranoid", in
addition for the automatic install procedure;

* perhaps it would be best to document the protocol your extension
uses to talk with the "native process", which most likely is JSON
based;  this way one can simply provide an alternative implementation;

* if going the Python / Perl / Ruby / "other interpreted language"
way, then it would be nice if it didn't require any external library
(except the interpreter itself, and hopefully that language is already
installed on may distributions);  if this isn't the case it would be
nice to have a documented way on how to prepare a "virtual
environment" so that one doesn't need to juggle RPM / DEB files;  (on
a second thought one could just use NodeJS and the whole "run-time"
needed is the `node` executable, even on Windows;)

* perhaps, given how simple the Gopher protocol is, one could just
implement the whole "native process" in Go / Rust, thus it will not
require any extra libraries;  (I excluded C because Go / Rust are more
"portable", thus easily compilable on OSX / Windows;)




Now on a different matter:  what other opportunities would this
"native process" open?

For starters I think the main appeal of Gopher is that it "simplifies
and cleans the Internet", i.e. no jumping adds, no million ways to
create and navigate a menu, etc.  Instead it brings order: menus with
clear semantic, a search functionality, and the rest are documents.

Thus how about this:  instead of the "native process" being just a
dumb TCP socket proxy, why don't we transform it into the "Gopher
protocol backend" by doing the following:

* specifying in JSON a format for describing the Gopher menus (and
related) -- it shouldn't be hard as I bet inside the extension there
is already such a structure;  (this also cleans and enables things
such as headers, etc., which today are twisted and clobbered
selectors;)

* the extension knows only about the Gopher "semantic" (i.e. menus,
searches and documents), but nothing about the Gopher "syntax" (i.e.
actual network protocol);

* the native extension knows how to translate between the Gopher
semantic and the network protocol;


So what does all this enables?  By replacing the "native process" with
a different one --- that keeps the Gopher "semantic" --- one can
provide alternative Gopher protocol implementations;  Gopher proxies
to other non-Gopher-native services without requiring one to run a
gopher proxy;  and other experimental things;

Concrete example:  I remember some time ago some discussions about
Gopher over TLS.  This would be easily achievable by changing the
"native process" without touching the extension itself.




And an additional idea:  how about the Gopher extension starts using
actual URL's in its menus instead of two separate host and port
fields?  (This would enable easily implementing "virtual" Gopher
servers, by intercepting these URL's within the native process.)

How about it doesn't "choose" the content type of a resource
beforehand based on what someone wrote in the menu selector, but
instead uses that as a hint for icon purposes, but when the response
comes in, it actually "finds-out" (via a `Content-Type` marker in the
"native process" protocol) about the actual resource type.

This would allow the owner of the Gopher resource to change its type
(for example from TXT to HTML) without breaking all selectors pointing
to that resource.




I hope this opportunity isn't missed by the Gopher community to evolve
the Gopher universe farther than it's 1990 technical limitations
allowed --- keeping its semantic roots (simplicity and cleanness), but
upgrading its antiquated technical-related aspects to 2018 (the
protocol and all accumulated quirks)!

I say this, because so far any evolution was "terminated" mainly by
the "all Gopher browsers would have to be changed and upgraded, thus
this change is breaking the Gopherspace";  well today the main "Gopher
browser" is already broken...

Hope it helps,
Ciprian.