Skip to main content

Mesh, DNS, and self-hosting

The lattice is many nodes serving one protocol. This page is the fabric that joins them and the path to adding your own.

The mesh​

Nodes share a gossip channel — a lightweight pub/sub (zeq:mesh:gossip) each node subscribes to on boot. It's how a node announces liveness and how fleet-wide reads work without every consumer opening N connections: an aggregator subscribes once to GET /api/chain/aggregate/sse and receives every public machine's events through a single stream. The mesh carries coordination, never your machine's private state — that stays node-local.

ZeqDNS — .hz names​

Machines and nodes get human-legible names in the framework's own naming layer: a .hz name (e.g. alice.hz) maps a readable label to a machine slug, so you can address a machine by name instead of its zeq7… slug. Names resolve through the node; the mapping is itself auditable state.

Certificates​

Application-layer TLS is the framework's own: ZeqSSL issues and manages certificates for hosted channels and fork domains, so a self-hosted node serves its pages over HTTPS without an external CA in the critical path. The SSL routes live in the security reference.

Standing up your own node​

A fork is a full node that speaks the same protocol. The shape:

  1. Bootstrap secrets — the same generator the provisioner uses for a paid machine produces a node's secrets (never checked into a repo; they live server-side).
  2. Run the stack — the api-core kernel plus its Postgres and Redis, from the air-gapped compose template. The node boots, subscribes to the mesh, and starts its Zeqond clock and seal spine.
  3. Point a domain at it — nginx routes your domain's root to the node; /api/… is the live surface, /s/… serves hosted channels.
  4. Verify parity — the acceptance test is the one from Nodes: your node's GET /api/endpoints hashes identical to the reference fleet.

Because verification travels but machines don't, a fork is a peer, not a replica: machines spun up on your node live on your node, and their proofs verify anywhere — including back on the reference fleet.

What stays the same everywhere​

The kernel, the operator registry, the constants, the clock, and the proof formats are identical on every node by construction — that's what makes a ZeqProof from one node checkable on another. A fork customizes its surface (domain, branding, which channels it hosts), never the maths.