Client Concepts

How Agent Nodes leverage the LIOP Mesh for discovery and execution

In the Logic-Injection-on-Origin Protocol, a “Client” is best understood as an Agent Node or an intelligence orchestrator. While the Server guarantees safe execution, the Client is responsible for discovering data, defining intents, and dispatching execution logic across the network.

Agent Nodes interact with the Mesh through three core mechanisms: Discovery (DHT), Elicitation Handshakes, and Logic Injection.

1. Network Discovery (Kademlia DHT)

In traditional Client-Server architectures, the Client must know the exact IP address or Domain Name System (DNS) entry of the server it wishes to query (e.g., https://api.internal.corp/).

Agent Nodes in LIOP operate in a decentralized peer-to-peer topology:

• Every Agent and Data Node generates a cryptographic Ed25519 Peer ID upon startup.
• Nodes connect to a peer-to-peer bootstrap network and form a Kademlia Distributed Hash Table (DHT).
• When an Agent needs to access a specific capability (e.g., Company_SQL_Database), it queries the peer network: “Which Peer ID currently holds this capability?”
• The DHT algorithm calculates the routing path to the target node, resolving its dynamic IP automatically behind NATs and firewalls without a central registry.

This provides fault tolerance and dynamic route resolution across distributed nodes.

2. Elicitation & Trust Handshakes

Because the Mesh is decentralized, trust cannot be derived from standard centralized Certificate Authorities (CAs) used in traditional mTLS.

When an Agent Node locates a Data Node, it initiates a Zero-Trust Handshake (Elicitation) before any logic is executed.

• LIOP uses the Noise Protocol Framework, encrypting connections natively at the transport layer (QUIC) using symmetric keys derived from peer identity.
• Post-Quantum Cryptography (PQC): LIOP Client Elicitations encapsulate session keys using ML-KEM-768. This prevents adversary capture of encrypted traffic for retrospective decryption by future quantum hardware (Harvest Now, Decrypt Later).

If the Data Node requires user consent or authorization tokens, it responds to the Elicitation request prompting the Agent for the required OAuth scopes.

3. Logic Injection (The Payload)

Once the secure channel is established, the Client executes its core function: Logic Injection.

Instead of dispatching sequential JSON commands to retrieve raw text, the Agent relies on local logic compilation orchestrated by the TypeScript SDK:

1. Compilation: The Agent translates its high-level logic (JavaScript, Python) into a compact WebAssembly module.
2. Client AST Sentinel (GuardianTS): Before transmission, static AST rules verify that the .wasm binary does not contain unauthorized host syscall imports.
3. Payload Sealing (Crypto Module): The Client encapsulates the session using ML-KEM-768 (Kyber768) and encrypts the payload with AES-256-GCM.
4. Streaming (MeshNode): The Client multiplexes the connection via Yamux along with Noise and transmits the encrypted binary to the target peer.
5. ZK-Verification: Upon result retrieval via libp2p ingress, the Agent verifies the ZK-Receipt to validate execution integrity.

By delegating execution to the Origin node, the Agent Client remains lightweight, coordinating concurrent connections across the Mesh while remote servers execute data processing locally.

SDK Runtime Architecture (Node.js)

The Node.js Host orchestrates this pipeline using asynchronous worker pools. The LIOP SDK executes cryptographic operations and verification tasks off the Main Event Loop, maintaining responsiveness under high query volumes.

The visual flow above details the four core components inside the local @nekzus/liop:

1. Agent App (LLM Logic Emitter)

The origin application layer (such as an analytical agent or internal orchestration service) that defines the query intent and provides the initial logic to be dispatched to the Mesh.

2. GuardianTS (AST Heuristics)

Prior to network transmission, GuardianTS validates module safety. Utilizing V8’s native compilation pipeline as a static validation step, it scans the generated .wasm binary for unauthorized host imports outside wasi_snapshot_preview1. Payloads failing validation are discarded immediately.

3. Worker Pool (Piscina Cryptography)

To keep the Node.js event loop free of computational bottlenecks, cryptographic operations run inside a native piscina Worker Pool.

• Egress (Outbound): Worker threads encrypt the validated .wasm module with ML-KEM-768 and seal it inside an AES-256-GCM envelope.
• Ingress (Return): When the resulting payload and ZK-Receipt return, the Worker Pool decrypts and verifies the cryptographic proof concurrently, preventing main-thread blocking.

4. MeshNode (Yamux/Noise Multiplexing)

The network boundary interface. MeshNode maintains a libp2p gateway to the decentralized network, encapsulating traffic in a Noise protocol tunnel and multiplexing streams via Yamux. This enables a single connection to support concurrent Logic-on-Origin executions with minimal framing overhead.