ZTOS API

Introduction

DUC

The ZTOS API provides the functionality such that owners of data can specify what actions can be taken upon their data by what user users and under what conditions. This is called DUC, which is short for Data, User, and Code. The data can have settings that specify what users and code can act upon that data. Code is the software that does the action that the user wants to perform on the data. We call this Action Code or AC. In contrast today's operating systems secure the data by specifying what users can access it, and there are no restrictions on what code can act on that data (this is DU).

Entities - globally unique

Data in ZTOS is called an entity, and in the API is ZEntity. Think of an entity as a file. Entities can be data or software just like today's files, however every entity has a globally unique identity and a thumb that is effectively its URL. A ZNS system, like DNS, provides the thumb to IP mapping to get that entity.

Operating system providers can supply their own brand of folder and file naming systems on top of ZTOS.

Settings

Each entity has a collection of settings that must be satisfied in order for the AC to get access to the entity for the user. Each setting refers to the code that verifies that the condition has or has not been met. This code is called Proof Code or PC. Examples of PC are ZPassword or ZComputer, which verifies that the user has entered their correct password, or verifies that the AC will be executed on a company computer. A setting will specify the PC and optionally the AC and user that is allowed, and can have an arbitrary number of parameters that are specific to that PC.

Root Identities

Users need to be able to specify what actions are allowed on their data under what conditions without having to know the minutia of software subroutines. For example, a user might want to specify that Microsoft products are OK and that the marketing group can view the data and the sales group can modify it. To provide this functionality each AC entity can inherit from any number of ancestor entities. Since each entity has a unique identity, the inheritance is implemented just like an SSL certificate. There are root level entities for global concepts like View, Modify, Print, and AC providers will have their own certificates to identify that the software came from their company, for example Adobe or Microsoft. Software providers will have descendant entities that are the separate AC products, like Word or Acrobat. These ancestor entities provide the higher level concepts that enable a user to specify what software is allowed to act upon their entities.

File Formats

Every entity contains a reference to a root identity that identifies its file format. This is equivalent to Windows file extension (e.g. .txt), however unlike today's operating systems this is strictly enforced. Only AC that are descendants of the entity's file format identity can operate on the entity.

DLLs

Like today's applications, AC will depend on many different libraries (DLL), each of which will be in the AC's ancestry. Those dependencies will be brought into the AC's process space unless those libraries have been disallowed by the entity, in which case the AC will not run and get access to the data. For example an AC might depend on OpenSSL, but the organization might have disallowed OpenSSL version 1.2.3 and prior. When ZTOS attempts to satisfy this dependency it will get the latest OpenSSL DLL. If 1.2.3 is the latest, the AC will not run.

Dynamically loaded

Notice that this means that software, PC, AC, and DLLs are not installed. They are downloaded as needed by ZTOS.

API

How to create an AC

Sign the ancestry

public interface ActionCode
{
	static abstract Task End(ZEvent ev);
	static abstract Task Changed(ZEvent ev);
}

How to create a PC

How to create settings

How to open an entity.

ZEvents