Kueea System is a distributed, peer-to-peer operating system. Its main purpose is gathering and preservation of knowledge about the worlds around us, whether these are real or fictional. It provides tools to make computations on that knowledge, so that further knowledge may be inferred from what is already known, tools for creation and interaction with various kinds of resources and enables its users to stay connected with each other via automanaged networks.

The first ideas leading to the creation of the system emerged around the year 2004, when the project was just another Web site. The project evolved into an operating system around the year 2015. The goal was to avoid duplication of information by connecting databases. As research progressed, it became clear that a database alone is useless. There needs to be a system of applications that use and manage the data. Database usefulness needs to be proven by using it for something perceivable like an audio or video player (that reads streams from the database). Kueea System consists of both the applications and the database, which is where all of system and user resources are being kept.

One does not "install" the system on a machine. Rather, one prepares and adds one’s machine to the system. It then becomes a terminal through which one can access the system.

In short, the system is an intangible, abstract concept. The behaviour of a node as seen from outside is what matters. For example, if a node is asked to add 2 and 3, it is expected to answer 5. How did it arrive at this answer (implementation) is insignificant.

Kueea System

Kueea System is composed of Kueea Networks. It is an abstract thing that does not physically exist. There exists only one Kueea System; do not use ‘the’ in English, please.

A Kueea Network is an abstract network of kueea. Kueea (user representations) connect with each other via Kueea Nodes. The type of Kueea Node is a property of a Kueea Network. Networks are at the level of resource identfication and interfaces. Nodes are what implement these interfaces.

A Kueea Node is part of a mesh (peer-to-peer) network. The node is required to support a certain set of network services. The basic service is that of a general-purpose remote procedure call (RPC) system, which is one of the core concepts of Kueea System. The available procedures are defined by Kueea Modules.

This RPC system allows any kind of function to be called as well as reference memory physically located at every node in the network. From the perspective of the programmer it does not matter which node executes a program, because every node is able to do it. A function call can be redirected to another node for execution, at any moment in the program (theoretically).

The term peer or node refer to an entity that is connected to other such entities with some kind of network technology. Ethernet and Internet are examples of such technology. Generally, in Kueea System documents, nodes refer to a single entity, whereas peers are used in the context of node communication.

Modules and M-Builds

A Kueea Module is a technical document. It defines symbols, which are functions and in-memory data objects of various kind, as well as paths under which resources (usually octet sequences) used by the module are located. Symbols and paths are within the namespace of the defining module.

Symbols and paths (items) are grouped under module levels. Once an item is declared as final, its definition never changes. Implementations of a module at level n contain all items defined by levels [0,n] of that module.

An M-Build is an implementation of a module's symbols.

An M-Build image contains one or more M-Builds. They are program images interpreted and executed by system software. The system is not dependent on any particular image format, although there always exists a preferred format for these images.

Paths name out-of-memory resources, like configuration data, or things like assets used by a game engine, style sheets, etc. There are four kinds of resources:

  • read-only resources, which are distributed alongside M-Build images,
  • node-specific resources, which are stored at the node executing the task,
  • synchronized resources, which are synchronized against a synchronization point, meaning that the resource state is the same on every node,
  • user-provided resources, which serve as input from and output to the user; modules do not define these.

Each module’s goal is to standarize some specific system functionality. Modules ought to follow the KISS (Keep It Simple, Stupid) rule. They are to be narrow in scope so that their developement ends one day, the module becomes finalized and no more items are ever added to it. If it does not need revision, it means it’s good and can be safely used.

Having too much functionality in a module makes it more unstable. Stability is the most important trait every module author ought to pursue. Modules that are constantly revised are broken by design. Such modules ought to be scrapped, made obsolete, and then redesigned as new modules (with a new identifier).

The scale of a module should ideally be small enough for one person to not become mentally exhausted (burned out) while implementing it alone. There should be many implementations available that a user can choose from.

One should differentiate between a module and a software project. The module ought to be a part of the project, not the project itself. For example, if a Python interpreter were to be a module, then Python 2 and Python 3 should be different modules developed as part of the same project. They are different because the most crucial part—the parser and interpreter—are different for version 2 and for version 3. The other reason is that Python 2 is phased out in favour of 3. Keeping both 2 and 3 in the same module is counter-productive. Remember that symbols—once defined—cannot be removed from a module.

Some modules are published and standarized for the general public. Other modules may be known only to select few or be created as part of developement or a user session and have the lifetime of only few hours.

Kueea Network

Each Kueea Network is defined by its network parameters.

