Runtime and Networking: Inside the Foundations of Logos
A technical overview of the foundational components of the Logos stack.
Nasrudin
In our previous Logos Press Engine article, The Logos Tech Stack: An Operating System for Sovereignty, we introduced Logos by comparing it to a Linux distribution, albeit with several important differences.
A foundation sits at the bottom of the stack. A networking layer runs above it. A set of pluggable modules provides specific capabilities. Decentralised applications live on top.
This article narrows the focus to the two layers that are foundational to the stack. The Logos runtime provides a modular framework for the stack to build on. The networking layer routes traffic between components and across the wider network, without revealing who is speaking to whom.
These are the layers most users will never see directly, yet everything they interact with on Logos operates on this foundational infrastructure.
What is the Logos runtime?
The runtime is designed to operate similarly to a microkernel – a piece of software that handles only the most fundamental jobs, loading components, managing their lifecycles, and letting them talk to one another, while leaving all other work to separate components that plug into it.
The point is to keep the core runtime environment small so that anything built on top can be developed, replaced, or upgraded without disturbing the foundation. In this way the Logos runtime differs from Linux, which is a monolithic model where the networking stack and many other services live inside the kernel itself.
The Logos runtime is managed through a library called liblogos, written in C++.
Its responsibilities are narrow. The runtime loads and unloads modules, manages each one's lifecycle from start to shutdown, and runs an internal directory which lets modules find and call each other by name.
Networking, storage, user interfaces, and the rest of the work happens in modules that run on top of this foundational layer.
Sitting alongside liblogos is the Process Manager Module, which keeps any faults contained inside the modules they belong to. A module loaded through the Process Manager runs in its own operating system process and communicates with the rest of the stack. If it crashes, the Process Manager catches the failure, reports it, and restarts the module with an exponential backoff. This means that a single misbehaving module cannot bring down the rest of the system.
Two further elements of the runtime support the people building on Logos. A Developer Module gives developers real-time visibility into loaded modules, their registered objects, and their interactions, along with tools for tracing, hot reload, and live debugging through a JSON-RPC interface.
The Package Manager Module fetches modules (currently from GitHub, but in the future from peer-to-peer storage), verifies them against cryptographic hashes, resolves dependencies, and applies incremental updates rather than re-downloading whole modules each time something changes.
The Logos runtime is built to be as lightweight as possible to allow anything built on top of it to be developed, audited, replaced, or omitted on its own schedule. A change to one module cannot disrupt the rest of the system, as each is both independent and interoperable.
What is the networking layer?
The networking layer of the Logos stack sits above the runtime – shown in the tech stack diagram as P2P, discovery, peering, and mixnet – and handles how Logos nodes find one another, connect, and exchange messages.
Developed by the AnonComms team, what distinguishes it from a conventional networking layer is its principled focus on anonymisation. The design goal of Logos’ base networking capability is to obscure who is talking to whom. Metadata protection is a foundational property of the network itself, rather than something layered on by individual applications.
The AnonComms team develops several focused components and protocols, each addressing one part of the challenge of delivering private peer-to-peer communication at scale. Many of these are embedded in the stack’s anonymity-preserving base networking layer, while others are higher-level protocols leveraged by other components and modules.
Service Discovery addresses the first practical question any decentralised network has to solve: how does a node find other nodes that offer the services it needs, without consulting a central directory?
AnonComms builds its answer as a new protocol on top of libp2p, an established peer-to-peer networking toolkit. Specifically, it adapts DISC-NG for libp2p's Kad-DHT — a distributed hash table used by many peer-to-peer networks to coordinate without central servers.
Each node publishes a small, cryptographically signed record describing its address and what it can do. Other nodes search for records matching specific capabilities through a general API, and lightweight clients can look up peers without having to participate in the full distributed hash table themselves.
Logos is poised to become the first truly heterogenous peer-to-peer network, with many different types and configurations of nodes coordinating without intermediaries. Service Discovery solves the problem of how – within this heterogenous p2p network – to find the specific services or capabilities you need for your application.
The libp2p mixnet is the privacy-preserving transport layer itself, modelled on the same family of designs that powers anonymity networks like Tor and Nym. Messages sent through the mixnet travel through several intermediary relay nodes that shuffle and delay traffic before passing it on, so that an external observer cannot pair senders with receivers, even when tracking timing and volume carefully.
The protocol works for both fire-and-forget messages and request-response interactions. It supports cover traffic — dummy messages added to keep the crowd of plausible senders large — and will aim to support hidden services that clients can reach without ever learning their network location.
RLN and Zerokit tackle a problem that arises in any anonymous network where messages cannot be linked to their origin: with no way to identify users by name or even tie messages to pseudonymous senders, how does the network protect itself from spam?
The solution is a Rate Limiting Nullifier, or RLN – a piece of cryptography built on zero-knowledge proofs that lets each member of a network send messages up to a defined rate while staying anonymous. Exceed that rate, and the system automatically reveals the offender's identity, allowing them to be slashed or removed. In the Logos stack, RLN is used for DoS protection on the mixnet and rate limiting in Logos Delivery, which in turn is used by the Chat module.
The cryptography lives in a library called Zerokit, written in Rust and made accessible to other languages including C and WebAssembly. The same machinery has use cases beyond Logos, powering mechanisms such as gasless Layer 2 transactions that can protect against spam.
De-MLS extends private messaging from one-to-one conversations to groups. It is a decentralised adaptation of Messaging Layer Security, an open standard for end-to-end-encrypted group chat.
The decentralised variant lets a group be co-managed by multiple stewards rather than a single administrator, with built-in mechanisms for scoring peers, removing misbehaving members, and resolving conflicts.
Additional components sit further out on the AnonComms roadmap: an incentivisation protocol that lets users pay service providers off-chain without linking the payment to the service it pays for; an oracle for bringing outside data such as price feeds into the Logos Execution Zone through a small off-chain consensus among signed observers; and an identity model that allows for sovereign user accounts with support for multiple devices, verifiable log of keys, and external account associations.
Both are being developed with the foundational principle of AnonComms in mind: privacy should be guaranteed at the infrastructure level.
Private construction and communication
The runtime and networking layer are stacked together at the foundation of the Logos stack, providing the substrate on which Logos modules can be built and talk to each other.
The runtime is the cornerstone. It loads each module into the system, keeps track of what is running, and lets modules talk to each other through its internal communication system.
The base networking layer itself plugs into the runtime as a module, packaged in the same way as Storage or Messaging or any other component. Once it is loaded, it becomes the private transport that every other module uses to reach across the network.
Logos Storage uses Service Discovery to find other Logos nodes with specific capabilities – for example, a Logos node that supports delivery via the Delivery module.
This is what allows privacy to live at the infrastructure level. The mix layer allows for anonymity-preserving communication across the Logos ecosystem, providing built-in privacy to modules, including Messaging. The Logos Execution Zone supports private state when applications run logic on the blockchain.
An application built on Logos can inherit these properties whether or not its developer thought about how to preserve privacy at all, freeing up builders to create privacy-preserving apps without solving the challenge of anonymous interaction themselves.
A base layer for local-first software
The unique capabilities of the runtime and AnonComms-developed components ripple all the way up to the people who eventually run Logos applications.
The Logos stack as a whole is designed as a foundation for local-first, decentralised applications.
When a user runs Logos Basecamp, their base of operations to use and build on the stack, the software is not dependent on cloud infrastructure or centralised servers – it runs on their machine.
The network exists only to coordinate between users who each hold their own data, with no third party acting as custodian or middleman. Running a Logos node means messages never pass through company servers, files never sit in corporate data centres, and transactions never need permission from a gatekeeper.
There is no service operator collecting metadata or a database of user activity, because there is no service operator.
The runtime's modular design means each user picks their own configuration. The default ships with Storage, Messaging, and Blockchain modules, but nothing in the architecture insists on that combination. A user can leave out modules they do not need, swap in alternatives, or assemble a distribution tailored to a specific purpose.
A typical privacy-friendly online service depends on policy promises that are only as good as the company's word and the legal jurisdiction it sits inside. Using the base networking layer, Logos etches anonymity into the infrastructure itself. The mixnet structures network traffic so that even its own relay operators cannot work out who is talking to whom, RLN enforces rate limits through cryptography, and Service Discovery removes the need for a central directory
Together, these two components of the Logos stack produce resilience against failure and censorship. Modular isolation at the Runtime layer means a failing component cannot pull down the system around it. Decentralised peer discovery and mixnet routing at the networking layer mean there is no central service that could be throttled, deplatformed, or compromised.
The qualities that make Logos worth building on — modularity, structural privacy, local-first design — all trace back to the capabilities of these two components.
Get started with Logos Basecamp
Logos is a stack of four layers — the Runtime at the base, networking above it, the foundational modules of Storage, Messaging, and Blockchain alongside any number of user modules in the middle, and the decentralised applications people use on top.
The stack is configured based on the application the user is running, and they run those applications through Basecamp – the user interface for private, sovereign applications built on Logos.
Basecamp is a fully local launcher for the Logos stack, running all modules on the user’s hardware from a unified interface. It is private by default, modular, and completely in the user’s control.
If you are interested in helping to build the technology to revitalise civil society, Basecamp is the place to start.
Join us at the frontier. To start using and building on Logos, get Basecamp below:
- Repository: github.com/logos-co/logos-basecamp
- Builder Hub: build.logos.co