Skip to content

hamma

A clean-room Rust implementation of a Tailscale-compatible mesh networking stack. Pre-alpha, actively implementing the peer client against a real reference control plane.

PRE-ALPHA Repo → Rust · WireGuard (boringtun) · Noise protocol Noise handshake, control-protocol types, and TCP/TLS registration land in Phase A · hamma/README.md, Status section
hamma · handshake + control-protocol type tests · hamma-core, dictyon 0:45 · .tape

RECORDING FORTHCOMING: cargo test -p hamma-core && cargo test -p dictyon — the Noise-handshake and control-protocol-type tests passing

What this shows: The Noise-handshake and control-protocol-type tests passing — modest, explicitly test-suite-shaped, matching where the project actually is. What it doesn’t show: Two peers joining a tailnet. That moment doesn't exist yet — the WireGuard data plane isn't wired in; this recording won't stage a fake version of it.

What it is

hamma is a clean-room Rust implementation of a Tailscale-compatible mesh networking stack: the pieces needed to knot a set of devices into one flat network, speak WireGuard peer-to-peer, traverse NATs through DERP relays, and name each other through MagicDNS. It targets wire compatibility with Tailscale’s existing control plane, so a device running hamma can join the same tailnet as a device running the reference client. It exists because no production-grade Rust implementation of that protocol exists yet, and it’s meant to fill that gap both for this practice’s own systems and openly, for anyone who wants a memory-safe, auditable mesh client.

Decisions and trade-offs

Clean-room, not a port

hamma is written from the protocol spec and public behavior, not translated line-by-line from Tailscale’s Go client. No vendor blobs, no unsafe beyond what the underlying boringtun crate already audits. The trade-off: a clean-room implementation is slower to reach feature parity than a direct port would be, since nothing gets carried over for free. The reasoning: a port inherits whatever the original got wrong along with what it got right; a clean-room build only has to be correct against the wire protocol.

DecisionChoseRejectedCost accepted
Validation orderValidate dictyon against Tailscale’s actual production control plane firstBuilding the self-hosted histos server firstNo self-hosted option yet; Phase A depends on the vendor’s control plane
Feature scopePeer WireGuard, MagicDNS, exit nodes, ACLsMatching Tailscale’s full feature surface (Taildrop, SSH, Funnel, app connectors)Real features left out until there’s demand, not built speculatively

What’s solid / what’s open

Solid: the Noise handshake, control-protocol types, TCP/TLS registration, and the map-streaming loop, all landed as part of Phase A’s dictyon peer client.

Open, stated as the repo itself states it: pre-alpha, no releases yet, no stable API. The next implementation milestone is the WireGuard data plane via boringtun — until that lands, there’s no working end-to-end tailnet, and this page won’t imply otherwise. An open audit backlog tracks known gaps in map deltas, frame handling, node-key expiry, tracing, and map-stream integration coverage.

Numbers, and how they were measured

ClaimMethodWhere to check
4,091 lines Rust (code-only), 5,112 including commentstokei against a local clone, 2026-07-20reproducible: tokei on a fresh clone
2 workspace crates (dictyon peer client, hamma-core shared types)crate count in the workspace Cargo.tomlreproducible on a fresh clone

Smallest of the systems on this site, by design — the newest and least mature, not padded to look bigger than it is.

Where to look