Skip to content

Mesh relay

Network and security

Understand what the current Mesh relay protects, what it can observe and which guarantees are not implemented yet.

This page describes the current code, not an intended future security model.

Network topology

Mesh clients connect to configured relay origins over TCP. Relays communicate with other relays over UDP and replicate or route message envelopes through the relay network. The current client flow is relay-mediated; relays are not an optional fallback for direct client-to-client connections.

text
Client ── TCP ──> Relay ── UDP ──> Relay <── TCP ── Client

What is protected

  • Message payloads are end-to-end encrypted with keys derived through X25519 and XSalsa20-Poly1305 secretbox encryption.
  • Envelopes are signed with Ed25519 so their authenticity can be checked.
  • A relay forwards and stores ciphertext and cannot decrypt the message content without the participants' private keys.
  • The relay enforces protocol validation, including envelope signatures and the current ciphertext size limit.

What a relay can observe

End-to-end encryption protects content, not all metadata. The current relay database stores the encrypted envelope together with routing fields including sender, recipient, timestamp and message identifier. A relay also necessarily observes network addresses and maintains peer and operational statistics.

The runtime does not currently schedule an automatic retention purge for message envelopes. Operators must assume that routing records can remain in the relay database.

Guarantees not currently provided

  • No transport TLS: relay TCP and UDP traffic is not wrapped in TLS. Payload content remains end-to-end encrypted, but transport traffic and connection metadata are not protected by TLS.
  • No forward secrecy: contacts use long-lived encryption keys and automatic session-key rotation is not implemented. Compromise of a long-lived private key may affect previously captured ciphertext.
  • No authentication tokens: the relay protocol does not expose the token controls previously described by this website.
  • No zero-metadata guarantee: relays process and store routing metadata needed by the current protocol.
  • No IPv6 literal support: relay address parsing currently expects host:port and does not handle IPv6 literals.

Operator responsibilities

  • Keep the host and Docker installation patched.
  • Restrict administrative access to the server.
  • Expose only the required TCP and UDP relay port.
  • Protect and back up /data, which contains the relay databases and persistent state.
  • Monitor logs, resource usage and storage growth without treating logs as proof of end-to-end reachability.
  • Reassess these limitations when upgrading because the protocol is experimental.