Crate: kinetic-daemon

Stage: 9

Reading Time: 360 mins

Depends On: kinetic-core, kinetic-network, kinetic-storage

What Is This?

This crate contains the daemon process, which acts as the orchestrator and primary user interface for a running Kinetic node. It is the application that users actually execute when they run the node on their servers or local machines.

Unlike the other crates that provide library functionality, the daemon exposes the system via an HTTP API, handles configuration, establishes secure proxy tunnels, and runs all necessary background services.

Key Pieces

The crate is conceptually divided into a few vital subsystems:

1. The API (src/api/): Built using axum, this is a fully asynchronous REST API that exposes the node’s capabilities (like publishing records, resolving names, and interacting with the VDF engine) over standard HTTP. It includes strict CORS restrictions, constant-time token authentication, and SSE streams for real-time gossip.
2. The Proxy (src/proxy/): A complex HTTP tunneling layer that intercepts requests to .kin domains from a standard browser. It acts as an internal Man-in-the-Middle (MITM), performing recursive P2P lookups and returning standard HTTP responses, allowing seamless web surfing over the decentralized network.
3. The Services (src/services/): Background worker tasks (like the heartbeat and gossip managers) that maintain the health of the node, continually fetching the latest timestamps from the Drand network and pruning expired identities.
4. The CA (src/ca.rs): A crucial component that generates a localized Root Certificate Authority on boot and injects it into the host OS, enabling the proxy to provide valid TLS encryption for decentralized .kin websites without warnings.

Why Kinetic Needs This

A peer-to-peer protocol library is useless if a user cannot easily interact with it. The daemon transforms the Kinetic protocol into a running application.

It provides an HTTP bridge that enables modern frontend interfaces (like React dashboards or Chrome extensions) to communicate with the node without having to implement complex Libp2p gossip protocols in JavaScript. It also provides the vital proxying mechanism that allows legacy web browsers to navigate the .kin namespace transparently.

How to Read This Stage

Since this crate glues everything together, the documentation files cover a wide breadth of functionality:

• Start with 02_main_1.md and 03_main_2.md to understand the daemon’s boot sequence, setup, and graceful shutdown loops.
• Explore the API configuration and routing by reading 10_api_mod.md, which details the critical RBAC security model.
• Dive into the Proxy components (08, 09, 16, 17) to learn how decentralized websites are served locally.
• Review the various API endpoint files (e.g., 04, 05, 06, 07, 12, 13) to see how specific user actions (like publishing names or generating KIDs) translate into underlying protocol commands.
• Finally, read about the background jobs in 14_services_network.md and 18_services_misc.md.