This page is a work in progress. It is not ready for publication yet.

System overview

Kueea System is composed of Kueea System Networks.

Kueea System Network is a computer network, in which each node supports the required set of network services by implementation of corresponding Kueea System Modules.

Kueea System Module is a written document. It describes a set of data structures and functions, which compose some specific functionality of the system.

Programs and memory

Kueea System programs are executed by an abstract computer. The processors of the computer do not matter. They are undefined. What matters, however, is the memory that the processors access.

The abstract computer does not exist as one device. It is implemented as a Kueea System Network. Memory of all nodes is the memory of this big computer. It has as many internal processors as there are nodes.

There are three different memory spaces within Kueea System.

System memory

System memory is made of octets, each having a 192-bit address. Reference to this memory is called a handle. It is a memory reference which is unique within a Kueea System Network.

The higher 128 bits of the address contain an identifier of a node. The lower 64 bits reference an octet stored by that node. (Note that one device may function as more than one node.)

At one point, the authors considered hardware that could reference the system memory directly, but that idea was abandonded. The problem lies in that if the memory was physically at another node, fetch operation would complete after the data arrives over the network link. The CPU would not be able to execute the next instruction or be interrupted. This would introduce very long delays, which is unacceptable. Long-distance network links also introduce a bunch of other problems. The 192-bit system memory is thus implemented by software.

Virtual memory

Programs access memory through a node-local virtual memory space. The space is made of bytes, which must be at least 8-bit long. All bits above the lowest 8 are undefined and must be cleared between calls. The bytes are referenced by 64-bit virtual addresses. These addresses are temporary and local to the program.

Current (as of 2019) CPUs reference memory with 64-bit words, of which not even all of the 64 bits are used for the address. The authors believe 264 octets is enough for any program.

Physical memory

Virtual addresses are then translated by the node's CPU into a corresponding node-local physical address, under which actual data resides; or, if the memory is at another node, the reference is intercepted and translated by the system.

Objects and memory management

Kueea System is an object-oriented system. All allocated memory always contain data of some object.

An object has the following traits:

  • location of its data,
  • length of the data (in octets),
  • type of the object (class),
  • other attributes and flags.

Objects belong to one or more of the three memory contexts:

  • system context, accessible only to the system software of a node;
  • module context, accessible to all tasks of a given module; and
  • task context, accessible only to a particular task.

The lifetime of an object is as follows:

  1. A task requests the system to allocate memory for an object.
  2. The task gains access to the object.
  3. The task invokes the object’s constructor.
  4. The object is now created.
  5. Tasks utilze the object.
  6. Tasks lose access to the object.
  7. When there are no more tasks with access to the object, the system calls the object’s destructor.
  8. The system deallocates the object’s memory.

The core functionality of Kueea System is tasks’ ability to gain direct access to objects created by other tasks, including those objects which reference other objects.

Programs may also call functions in separate, distinct tasks, which at the beginning gain access to necessary objects. They may also return objects to the caller.

Classes and interfaces

Every object is an instance of some class. Classes contain data and function members. Function members are often called methods of the class.

Classes may implement sets of functions defined by interfaces. Interfaces may also define an associated object, which a class must contain somewhere within its data structure.

Information about classes and their interfaces is stored within special read-only objects called class descriptors.

Tasks may access this descriptor, which allows a task to execute interface functions without any prior knowledge about a given object. Programs may be written to manipulate an object based its type, or based on the supported set of interfaces.

In other words, run-time type information about objects is a part of the system’s ABI in order to provide system-wide virtual function functionality to every task in the system, regardless of the language a program has been written in.

Modules and M-Builds

Kueaa System is defined by technical documents called modules. A program image which contains implementation of one or more modules is called an M-Build. The system is not dependent on any particular image format.

Each module defines a set of symbols, which are functions and various kinds of data objects within a module. They also contain, or reference, information necessary for the reader to understand the content and then use or implement the module.

Modules are identified by their unique identifier and revision number. Higher revisions of a module may only add new symbols to the module. Existing symbols are never re-defined. They are always backward-compatible with lower revisions.

**Modules that need redesign are scrapped and made obsolete. A new module then takes its place with a new identifier.**

Modules are narrow in scope so that their developement ends one day, the module becomes finalized and is never revised again. If it does not need revision, it means it’s good and can be safely used. Modules that are constantly revised are broken by design. (Note that this paragraph is about modules, not M-Builds.)


Kueea System is a peer-to-peer operating system. This means that for the system to function there needs to be a network, although this network may be composed of only one peer.

The term peer or host refer to a device that is connected to other devices with some kind of network technology. Ethernet is an example of such a technology.

Throughout the pages the term network refers specifically to a network of devices, which all execute some implementation of Kueea System.

Each such network is defined by the set of host which compose it, as well as its trust anchor, which is a set of entities that every peer in the network trusts by default.

Networks that have the same set of entities in their trust anchors are compatible and their resources may thus be merged together.

One host may be a peer in multiple networks at the same time. Which network is to be considered is based on whence data came from.

The goal of Kueea System is a state where every peer on the Internet agrees on a common trust anchor, i.e. every peer on the Internet is part of one big Kueea System network. Realistically, this will probably never happen.


Resources in Kueea System are stored in a global graph. This means that at the low level there are no files nor directories. If one needs, one may compose a tree from the nodes of this graph.

Resources are either device-independent, in which case their identifiers do not take device or host identifiers into account; or they are device-specific, in which case the host needs to be specified.

Device-specific resources are generally limited to actual physical devices.


Resources called kueea are entities on behalf of which tasks are executed. They are conceptually not users, but something closer to pseudo-users on UNIX systems.

User resources are sets of kueea credentials and are stored outside the system.

When someone wants to use the system, the person points the system to its user resource. This user resource is something one carries with oneself. It could be a pendrive or some other removable storage device. It should never be stored on a publicly accessible device.

Once the system has access to the user resource, the user is asked to provide the system necessary information required to access kueea credentials stored therein. When the system successfully accesses the credentials, it then asks the user to choose under which kueea tasks are to be executed.

The shell is designed so that users may freely switch between their kueea within the same session.

Some tasks may require contacting other deivces. In this scenario, the task will identify itself as the kueea on behalf of which the task was executed.

Kueea are globally unique resources. They are generated independently of the system and then registered with a network in order to be recognized. Users themselves are the sole authoritative source of information about their kueea, although there is a third-party trust anchor involved.

No host may act on behalf of any kueea unless explicitly allowed by the user.

Access control

Access control in Kueea System is decentralized and based on network policy. A host determines whether a kueea has access to a resource based on information coming from the network it is a part of.

Public metadata is always transferred before the data, so that a host may verify access before requesting the data proper. Hosts that requests data on behalf of kueea that do not have rights to said data are mailicious and are to be banned by every peer in a network.

Know your peers or follow the policy.