System overview

Memory and objects

Kueea System defines its functions as routines that operates on memory of which address range has 64 bits and stores eight-bit values (octets) at each address. (Addresses range from 0 to 264-1 and values from 0 to 255.)

Objects are then defined based on this abstract memory. They define the interpretation of values stored in memory, starting from an address from which object data begin.

Therefore, each object is always composed of octets, regardless of how the physical memory device works and what kind of registers a CPU has. If memory can store more than 8 bits per address, the excess bits are ignored and never used by the system. Furthermore, memory that stores less than 8 bits per address is unsupported. (A memory emulator would be needed in this case.)

It must be noted that this applies to the objects defined by the system. It does not matter how a function is implementated internally. What matters is the state of the object before and after a function executes.

Object management

Kueea System is an object-oriented system. All allocated memory is always tied to an object and belong to the system.

There are four object kinds:

  • system objects, accessible only to the most privileged software;
  • task objects, accessible only to a specific task;
  • module objects, accessible to all tasks within a given module; and
  • shared objects, which multiple tasks can access.

The majority of objects in the system are shared objects.

Allocating memory for and object and then constructing it (initializing its memory to a valid state) is called creation. The opposite of construction is destruction, although the destructor operates only on the primary object.

Tasks create objects, although they don’t destruct them. It is the system that decides when to call the destructor and deallocate an object’s memory. It is because other tasks may be using the object.

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

Tasks 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 may implement sets of functions called interfaces. Interfaes may also define an associated object, which a class must contain somewhere within its definition.

Data about classes are stored within special objects called class descriptors. They contain basic information about a class as well as contain references to functions which implement a given interface for this particular class.

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 on its supported interfaces instead of it being an instance of a particular class.

In other words, the structure of run-time type information 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 was written in.


Kueaa System is defined by technical documents called modules. Each module defines a set of symbols, which are names and definitions of functions, objects and messages. A program that implements a module is a module implementation.

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

Modules are narrow in scope so that their developement ends one day and the module become finalized and is never updated again.

They standarize system features by giving them system-unique names. This allows implementations to be replaced without affecting other ones. (The module identifier is a system-unique namespace for its symbols.)

Each implementation also have an identifier in order to differentiate them and provide a way for a program to request a specific implementation instead of referring to the identifier-revision pair. This should generally not be used, although it exists for scenarios such as when an implementation have been audited and certified.


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.