Glossary
Application
An application is a service created by a factory.
This factory is registered with a special registry and can start instances of its application via a message.
Usually, applications in
Envelope
The envelope is the part of a message that contains all information needed for routing and handling.
In other words, it defines how a message is transported, processed, and tracked.
Typical components include:
- Recipient address(es) in nyssr.net
- Sender address in nyssr.net
- Indicator whether the message is a reply
- Option specifying whether a reply is expected
- Transaction ID for linking replies
- Flags for compression and/or encryption
- Restriction preventing the message from leaving the current node
- Permission or prohibition for logging the message
- Marker showing whether the message has already been processed by the recipient
- Indicator whether the message is addressed to a nano-service
- Microservice ID if the message targets a specific microservice
- Instruction whether the message may be forwarded
- Status showing whether the message is blocked (e.g., not to be returned immediately)
- Session ID for identifying the session, user, and permissions
- Result code for replies
- Result text for replies
- Message priority (important for routing decisions at hops)
- Unique envelope ID for routing traceability
- Timestamps for sending and receiving, both outbound and return
- Optional routing hints
Analogy:
The envelope can be compared to the address label and handling instructions on a parcel.
A parcel shows sender, recipient, shipping options (e.g., express, registered mail),
special instructions (“do not forward,” “do not open”), and tracking numbers.
All of this determines how the shipment is transported and handled – exactly like the envelope in
Message
A message consists of two parts: the envelope and the record.
The envelope contains all meta-information for handling and transport,
while the record carries the message ID and the payload.
Before sending, a message can be constructed in two variants:
- the standard version that streams data into a ByteBuffer,
- or a custom JSON structure with appended binary blocks.
Both variants can be used in parallel.
During transport, the data is repackaged.
This process creates a compact header containing all routing information in plain text,
as well as a binary block with the remaining parts of the envelope and record.
Since this block is not required for intermediate hops, it can be compressed and encrypted.
Message addressing is always direct.
Each message contains one or more recipients (as
No queues or topics are used – instead, the message is delivered precisely to its recipient,
processed there, and typically returned as a response.
If delivery fails, the message is sent back to the sender with an appropriate error code.
Analogy:
The message flow in
Each node acts like a distribution hub.
A message leaves the sender, and every hub decides, based on up-to-date information,
through which next hub the parcel will reach the destination fastest.
If a hub fails or a route becomes congested,
the parcel is automatically redirected through an alternative path –
much like a GPS navigation system that avoids traffic jams and reroutes dynamically.
Microservice
Microservices are services that can be accessed from the entire
Namespace
A namespace provides a working environment for a plug-in, application, or microservice. It provides threads, registers targets, and has a local nano service registry. It encapsulates this environment from other namespaces so that, for example, hundreds of instances of the same application can operate simultaneously in the same node.
Nano service
The abstraction of a small service that consists only of a single message, and whose implementation remains private. Nano services are registered in nano service registries, which are components of namespaces. You can address messages directly to nano services. Nano services are also used to distribute notifications.
NID
Short name for namespace ID, which means the ID of a namespace.
Node
A node is a program that runs somewhere on the network, connects to other nodes via TCP channels, and executes user software as plugins. All the nodes are identical, except for the plugins they run. Thus, a node is merely the platform for distributed user services and applications.
nyssr.net
is a "nicer net".
QID
Short name for queue ID, which means the ID of a message queue.
Record
The Record is the part of a message that holds the payload and the Message ID.
The Message ID serves as a unique identifier, allowing the recipient to filter the message and enabling the sender to match responses to the original message.
The payload itself is stored in a map-like structure called Slots.
Each slot consists of an ID, a type, and the data itself. A record can contain any number of slots.
Type-Safe Data Handling with Record Definitions
To populate and read data from a record in a type-safe manner,
we use Record Definitions.
Although these are optional, we use them by default as they significantly simplify the process.
A Record Definition is a JSON or XML file that describes what data is expected within a record.
We use these descriptions to generate helper classes that provide secure, type-safe access to the record's data.
Since these helper classes are language-neutral, they can be used not only with Java but also with other programming languages in the future.
It is always possible to append additional data to a record—for example, to better handle a response—without having to modify the original definition.
Routing
In the decentralized
Our messaging approach differs significantly from conventional solutions because it relies on dynamic,
latency-based routing rather than static routes.
In
To find the fastest route, it is not enough for nodes to know the overall network structure –
they must also take into account the latency of each segment.
The system automatically detects when nodes join or leave,
measures link latencies at short intervals, and distributes this information to all nodes.
Using a customized Dijkstra's algorithm, each node dynamically calculates the next optimal "hop."
Should network conditions change during transport, this is immediately taken into account,
allowing for a dynamic route adjustment.
Example of Dynamic Routing:
Suppose a message with destination “Node F” starts at “Node A.”
The system determines that the route A → B → E → F is currently faster than A → C → D → F
because the link C → D has high latency.
If the latency of the B → E segment worsens during transport, the route is dynamically adjusted,
and the message may instead be forwarded via C → D → F.
RemoteSkin
Service
There are several types of services in
SID
is an abbreviation for Service ID. This refers to the ID of a nano service.
sillysky
Just a beautiful name. Some claim sillysky.net is related to Skynet in the Terminator series. But we're just building a silly Skynet, putting in only modest intelligence and not letting the net gain consciousness. You are in charge of the AI.
Similar Frameworks
Slot
A slot is a data element transported inside a record.
Each slot has an ID, a type, and the actual data value.
There is a set of predefined types that represent different data formats.
Examples:
- Primitive types: BYTE, INT, LONG, FLOAT, DOUBLE, each also as an array (BYTE_ARRAY, INT_ARRAY, …)
- Characters & strings: CHAR, STRING, STRING_ARRAY, CHAR_ARRAY
- Addresses & IDs: TARGET_ADDRESS, NODE_ID, UUID, each also available as arrays
- Complex structures: RECORD, MESSAGE, OBJECT
- Special types: COLOR, BIT_FIELD, HASH, STRING_PROPERTY (key/value as strings)
- Time-related types: UTC_TIMESTAMP, ZONED_DATE_TIME, LOCAL_DATE, INSTANT
- System-related IDs: WIDGET_SET_ID, WIDGET_ID, SEGMENT_ID
This list is expandable.
A record can contain any number of slots, making it possible to build very complex data structures.
Example:
A record is created to hold user data for a login. It might contain three slots:
- Slot 1: ID=1, Type STRING, Value "username123"
- Slot 2: ID=2, Type HASH, Value = hash of the password
- Slot 3: ID=3, Type UTC_TIMESTAMP, Value "2025-09-14T11:45:00Z"
Analogy:
A slot can be compared to a field in a form. Each field has:
- a number or label (ID),
- a content type (e.g., text field, date picker, checkbox – corresponding to the slot type),
- and the actual value entered.
Just like a form is made up of multiple fields, a record consists of multiple slots.
Target
A target is a Java object that can receive messages. To do this, it must implement the ITarget interface.
However, it is more efficient to derive an object from the CTarget class. This offers many conveniences:
- a message handler class where incoming messages are mapped to lambdas or local methods
- Methods for sending messages (sendRequest, sendNotification)
- Ping support
- Management of the own target address, deregisterTarget method
- there are callback methods (notifyTargetRegistered, notifyTargetDeregistered)
- a name for the target can be given (debug support)
- messages can be logged automatically (debug support)
- Support of self-destruction (in the absence of activity triggers)
Targets receive messages exclusively in the same thread. Therefore, it is easy to avoid concurrency errors. Likewise, resources can be safely shared with other targets if they are registered in the same namespace (and thread).
TID
Short name for target ID, which means the ID of a registered target.
Timer
A timer in