Run untrusted code from anonymous sources. Instead of sending messages composed of passive data, send programs which can react to their environment. Migrate or duplicate running applications across hosts and computer architectures. Gate is a toolkit which aims to enable such things.
WebAssembly is the interchange format of the user programs. However, the APIs are different from the browsers' usual WebAssembly environments. See low-level C API or the higher-level Rust crate for details.
The sandboxing and containerization features of the Linux kernel provide layers of security in addition to WebAssembly. See Security for details.
Gate services are akin to syscalls, but they work differently. New services can be added easily, and available services are discovered at run time. See Service implementation for details.
Gate appears as Go packages and programs. The execution mechanism is implemented in C and assembly, and needs to be built separately (see below). It's highly Linux-dependent. Currently only x86-64 is supported, but ARM64 support is in development.
Important Go packages:
gate/runtime: Core functionality. Interface to the execution mechanism.
gate/image: Executable building and management.
gate/service: Service implementation support and built-in services.
gate: Command-line client. Uses SSH keys (ed25519) for authentication.
gate-server: Standalone HTTP server with the built-in and plugged-in services.
gate-run: Run your programs locally, with the built-in and plugged-in services.
gate-runtimed: For optionally preconfiguring the execution environment, e.g. as a system service.
See the complete list of Go packages.
While code is data, most of the time data cannot be treated as code for safety reasons. Change that at the Internet level. Data encapsulated in code can describe and transform itself.
Application portability. Migrate processes between mobile devices and servers when circumstances change: user presence, resource availability or demand, continuity etc.
Overhead needs to be low enough so that the system can be practical. Low startup latency for request processing. Low memory overhead for high density of continually running programs.
Work in progress
- Linux x86-64 host support
- Planned security measures have been implemented
- HTTP server for running programs
- Client can communicate with the program it runs on the server
- Programs can discover and communicate with their peers on a server
- Support for WebAssembly version 1
- Speculative execution security issue mitigations
- Pluggable authentication
- Load programs from IPFS
- Reconnect to program instance
- Restore (wag already has support)
- Clone programs locally or remotely (with or without snapshotting)
- Expose program instance at some type of internet endpoint to implement ad-hoc servers
- Mechanism for implementing services in a programmer-friendly way
- Useful resource control policies need more thought (cgroup configuration etc.)
- Stable APIs
- ARM64 host support
- Additional security measures (such as AppArmor/SELinux profiles)
- Android host support
- Non-Linux host support
User program support:
- Low-level C API
- Rust support
- Improved Rust support
- Go support
- Approach for splitting WebAssembly app between browser (UI) and server (state)
The non-Go components can be built with
make. They require:
- gcc or clang
- uidmap (shadow-utils)
- libsystemd-dev, unless CGROUP_BACKEND=none is specified for make
make bin builds the programs using the Go 1.11 module mechanism.
(Individual packages may be buildable with older Go versions.)
Other make targets:
The capabilities targets grant capabilities for the installed container binary (lib). That requires: