poztter.org / components / network protocol

The POZ network protocol.

All components · Service Zone · poztter.net (live network)

POZ records move over a small purpose-built TCP protocol — not HTTP, not a blockchain. Three ports do all of it. Servers are stateless: connect, ask one question, receive one answer, disconnect. The data is the trust anchor; the transport doesn't need to be trusted to be useful.

the three ports

Port	Encryption	Direction	Purpose
`7074`	None	Client → Server	Public lookups. Response is self-verifying.
`7075`	Noise NK	Client → Server	Private lookups. Eavesdropper sees nothing.
`7076`	Noise NK	Client → Authority	Push signed updates or request authority signing.

Each port enforces a specific contract. Plaintext queries are useful for tooling, debugging, and environments where Noise isn't available. Encrypted queries protect the privacy of which user is being looked up. Submissions go only to authoritative servers and are always encrypted. Separate ports mean a server's encryption requirement is visible at the firewall layer, and a misconfiguration can't accidentally serve submissions on a public lookup port.

discovery

Clients find servers using infrastructure that already exists, so deployment doesn't require new global plumbing:

_poz._tcp.<domain> SRV record points to query servers.
_poz.<domain> TXT record carries the domain's original_master_hash.
https://<domain>/.well-known/poz JSON is the PKI-backed fallback.
Direct connection to <domain>:7075 or :7074.
_poz-submit._tcp.<domain> SRV record points to the submit endpoint.

Cross-validation is the point. Compromising the binding from a domain to a POZ record requires compromising DNS and PKI and the POZ chain. Any one of those still standing detects the others.

fig 01 · the client checks the same binding through three independent paths. Any disagreement is a signal that one of them has been compromised.

wire format

Request
  uint8   protocol version (0)
  uint8   query type
  uint16  request ID (echoed in response)
  uint8   PoW flag (0 / 1)
  [if 1]  challenge[16] + timestamp + nonce
  uint16  payload length
  uint8[] payload

Response
  uint8   protocol version (0)
  uint8   status code
  uint16  request ID
  uint32  payload length
  uint8[] payload

query types (ports 7074, 7075)

Code	Name	Returns
`0x01`	MASTER	The master zone for a domain.
`0x02`	MIRRORS	Known servers for a domain.
`0x03`	SERIAL	Current serial / hash — cheap freshness check.
`0x10`	IDENTITY	Identity binding for one user handle.
`0x11`	CHAIN	Full validation chain: master + authority + zone.
`0x12`	ZONE	Generic query for any zone type.
`0x13`	CHALLENGE	Get a proof-of-work challenge.

submit types (port 7076)

Code	Name	Effect
`0x20`	SUBMIT_SIGNED	Push a fully signed zone update.
`0x21`	SUBMIT_REQUEST	Request an authority signature on a new identity entry.
`0x22`	SUBMIT_STATUS	Check status of a pending submission.

noise NK

Ports 7075 and 7076 use the Noise Protocol Framework's NK pattern with the cipher suite Noise_NK_25519_ChaChaPoly_SHA256. The server's Noise static key is the raw Curve25519 public key from its POZ master zone — the same key serves as both the signing root and the transport authentication key.

The handshake completes a query in a single round trip: the request goes inside the client's first message, the response inside the server's first reply. Forward secrecy comes from the per-connection ephemeral keys.

fig 02 · the client sends its request inside message 1; the server's response rides inside message 2. The handshake authenticates the server using its POZ key.

adaptive proof-of-work

Proof-of-work protects servers — small and large — from volumetric DoS. Servers configure a base difficulty (often 0); under load, difficulty rises automatically. Legitimate clients are unaffected at low difficulty; attackers pay more as load increases.

given:    challenge[16], difficulty
find:     timestamp, nonce
such that:
  SHA-3-256(challenge ‖ timestamp ‖ nonce)
  has at least <difficulty> leading zero bits

Verification cost is one SHA-3 hash, regardless of difficulty. Challenges are derived from a server secret and a time window, so they're verifiable statelessly and expire automatically. A client can request a challenge proactively (CHALLENGE, query 0x13) or react to a POW_REQUIRED response.

what a server can and can't do

POZ data is self-verifying. A compromised server can:

Refuse to serve data (denial of service).
Serve stale data (older serial numbers).
Lie about which records it hosts.

It cannot:

Forge identity claims.
Modify zone data without invalidating the chain.
Impersonate another server on a Noise port.

This is the protocol-level expression of POZ's core philosophy: trust the data, not the provider. The server moves bytes; the client verifies.