The main parameters of a network are: the network technology used for node communication, the broadcast channel, the type(s) of Kueea Node, the trust anchor and the ruleset.

A node becomes part of a network by adopting the network's parameters.

Network protocol

The network protocol receives messages from Kueea Nodes addressed to other Kueea Nodes and passes them around as opaque data.

It also concerns itself with problems such as node authentication, so that is ensures the messages are delivered to their intended destination.

It must also ensure the messages cannot be tampered with or intercepted by unintended parties while a message is in transit.

Broadcast channel

Majority of communication is done via direct communication between nodes, but sometimes there is a need to send a network-wide message to all nodes, for example when advertizing a role intent to the network.

Thus, each network defines its broadcast channel, which is monitored by every node in the network for incoming messages.

The possible ways the broadcast channel can be implemented is decided by the network protocol in use.

The broadcast channel is needed to avoid the need for a centralized server. That said, the channel may be implemented as such a server, although this is greatly discouraged and should be done only if no other methods are viable.

Node type

An implementation of a Kueea Node is called a Kueea Node type.

A Kueea Node type defines its associated Kueea Module Declaration Language (what functions and data types exist) and its implementation of the RPC protocol (messages over the network protocol). It also defines the format of its ruleset.

A Kueea Network defines what types of Kueea Node it supports, i.e. what kinds of node is its graph made of.

To a user, this is the answer the following question: “What kind of device I need to be able to join the network?”

Trust anchor

The trust anchor is a set of entities who are trusted by default. All statements signed by these entities must be accepted by all nodes. The trust in these entities is what defines a Kueea Network.

The trust anchor should consist of individuals, because behaviour of an individual is a more stable factor than that of a group. Members of a group change in time, which in turn changes its trustworthiness. An individual is always the same individual.


Kueea Nodes automatically enforce the network's ruleset, which is a set of rules written in a machine-readable format. Format of a ruleset is a property of a given node type.

For example, if the ruleset says that trolls are not allowed, then whenever a kueea is labelled a troll by members of the network, and the label is credible (trustworthy) following the trust anchor, the trolls will automatically be banned from the network by every node.

One node may be a peer in multiple Kueea Networks at the same time. The sender of a message determines which networks (rulesets) to consider.


Kueea Nodes may serve a particular role in the network.

A node broadcasts to the network its intent to serve a role. Other nodes, upon receiving the intent, may accept it or not. Incoming connections to a node mean that the role has been accepted, i.e. the service is being accessed by other nodes.

Examples of roles are: value registry, file archive, public cache, etc. Basically, these are nodes that are frequently accessed by others. Most of them are expected to have fast connections and high availability.

A healthy network is one where multiple nodes take the same role, so that if one of them becomes unavailable, there are others remaining; the availability of a service is thus preserved.

An important part here is that roles are established dynamically and may not require any intervention from a user. Role assignment can be made fully automatic.


Resources in Kueea System are all vertices of a graph. All resources referenced by their globally unique identifiers.

An identifier is a name in a certain namespace. A network's policy declares namespaces that must be recognized.

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

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


Resources called kueea (uncountable) are special resources, in that these resources have the ability to make changes in the system. Other resources are inanimatable objects, which do not act on their own. For example, an author of a document would be a kueea.

Kueea do not necessarily represent living beings. They may be abstract concepts (like nature) or fictional characters. Organizations also have kueea – their public image. Think of them as masks a human puts on when interacting with others. One may also think of a communication channel.

Kueea is a resource which has authentication properties. These properties are used to verify cryptographic signatures. Technically, kueea are what signs messages in the system.


The term user refers to a physical being (usually a human) which interacts with a Kueea Node via its terminal device(s), by which the user issues commands to its kueea to do things within the system.

A given user is always the same user. A kueea may represent a user, but it is not the user. The current user of a kueea is a property that may change, for example because one user sold its kueea to another.

From the point of view of the system, users are out of its scope, they are external to the whole system.

A user resource is a collection of kueea credentials. The credentials are required to generate signatures (control kueea). The user resource should be stored on a device one carries with oneself. It could be a pendrive or some other removable storage device. The data should never be stored on a publicly accessible storage medium.

Data and metadata

Octet sequences are categorized as either data or metadata.

Format of metadata sequences is standarized. They contain information about resources in the system, which might be binary or might not have any binary representation. Metadata sequences have a name in a metadata system. All of these sequences are publicly accessible.

Format of data sequences is undefined. Every data sequence have a corresponding metadata sequence, which describe its content. Data sequences are treated as immutable objects.

