Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Name Registration, Renewal, Publish, and Query

Files: commands/name/register.rs, renew.rs, publish.rs, query.rs, mod.rs Crate: kinetic-cli | Stage: 14


name register <name> — The Full Registration Pipeline

This is the most computationally complex CLI command. It runs a multi-step cryptographic protocol against the daemon.

#![allow(unused)]
fn main() {
-> See: `kinetic-cli/src/commands/name/register.rs` — Lines 25–end
}

Step 1: Fetch Drand entropy

DrandClient::new(None).fetch_latest() — gets the latest beacon randomness. The Drand signature is hashed with SHA-256 to produce 32 bytes of verifiable entropy (drand_rand).

Step 2: Build the commitment hash

H(fqdn || salt || drand_rand || pubkey)
  • salt: 32 random bytes from getrandom::fill().
  • pubkey: the ML-DSA-65 public key from identity.key.
  • Result stored in Commitment { hash: [u8; 32] }.

Step 3: POST commitment (Phase 1 of 2)

Important

POST /api/commit with the CommitRequest. The daemon stores this commitment. This is the “lock-in” phase — the user can’t later fake a different name after seeing other commitments.

Step 4: Generate VDF proof (CPU-intensive)

kinetic_vdf::ChiaVdfEngine::new().generate_proof(challenge, iterations) — runs the Chia VDF for iterations steps. Run in tokio::task::spawn_blocking. This is the PoW component — computationally sequential, can’t be parallelized.

Step 5: Create the Reveal

Constructs Reveal { name: fqdn, payload: zone_bytes, salt, drand_kyn, drand_signature, vdf_proof, iterations, pubkey, signature }. Signs signable_bytes(NETWORK_ID) with the ML-DSA-65 key from identity.key.

Step 6: POST reveal (Phase 2 of 2)

POST /api/publish with the Reveal. The daemon verifies the commitment matches, verifies the signature, verifies the VDF proof, then publishes to the DHT.

Zone file

Before POST, calls save_zone_file(fqdn, &zone) to persist the zone locally in <base_dir>/zones/<fqdn>.json.


name renew <name> — Renewal

Same pipeline as register but hits POST /api/renew at the reveal phase instead of POST /api/publish. Also re-fetches the existing zone from the daemon API to carry over records.

#![allow(unused)]
fn main() {
-> See: `kinetic-cli/src/commands/name/renew.rs`
}

name publish <name> — Zone Update

Used after a name is already registered to update DNS zone records (add A records, CNAME, TXT, KID links, etc.).

  1. Reads the local zone file from <zones_dir>/<name>.json (or creates a blank zone).
  2. Prompts the user to add/edit records (interactive CLI prompts).
  3. Signs a new Reveal with the updated zone payload.
  4. POST /api/publish — re-registers the updated zone on the DHT.
#![allow(unused)]
fn main() {
-> See: `kinetic-cli/src/commands/name/publish.rs`
}

name query <name> — Lookup

GET /api/resolve/<name> from the daemon. Prints the returned NameRecord as formatted JSON. If the daemon isn’t running, falls back to constructing the API URL from config and printing an error.

#![allow(unused)]
fn main() {
-> See: `kinetic-cli/src/commands/name/query.rs`
}

name/mod.rs — Dispatcher

Defines NameCommands enum: Register, Renew, Publish, Query. handle_name_command() dispatches to the right handler.

#![allow(unused)]
fn main() {
-> See: `kinetic-cli/src/commands/name/mod.rs`
}

Quick Reference

CommandKey StepsDaemon Endpoint
name registerDrand → VDF → ML-DSA sign → commit → revealPOST /api/commit + POST /api/publish
name renewSame as register but for existing namePOST /api/renew
name publishEdit zone → sign → postPOST /api/publish
name queryDirect API lookupGET /api/resolve/<name>