• Delivery of a Node

TODO: implement gitlab links https://gitlab.com/octomy/octomy/-/tree/master/src/libs

When you start a node for the first time, a series of processes must complete before it becomes useful to the user. This page aims to explain this in good detail.

When the node is started, it is given an AppContext, that contains the following;

• Commandline options set at invocation of the application
• Environment variables set at invocation
• Settings instance
• Base name (identifying string)
• Base directory (local file system location pertaining to this node instance)
• Wether or not this node instance was started in headless mode or not (headless = server with no GUI)

The base name allows multiple nodes to be instanciated on the same computer by creating a separate base directory for each side by side.

All settings are stored in files inside the base directory, keeping them separate as well.

When the node is started for the very first time, the base directory and various settings files will be missing and need to be created.

This process is automatic for the most basic settings, but the node UI will ask the user to input some details pertaining to important stages in initializtion;

• Generation of ID
• Configuration of hardware such as sensors and actuators
• Pairing with other nodes for remote effective control

We will go through each stage below.

Generation of ID

All nodes have the following components relating to identity:

• KeyStore:
• asynchronous loading and storing of our local key pair
• asynchronous loading and storing of the public keys of associates
• asynchronous generation of our local private key
• Look-up of keys by ID
• LocalIdentityStore:
• asynchronous loading and storing of our local identity EXCEPT the key-pair
• ID, Node Type, Role, Birth Date, Name, Gender
• NodeIdentity (Associate):
• Wraps the map of data in LocalIdentityStore with proper selectors

KeyStore and LocalIdentityStore are wrapped in "services", and each service is started as part of the service level called "always" which means the services will be run as soon as the node starts.

Once the KeyStore has been activated, all the key data is loaded into memory, and is accessible by the node. A callback in appActivate() is called after all the services in the "always" service level have completed.

This is when the node first can check what data exists in the store. When first stated, the stores will be empty, and this will be signaled in the UI to the user through UnboxingWizard in Agent.

Sanity check is run:

1. There is no ID: We are virgin, delivered = false
2. There is an ID, but no key: We have a problem, user intervention needed, error = true
3. There is an ID with a matching key, but the key does not have a private part: We have a problem, user intervention needed, error = true
4. There is an ID and a matching key with private part: we are OK, delivered = true

Hardware configuration

Hardware is mostly relevant to Agent nodes, remotes and hubs does not need this step.

Agent nodes have the following componets relating to hardware;

• Actuator controller

Pairing

All nodes have the following components relating to pairing:

• LocalAddressList: Our local network addresses