Schemas in Action

The next step after code execution isolates and schema upgrade strategy is defining exactly how schemas will be installed and how they will run. Here is my first (detailed) take on it:

Artifacts

Schemas at runtime will consist of 4 separate piecies:

• JSON definition file
• Isolate library
• Client side library
• Checksum file

JSON definitions will contain the schema DDL. It will also contain a list of all other schemas (and their versions) that this schema depends on.

The Isolate library is all of the server side logic that is needed by the schema, stripped of all of it's dependencies. The core dependencies will be automatically provided by the AIRport application. The schema dependencies will be downloaded by AIRport application and loaded into the same Isolate. The isloate library will be exposed via a special "internal_index.ts" file that will tie in all of the files required.

Client side library will be a minimal set of runtime artifacts needed to run a client. Presently the only thing that is needed is a small shim (of 3 AIRport libraries, packaged separately to reduce redundancy) and the definition of the tokens used for dependency injection. The rest of the client side library (fronted by the usual "index.ts") will consist of interfaces and won't have any run-time footprint.

Insuring authenticity

Lastly, checksum file will contain a checksum for (in the form of a signature) that will ensure that the combination of the "JSON definition file" and "Isolate library" have not been tampered with and are indeed from the schema publisher.

Installation process

Installation of any given schema will come as a result of a client App making an API call to it.

The client side library will first attempt to invoke the local AIRport App/server. If it's not found (not listening on the specified localhost port) it will prompt the user to either install AIRport App or run the client App in "demo mode" (demo mode will just open another tab with the AIRport server running in window.postmesage mode).

Once the installation handshake completed (and either the AIRport App is running natively on the device or the demo tab is opened) the client App will proceed with the initial API request. The request will contain the schema signature in it (along with schema version, the API object name, method name and call parameters). At that point, AIRport App will:

• Check if the schema is already installed. If it's not it will download the requested version of the schema, verify the signature, and install the schema DDL.
• If the schema is installed it will verify that the requested version of the schema matches the installed one, if not it will download the requested schema version and run the upgrade scripts to get it the the latest version. If the schema has any other schemas it depends on AIRport will check/install those schemas before installing the requested schema.
• Once the schema is installed and all initialization/upgrade scripts have been run AIRport will load the library code into a V8 isolate (either directly in the go code in the native app, or in a separate child iframe).
• With the schema code loaded it will run the client App's request and return the results.

TBD schema lookup

I have more research to do on the process of looking up schemas. It should be done in a way that is agnostic of the underlying storage technology used to accomplish it. An easy solution would be to copy the Arweave GraphQL API and do everything via a number of lookups:

• First lookup the schema by the "signature" tag
• Lookup the specified publisher via their "id" tag (to load their public key).

Of course all of this will need to be implemented. That will have to come later, as I'm now busy with implementing the core framework so stay tuned for next year! :)