The SuperTXT team, like others out there, is super excited about the possibilities of WebAssembly technology. Of particular interest is using this technology to advance internet usability outside of The Web, based on our values.
Our default settings are:
The world has changed alot since Unix was first invented. There are limits, both perceived and real, that led to the development of the modern Web. People expect to be able to trust that untrusted programs can run on their computer for the purpose of cursory reading/browsing, and even interactive experiences. This is far different than the original Unix concept where you implicitly trusted every program you run because you either compiled it yourself or your system administrator and OS vendor made the assurances that software wouldn't be malicious. You were protected from others computers and users, but that's about it. Web browsers offered much better protections at the cost of significant complexity.
There is also the multi-platform problem. Not everyone uses the same Unix (e.g. macOS and Linux). Many people use non-Unix (i.e. Windows). Programming languages filled the void by offering either cross-compilation, or interpretation. Neither is particularly appealing when you want to run a low trust program quickly. Also, there is a variety of package management tools, some OS integrated, others more aligned with programming language. The OS integrated, if available, often prefer stability over leading edge. There's a third category of language independent package managers, such as Homebrew, but they are largely fractured along different approaches. At the moment the SuperTXT stack tends to recommend Homebrew.
For now, when you use SuperTXT, you're generally operating within the existing Unix paradigm. The Browsing Shell (brsh) is modeled after other Unix shells in a true graphical interface. That graphical interface emphasizes the text, but offers gentle usability improvements, such as indentation, different font sizes, and navigation features. Also, there's the option for the user to fall back to a legacy Unix shell at the user's preference, preserving much of the usability. You'll notice that the browsing shell offers some acceleration for running commands, and navigating links, but it must ultimately give the user the opportunity to see what they're about to run before running the command. That's because what they are reading can be malicious even though the page itself has no executation semantics beyond the programs that the user has decided to trust by installing them on their computer. The "rm" command is not malicious on its own, but the following command if run automatically on the user's behalf can cause alot of damage.
# rm -rf "$HOME" # PLEASE DON'T RUN THIS!!
Meanwhile, the sandbox problem has been solved by some post-Unix systems, like BSD, and Plan9 through either jails, or namespaces. These are tightly integrated into those systems so that users can easily customize the environment in which a program runs based on the level of trust. We want to gain some of these features, but in a way that still works with the current landscape. This is where WebAsembly fits in.
WebAssembly offers us a way to run untrusted programs that are precompiled for performance and simple distribution in a sandbox. So that there are extremely limited ways that such a program could escalate its privilege beyond what the user expects. This is accomplished via the WebAssembly System Interface [:@WASI] that provides the interface that most programs might expect, such as a filesystem, standard I/O (i.e. stdin/stdout/stderr).
There are WebAssembly runtimes that are capable of running WASI programs. Most of them start with a very limited default settings. The filesystem is usually empty and the standard low-level networking system calls generally return errors.
So, there's not much that the WASI program can do other than consume some memory, CPU cycles, print things to stdout (and stderr), or read what you type into it. WebAssembly runtimes often allow you to "mount" certain directories of your choice from the host so that the program can be granted access. You can often choose where in the filesystem tree the program sees your directory too, which can make the path names shorter and more ergnomic for command-line parameters. Also, choosing different guest paths can leverage certain conventions, such as putting all the binaries in "/bin", the temporary files in "/tmp", and so on indepedent of where they might be located on the host. This is alot like how Plan 9 namespaces work.
It turns out that you can compile and run a large variety of programs using WASI. It's done using various approaches like the [:@WASI SDK] for C/C++ programs. Go has [:@built-in toolchain support] for WASI so that you can compile many programs using that language too. There are many others too. It turns out that WASI is a very good subset for things that programs need to do without knowing that the filesystem they access has been virtualized into a namespace from different places on the host.
As long as a WASI program is capable of accessing the filesystem it is given it is then capable of whatever that filesystem can provide. Before the time of Unix files were often just the ones stored in some kind of storage, like a hard disk. After Unix was release it popularized the idea that "everything is a file" including system devices, from the bit bucket (/dev/null) to hardware devices like the hard disk itself. Plan 9 took that a step further to include the display device too so that modern (for the time) graphics can be drawn on the screen by a program reading and writing to the "/dev/draw" file, and also "/dev/mouse" for the mouse. If those files aren't present then the program can either fail or attempt to run in a non-graphical mode.
It turns out that file names and paths can act as a convention that a variety of programs can use to detect whether certain capabilities exist. If the capability exists then a protocol can be established between the client and the server. This applies not only to graphical modes, but all kinds of other sorts of capabilities too. Basically, anything that can be modeled as a file can work in this way. Plan 9 went really far with this using the 9P protocol to multiplex different file servers together into namespaces.
If WebAssembly runtime can support 9P as a protocol then this versatility can be brought to the world of WASI too, and a large body of potential programs. This can be done without any special API's or system calls in WASI since it already has a filesystem. The runtime provides the filesystem and the programs have the ability to access it. This is where the wanine proof of concept is born.
Wanine brings 9P together with WASI to promote versatile integrations between host and guest with some safety. The default state is that a file server isn't shared with the guest since it isn't mounted. If a file server is mounted, there can be a convention of where that server presents its interface in the filesystem, and the guest can use file access to speak the protocol of the server. Wanine is a WebAssembly runtime that can provide its own servers for basic services, but it can also mount other sorts of external file services using 9P too. There's a ton of flexibility there available today and more in the future.
If you want to run a program from an internet site, Wanine can run it over SSH along with its security guarantees and authentication, but also the built-in sandboxing.
wanine run supertxt.net:bin/ls --help
While the interactive defaults to text-only, which is one of the values of SuperTXT, file servers can create all sorts of new interaction possibilities, including rich graphics. Check out the [:@wanine readme] to get started.
Most host OSes don't provide a graphics interface file that you can mount for the WASI program to use. Something would need to provide one. One candidate is the Plan 9 draw server. It has been ported to a variety of platforms. However, the protocol is dated, and the program either needs to be installed/invoked separately to handle requests, or it needs to be linked in using C FFI. It just isn't ideal. A new protocol is needed.
We are happy to announce an **experimental** new protocol called [:@shiny-wire]. The Wanine program will provide a server for this protocol, which is enabled by the user, and WASI programs can detect and use it to draw rich graphics. If you are writing your programs in Go, the library associated with the protocol can help you to write your graphics routines. It's based on the Go [:@shiny] library.
Wanine is just the first small step in the direction that we want to head with the SuperTXT stack. The browsing shell, cats and SSHLA applications are great for cases where either trust level is high enough to install them on your computer, or internet services are able to provide their experience within the tools that you already trust. The hope is that wanine and WebAssembly will handle other cases such as ones where the trust level for a particular internet site is lower, and yet has a site-specific experience that can't be met with standardized applications. Now that you can run site-specific applications in both text and with experimental graphics support we are excited to discover the possibilities.
If you want to get started check out the [:@wanine readme] to see how to install it and try the examples for yourself.