What Is Orbital?

Orbital is an 'application sandbox' that lets users create & share 'persistent internet applications'.

Design goals include:

1. providing a industrial strength, portable, safe compute environment for heterogenous apps written by different parties

2. a 'scenario definition language' to describe applications in terms of their intended requirements at a high level, dependencies, security permissions needed, lifetime and cpu expectations

3. to be able to act as a glue service for third party libraries such as machine learning algorithms, cloud computing resources, visualization and rendering tools

4. to be able to run on embedded hardware and also in the cloud as a persistent durable resource; and to somewhat deprecate the idea of computation being pinned to a given device

5. riffing on ideas around agent based models for large scale simulations and metaverse style projects with persistent actors (see https://en.wikipedia.org/wiki/Agent-based_model )... in effect getting away from the model of consumers explicitly loading and unloading apps and instead treating apps more like persistent agents

Why Make Orbital?

We see a future of user created persistent apps that work together. Today these issues are blockers:

1. platform specific -> applications (other than web apps) seem overly tied to implementation and hardware - for example an app and its dependencies can be described using npm modules, or rust crates, or a c makefile, and then associated code in a grammar such as javascript, rust or even c... but most of what an app does is simply talk to a big pile of libraries, which are largely standardized - and the actual glue logic or scripting is often less critical; but the idea of the app cannot be hoisted out of the specific toolchain...

2. poor scenario definitions -> applications don't seem to have very formal ways of describing permissions, this makes it very hard to run an app over the wire... rust/wasm are making great strides here of course

3. needless complexity -> it's difficult for novices to use the current grammars required to define rich apps - it should be possible to define an app leveraging third party libs and a bit of scripting glue - and this should be about as difficult as defining a static website in html

4. lack of persistence -> what's also missing is a way for the average consumer to describe an application or even just a single-purpose agent at a high level and publish that service to a persistent and durable network environment where that service can keep running and interacting with other agents. Most models of computation today for consumers have a concept of "downloading" and "installing" and then "running while being observed" and then "exiting". There just doesn't seem to be a way for consumers to think about software agents that can easily run durably in the background until stopped.