poztter.net / topology

Topology.

The POZ network has a deliberately simple shape. Authoritative servers own records and accept submissions. Public caches host read-only copies and serve lookups. Clients discover servers through DNS and validate everything on the client side.

roles

flowchart LR C[Client] DNS[(DNS
SRV + TXT)] WK[/HTTPS
well-known/] PC[Public Cache
7074 / 7075] AS[Authoritative Server
7075 / 7076] C -- discover --> DNS C -- fallback --> WK C -- query --> PC C -- query --> AS C -- submit --> AS AS -. mirrors to .-> PC

fig 01 · client, discovery layer, public cache, and authoritative server.

authoritative server

Owns one or more POZ records.
Accepts submissions on port 7076 (Noise NK encrypted).
Serves queries on 7075 (Noise NK) and optionally 7074 (plaintext).
Validates every submitted update against the POZ chain before accepting.
Is the source of truth for its records.

public cache

Hosts read-only copies of POZ records from any number of sources.
Serves queries on 7074 and/or 7075.
Does not accept submissions (no port 7076).
Validates every record it caches before serving.
Pulls updates from authoritative servers via the SERIAL + CHAIN queries.

mirror

A public cache that actively replicates from a specific authoritative server is a mirror. Mirrors are listed in the authoritative server's MIRRORS response, so clients can fail over to them if the authoritative server is unreachable.

discovery flow

sequenceDiagram autonumber participant C as Client participant D as DNS participant H as HTTPS well-known participant S as POZ Server C->>D: _poz._tcp.example.com (SRV) D-->>C: poz1.example.com:7075 C->>D: _poz.example.com (TXT) D-->>C: v=poz1 h=<hash> C->>H: /.well-known/poz (optional) H-->>C: { v, original_hash, servers } C->>C: cross-validate hashes C->>S: Noise NK + QUERY S-->>C: response (POZ chain) C->>C: validate chain

fig 02 · client-side discovery and cross-validation across DNS, HTTPS well-known, and the POZ chain itself.

why this shape

The split between authoritative servers and public caches is deliberate. Caches can be cheap, plentiful, and run by anyone — they just have to validate the data they serve. Authoritative servers are the policy and submission boundary; they have to be online for updates but not for lookups. A small operator can run an authoritative server for their own record on a $5 droplet; a large provider can host many records and serve thousands of queries per second from caches.