Glossary

Kinode uses a variety of technical terms. The glossary defines those terms.

Address

Processes have a globally-unique address to and from which messages can be routed.

App Store

The Kinode App Store is the place where users download Kinode apps and where devs distribute Kinode packages.

Kinode uses capabilities to restrict what processes can do. A capability is issued by a process (the "issuer") and signed by the kernel. The holder of a capability can then attach that capability to a message. The kernel will confirm it is valid by checking the signature. If valid, it will be passed to the recipient of the message. Only trust capabilties from local holders! A remote node need not follow the rules above (i.e. it may run a modified runtime).

There are system-level and userspace-level capabilities.

System-level capabilities are of two types:

"messaging", which allows the holder to send messages to the issuer.
"net", which allows the holder to send/receive messages over the network to/from remote nodes.

System-level capabilities need not be attached explicitly to messages. They are requested and granted at process start-time in the manifest.

Userspace-level capabilities are defined within a process. They are issued by that process. Holders must explictly attach these capabilities to their messages to the issuing process. The issuer must define the logic that determines what happens if a sender has or does not have a capability. E.g., the system Contacts app defines capabilities here and the logic that allows/disallows access given a sender's capabilities here.

Inherit

Kernel

The Kinode microkernel is responsible for:

Starting and stopping processes.
Routing messages.
Enforcing capabilities.

Kimap

Kimap is the onchain component of Kinode. Kimap is a path-value map. Protocols can be defined on Kimap.

Examples:

The KNS protocol stores contact information for all Kinodes in Kimap entries. That contact information looks like:

A public key.
Either an IP address or a list of other nodes that will route messages to that node. The kns-indexer Kinode process reads the Kimap, looking for these specific path/entries, and then uses that information to contact other nodes offchain.

The Kinode App Store protocol stores the app metadata URI and hash of that metadata in Kimap entries. The app-store Kinode process reads the Kimap, looking for these specific path/entries, and then uses that information to coordinate:

Fetching app information.
Finding mirrors to download from (over the Kinode network or HTTP).
Confirming those mirrors gave the expected files.
Fetching and installing updates, if desired, when made available.

Kimap-safe

A String containing only a-z, 0-9, -, and, for a publisher node, ..

LazyLoadBlob

An optional part of a message that is "loaded lazily". The purpose of he LazyLoadBlob is to avoid the cost of repeatedly bringing large data across the Wasm boundary in a message-chain when only the ends of the chain need to access the data.

Local

Of or relating to our node. Contrasts with remote.

E.g., a local process is one that is running on our node. Messages sent to a local process need not traverse the Kinode network.

Capabilities attached to messages received from a local process can be trusted since the kernel can be trusted.

Manifest

Message

Kinode processes communicate with each other by passing messages. Messages are addressed to a local or remote process, contain some content, and have a variety of associated metadata. Messages can be requests or responses. Messages can set off message-chains of requests and responses. A process that sends a request must specify the address of the recipient. In contrast, a response will be routed automatically to the sender of the most recently-received request in the message-chain that expected a response.

Message-chain

Module

A module, or runtime module, is similar to a process. Messages are addressed to and received from a module just like a process. The difference is that processes are Wasm components, which restricts them in a number of ways, e.g., to be single-threaded. Runtime modules do not have these same restrictions. As such they provide some useful features for processes, such as access to the Kinode network, a virtual file system, databases, the Ethereum blockchain, an HTTP server and client, etc.

Node

A node (sometimes referred to as a Kinode) is a server running the Kinode runtime. It communicates with other nodes over the Kinode network using message passing. It has a variety of runtime modules and also runs userspace processes which are Wasm components.

Package

An "app". A set of one-or-more processes along with one-or-more UIs. Packages can be distributed using the Kinode App Store.

Packages have a unique identity.

PackageId

Process

Kinode processes are the code bundles that make up userspace. Kinode processes are Wasm components that use either the Kinode process WIT file or that define their own WIT file that wraps the Kinode process WIT file.

Processes have a unique identity and a globally unique address.

ProcessId

Remote

Of or relating to someone else's node. Contrasts with local.

E.g., a remote process is one that is running elsewhere. Messages sent to a remote process must traverse the Kinode network.

Capabilities attached to messages received from a remote process cannot be trusted since the kernel run by that remote node might be modified. E.g., the hypothetical modified kernel might take all capabilities issued to any process it runs and give it to all processes it runs.

Kinode