Both data and metadata sequences (because they are data, too) are stored in a data storage system. This system assigns lookup parameters to the sequences, which are all based entirely on the sequences themselves. The parameters are generally the length of the sequence and the results of applying a [hash function][hash] on it.

Users generally concern themselves with metadata sequences only. Data sequences are managed by system software in the background.

Because the metadata system needs to somehow find its sequences, the data storage system must provide in its interface at least one special sequence called the metadata bootstrap sequence. It may, of course, also provide specialized interface for a specific metadata system but one such sequence is the bare minimum.

Data management

Within a Kueea Network there is a data management system. It monitors availabily of octet sequences and tries to preserve them by maintaining a state where a sequence is available on more than one node. It ensures the availabiliy of data sequences to nodes.

Kueea assign a perceived value to data sequences. Sequences regarded as more valueable are duplicated in higher amounts and are given higher priority than those of lower value.

The purpose of this system is both to preserve data availability by distribution of backup duplicates over the network as well as make it possible to conduct research regarding the value of data by comparing their perceived values, market values and availability.

Access control

Access control in Kueea System is consensus-based. Rights are determined by the policy of a network.

Metadata sequences contain access control information among other things. Metadata is always transferred before the data, which might be protected.

If the data is unavailable locally, the node will look for it on the network. In order to successfully fetch it, the other peer must also agree on the assessment that the requesting entity may access the data.

Peers that requests data without the necessary credentials to said data are mailicious and are to be banned by every node in a network. Malicious peers are eliminated by denying them access to other peers.

The punishment is in that the peer becomes alone, without access to any of the resources offered by the network. If it wishes to regain access to the resources, it must follow the policy.

The policy is publicly available for review and inspection. Every banned node must be informed of the rules that it broke.

If a peer does not agree with the rules in the policy, the options left are to establish a new network or look for another. Discussing a policy can only be done while within a network or out-of-band.

A node that does not follow the policy in its network effectively creates another, hidden network with some other policy. In order to become part of this hidden network, one would need to somehow obtain addresses of its hidden nodes. In other words, life is very difficult for such networks. All nodes would also have to put trust in each other for staying hidden. Discovering these nodes exposes the ones that break the rules.


The kernel of a Kueea Node contains a session manager, which manages sessions and tasks created as part of the session.

A session consists of: a shell task, a set of user-initiated user tasks and a communication channel between the shell task and user tasks.

Only the session manager have the right to create a task under a kueea different from the kueea of its own task.

When powered on, a Kueea Node creates its boot session. The boot process adds user tasks to this session. One of these user tasks is the terminal manager, which is given access to the node's terminal(s) (input and output devices). User tasks in the boot session execute under the node administrator. At the end, the boot session is active without a shell attached to it.

When a user wants to use the system, the user interacts with the terminal manager and points it to its user resource. The manager then asks the user to provide information required to access kueea credentials of the kueea chosen by the user.

The manager then contacts the network to determine authentication paramters of the chosen kueea and verifies that they match the credentials provided by the user. The set of kueea for which the verification succeeded becomes the current set of available kueea.

Once one or more kueea are in the available kueea set, the terminal manager asks the user to either start a new session or attach a shell to one that is suspended or active.

In order to start a session, the terminal manager creates a new session via the manager. The session is active on creation with no user tasks and the shell task unassigned. It then attaches a shell to the session.

In order to attach a shell to a session, the terminal manager first verifies that available kueea is a superset of the set of kueea under which user tasks in a given session execute. It then obtains a reference to a shell (function) from the user. It passes the shell and the chosen session to the session manager, which creates the shell task and assigns it to the session. This blocks the terminal manager until the shell task finishes.

While the shell task executes, the session is current. Once the shell task finishes, control of the terminal goes back to the terminal manager, which once again presents its interface.

The shell task is given access to the terminal and available kueea. It asks the user to choose one kueea from available kueea to become the session's current kueea - that is, the kueea under which new user tasks will be created.

While the user is interacting with a shell, it can:

  • change the current kueea,
  • modify available kueea,
  • manage user tasks of the current session,
  • suspend the current session,
  • leave the current session.

Requests to create new tasks are signed and sent to the session manager. The shell task does not necessarily execute at the same node as user tasks.

If the shell loses access to credentials of any available kueea, it forces the session to become suspended: all of its user tasks are paused and the shell task finishes. The user can also explicitly suspend the current session.

When the user commands the shell to leave the session, the shell presents a dialog to the user in which it can choose which user tasks to stop and which should remain as executing. If all tasks are to be stopped, the session is finished and removed. If one or more tasks are to remain, the session remains active. In both cases, the shell task finishes. The session is not current anymore.