Kueea OSv1:
System definition

Introduction

The main purpose of the network is gathering and preservation of knowledge, whatever the knowledge in question is about. The first ideas leading to the creation of the network emerged around the year 2004, when the project was just another Web site. The project evolved into a network 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 programs 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 signals from the database).

Kueea Network consists of both the programs and the database.

Kueea OSv1 is an operating system running on an abstract machine composed of network nodes. The machine is controlled via a remote procedure call protocol.

This document defines the abstract machine and the remote procedure call protocol.

In the context of Kueea Network [NETWORK], this document defines the RPC subsystem of a Kueea System.

Tasks

A task is a system process which generates a response to a received message. The requested function becomes the initial function of the task.

Each task executes under the kueea [NETWORK] which has sent the (function execution request) message.

If the initial function succeeds, the task also succeeds.

A task fails when either the initial function fails or a function causes the task to fail, which aborts further execution of the task.

Each task is associated with a module. The current module of a task determines the current module context.

The current task is the task that is associated with the execution of a given program.

Task trees

Tasks may have a parent task. Those with a parent are attached; those without a parent are detached.

Detached tasks are root nodes of a task tree, in which tasks are nodes and task → parent task relationships are one-directional edges.

A task that creates another task becomes the parent of the created task.

A task T may have its parent changed to N if and only if one of the following is true:

• N is null (detach request),
• T is detached, or
• the requesting task can be found by following parents beginning at T and N.

To find task T by following parents beginning at C:

1. If T is null, return not found.
2. If C is null, return not found.
3. If C is T, return found.
4. Set C to the parent of C.
5. Repeat from step 2.

A task T is inaccessible from C when T is attached and T cannot be found by following parents from C.

Task states

Each task is in a certain task state.

A newly created tasks does not execute. Its task state is unprepared. An unprepared task may change its state to paused.

Once the system prepares a task for execution, the task state becomes paused.

When task state is paused, the task does not execute. A paused task may change its state to scheduled or failed.

When task state is scheduled, the task is scheduled for eventual execution. It is not currently executing. A scheduled task may change its state to executing, paused or failed.

When state is executing, the task is currently executing. An executing task may change its state to scheduled, paused, succeeded or failed.

When task state is succeeded, the task has succeeded and does not execute. This is one of two final states.

When task state is failed, the task has failed and does not execute. This is one of two final states.

When task state is either succeeded or failed, the task is said to have finished.

Task variables

A variable name is a pair of a class identifier of a module and a sequence of octets. The sequence of octets should contain textual data.

A name N is foreign when the class identifier of N is not invalid and the class identifier of the current module of the current task is different than that of N.

A task variable is a tuple of a variable name name, an object value and a boolean called its private flag.

A variable is unreadable when name is foreign and private flag is true.

Variables are stored in a variable set, in which name of a variable is a unique key. A variable can be stored, loaded and removed from the set.

Each task has its own variable set varset.

To load a variable named N from variable set of task T into O:

1. Fail if T is inaccessible from the current task.
2. Let task be T.
3. Fail if task is null.
4. If varset of task contains a variable R, name of which is equal to N:
   1. Fail if R is unreadable.
   2. Set O to value of R.
   3. Succeed.
5. Set task to the parent of T.
6. Repeat from step 3.

To store an object O into variable set of task T, as a variable named N with private flag F:

1. Fail if N is foreign.
2. Fail if T is inaccessible from the current task.
3. If varset of T contains a variable R, name of which is equal to N:
   1. T loses access to value of R.
   2. Set value of R to O.
   3. Set private flag of R to F.
   4. Succeed.
4. Let V be a new variable.
5. Set name of V to N
6. Set value of V to O
7. Set private flag of V to F
8. Insert V into varset of T.
9. Succeed.

To remove a variable named N from variable set of task T:

1. Fail if N is foreign.
2. Fail if T is inaccessible from the current task.
3. If varset of T contains a variable R, name of which is equal to N:
   1. T loses access to value of R.
   2. Remove R from varset of T.
4. Succeed.

Session

Each node has an associated administrator, which is a kueea identifier that may only be changed by said administrator.

The kernel of a Kueea OSv1 Node contains a session manager, which manages sessions and tasks of the node, as well as node kueea, which is a set of kueea identifiers. The current administrator is implicitly included in node kueea.

A session consists of: a shell task reference, a set of kueea identifiers called its session kueea, a set of kueea-initiated tasks called its taskset and a communication channel between the shell task and tasks in its taskset.

If the shell task is undefined, the session is detached; otherwise the session is attached to a shell. Delivery of messages from and to tasks always fail when detached.

When a session is paused, all tasks in taskset MUST stay paused; otherwise, the session is executing.

A newly created session is detached and executing with an empty taskset and session kueea containing only the node's administrator. The current administrator is implicitly included in session kueea.

New tasks are created in response to a request signed by a kueea, which MUST be a kueea identified by session kueea of the target session.

New sessions are created in response to a request signed by a kueea, which MUST be a kueea identified by node kueea of the target node,

Terminal

A terminal is a set of input and output devices together with a set of kueea signers called its signerset. Signerset of a terminal is initially empty.

