Architecture#

Where this module sits in the stack, and how much of that stack a given node actually mounts.

Layers#

A message passes through four layers on its way out:

Logos Core  ·  your module or UI
     │  calls delivery_module methods
     ▼
delivery_module            ← this repository, a Qt plugin
     │  C FFI
     ▼
liblogosdelivery
     │  Nim API
     ▼
logos-delivery             ← the node implementation

This repository is the middle box. It owns no protocol logic: it adapts the universal Logos module API onto liblogosdelivery’s C FFI, and turns the callbacks coming back the other way into typed events. Everything about how messages actually travel is decided by logos-delivery.

That division is why the configuration you pass to createNode is handed through verbatim — logos-delivery owns the grammar, and this module does not interpret it.

What a node mounts#

createNode’s entryLayer decides how much of the stack comes up:

`entryLayer`	What you get
`"kernel"`	Transport node only.
`"messaging"`	Kernel plus the messaging client.
`"channels"`	Kernel, messaging, and reliable channels. The default.

The layer you pick determines which methods work. On a kernel-only node, send, subscribe and the channel* methods fail with “node has no messaging client” or “no reliable channel manager”. getNodeInfo, storeQuery and metrics keep working.

The concrete configuration shapes — an app developer’s full stack, a node operator’s public service node, a self-hosted network — are documented with createNode in the API reference.