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 fromgetrandom::fill().pubkey: the ML-DSA-65 public key fromidentity.key.- Result stored in
Commitment { hash: [u8; 32] }.
Step 3: POST commitment (Phase 1 of 2)
Important
POST /api/commitwith theCommitRequest. 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.).
- Reads the local zone file from
<zones_dir>/<name>.json(or creates a blank zone). - Prompts the user to add/edit records (interactive CLI prompts).
- Signs a new
Revealwith the updated zone payload. 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
| Command | Key Steps | Daemon Endpoint |
|---|---|---|
name register | Drand → VDF → ML-DSA sign → commit → reveal | POST /api/commit + POST /api/publish |
name renew | Same as register but for existing name | POST /api/renew |
name publish | Edit zone → sign → post | POST /api/publish |
name query | Direct API lookup | GET /api/resolve/<name> |