Security & privacy

What the relay can see. What it can't.

Kant is designed around relay-assisted privacy rather than full central-server custody. Below is the actual data processing model and threat model — stated plainly, including the parts that are still open.

the relay never stores
  • Message content
  • Message history
  • Contact lists
  • User identity keys (beyond the relay's own long-term seed)
  • Private user payloads
the relay does process
  • Public registry metadata (signed circuit addresses)
  • Connection and reservation metadata
  • Health, readiness, and metrics data
  • TLS/certificate data at the termination layer
Threat model

Modeled threats and their mitigations.

Scoped to the active product surface: relay bootstrap, registry publishing, client identity and session handling, and the TLS termination layer in front of the public relay.

Message interception

Mitigated by end-to-end encryption at the client — the relay only ever forwards ciphertext frames it cannot decrypt.

Relay impersonation

Registry entries are signed by the registering peer's identity key, so a spoofed relay can't publish addresses on someone else's behalf.

Replay attacks

Every /register and /lookup call carries a nonce; duplicates are rejected outright.

Reservation abuse / resource exhaustion

Registry entries expire on TTL and are pruned on disconnect, bounding how much state a flood of reservations can accumulate.

Seed compromise

The relay's identity is recoverable through an authenticated backup flow — a compromised host doesn't mean the relay's identity is unrecoverable.

Public exposure of admin services

Admin reservation endpoints require a configured bearer token and are not reachable at all without one.