A kueea signer is an object with a method for cryptographically signing a message as the associated kueea.

Available kueea of a terminal is a set of kueea identifiers which consist of those identifiers that identify kueea, for which a kueea signer exists within the signerset.

There is one terminal manager task for each terminal.

User interaction

In order to use the system, a user interacts with a terminal via a user interface provided by its corresponding terminal manager.

The user provides the manager a set of kueea identifiers together with information required to access their corresponding kueea credentials.

The terminal manager determines authentication parameters of the identified kueea and verifies that they match the provided credentials. A kueea signer is created for each kueea the verification succeeds and inserted into the available kueea of the terminal.

Once one or more kueea signers are in the terminal's signerset, the terminal manager asks the user to either start a new session or attach a shell to a detached session.

In order to start a new session, the terminal manager creates a new session via the session manager, then inserts available kueea into the session's session kueea, then attaches a shell to the session.

In order to attach a shell to a session, the terminal manager verifies that at least one identifier in available kueea matches at least one identifier in the target session's session kueea. It then obtains a reference to a shell function from the user and prepares a task for executing the referenced function. It then sets itself as its parent, sets the target session's shell task to the task, then executes it and waits until the task finishes. 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 its signerset. It asks the user to choose one kueea from available kueea to become the session's current kueea - that is, the kueea signer that will sign user-initialed procedure calls.

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

• send a procedure call request,
• change the current kueea,
• manage available kueea,
• manage tasks of a session,
• suspend a session,
• detach itself from the session.

The shell task executes under the node's administrator and it does not necessarily execute at the same node as session tasks.

If any kueea signer in the terminal's signerset fails to sign a message, the shell MUST immediately fail, which causes the session to become paused and detached.

Boot session

Initially, a node's sesssion manager contains a boot session, which is detached and has one boot task in its taskset, which executes under the node's administrator.

As stated previously, this means that only a node's administrator can attach a shell to the node's boot session.

Resources

Resources in Kueea Network are all vertices of a graph. They 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.

Kueea

Resources called kueea are special resources, in that these resources have the ability to make changes in the network. 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 or a label.

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

Users

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 a 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 Kueea Network, users are out of its scope. The network can contain information about them, though.

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

Bit sequences are categorized as either data or metadata.

Format of a metadata sequence is predefined. The sequences contain statements about resources in the network. Resources might be binary or might not have any binary representation. All of these sequences are publicly accessible resources.

Format of a data sequence is undefined. These sequences SHOULD be immutable resources. Every data sequence have a corresponding metadata sequence, which contains description of the former.

Subsystem: Metadata

Metadata sequences have a name in a metadata subsystem. This system defines the format of metadata sequences and their identification and management protocols.

It names and describes resources for Kueea Node users.

The systems database SHOULD be stored within the metadata subsystem.

Subsystem: Data storage

Both data and metadata sequences are stored in a data storage subsystem.

This system assigns lookup parameters to bit 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 on it.

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

Because other subsystems need to somehow initialize themselves, the data storage subsystem MUST provide in its interface access to special bit sequences called bootstrap sequences. Implementations MUST support at least one such sequence (for the metadata subsystem).

Subsystem: Data archival

Within a Kueea System there is a data archival subsystem. The subsystem ensures that bit sequences can be accessed by users.

It monitors availabily of bit sequences and tries to preserve it. Because Kueea Systems are meant to be decentralized, this subsystem SHOULD maintain a state where a sequence is available on more than one Kueea Node.

Policy

Kueea Nodes automatically enforce their system's policy, which is a set of rules written in a machine-readable format. The policy is communicated via system parameters, most of which is tied to the metadata subsystem.

Access denial

Kueea that break the rules are banned for a period of time. The banishment is done by sending a broadcast message with the proof of the breakage, which is one of the reasons all messages are signed.

Denial of access is never permanent. The system parameters banMin and banMax are both numbers, specifying the minimum and maximum duration a kueea may be banned for, in seconds; the maximum allowed time is 31 days (2678400 seconds); the minimum allowed time is 1 minute (60 seconds). The value of banMin MUST be lower than banMax.

The policy is publicly available for review and inspection. Every ban MUST refer to the policy rule that was broken.

Nodes are banned by banning their administrator, which in turn invalidates all join requests sent by the kueea. All of the administator's nodes are thus banned, not just one.

The punishment for breaking rules is in that a kueea becomes alone, without access to any of the resources and services offered by the system. If it wishes to regain access to them, it must follow the policy.

If a user does not agree with the rules in the policy, the options left are to establish a new system or look for another. Discussing a policy can only be done while following the rules.

The policy SHOULD only contain rules about a node's network activity, not about the content of human-readable messages on a forum, etc. The latter should be mostly lax, if any, although such rules may also exist.

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

Access control

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

Metadata sequences contain access control information among other things. Metadata is always transferred before the data, which might be protected. Access is to be denied before a data request in sent over the wire.

In other words, metadata subsytem's messages are exchanged first. If the metadata indicates a kueea can access a resource, then the corresponding subsystem's messages are sent.

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

Kueea that request data without the necessary credentials to said data are mailicious and SHOULD be banned. The access tests MUST be done on both local and remote nodes.