zerotea

zerotea is a from-scratch Zig implementation of the ZeroTier network-virtualization protocol.

Status: early. The crypto tier is in progress. This is a research build. Do not use it for anything real. The daemon runtime does not exist yet. zerotea --version is the only contract so far. Nothing here is production ready. No such claim will be made without end-to-end proof.

Why this repo exists

An older Zig port of ZeroTier exists. An LLM grew that port to 6,817 commits by iterating on it locally, without validation, for a long time. zerotea is a deliberate counter-experiment. It rebuilds the same protocol with proper CI/CD as the development method:

• Every commit is validated in a build pipeline. It never merges red code.
• Every decoder gets constant fuzzing. The fuzzing is property-based, seeded, and reproducible.
• Releases happen occasionally and only pass wider functional tests.

The old port serves only as a reference oracle. It gives guardrails and clues, nothing more. The open question is this: does disciplined CI/CD produce a measurably different commit-history shape than letting a chatbot chew on the code forever? The comparison is tracked in docs/METHODOLOGY.md.

Not clean-room; MPL-2.0

zerotea is a derivative work of ZeroTierOne (MPL-2.0). It is distributed under the same license (see LICENSE and NOTICE). It is not clean-room. The reference code was visible while the authors wrote zerotea. MPL-2.0 permits derivation, so a clean-room claim is not needed and is not made. Crypto test vectors come from public standards.

Build

zig build test          # unit tests (KATs, round-trips)
zig build fuzz -- --budget=30s   # run every decoder's fuzz target for 30s
zig build && zig-out/bin/zerotea --version

This build requires Zig 0.16.0 or later.

Development

Binjovi validates each pull-request revision before it can enter trunk. A combined Release Build tests the exact integrated revision, creates the amd64 and arm64 archives and packages, and publishes signed APT and DNF repositories. The package installers receive no storage or signing credentials. The public package set is the released product, so this project has no Deploy phase.

The versioned build and install-test recipe is in sean/binjovi-plans. A recipe change does not require a Binjovi control-plane deployment. The native graph builds both architectures independently and runs Debian and Alma package tests in parallel. Each Build and Release keeps its selected recipe revision fixed for repeatable recovery.

Push a feature branch to code.sean.farm/sean/zerotea, open a pull request against trunk, and wait for binjovi/ci. Select that green Build in Binjovi when the change is ready for a Release. See docs/METHODOLOGY.md for more detail.

Native pipeline timing

Native tasks build architecture-specific packages and run Debian and Alma install checks. The pipeline ends at the verified package Release. This project has no configured Deploy target.

Open the project dashboard and expand an execution attempt for the task timeline and available CPU, off-CPU, and syscall profiles. Cached BuildKit steps still appear as cached work; a missing sample does not prove that a task used no CPU.

Select an exact successful Build with binjovictl release zerotea --build BUILD_ID --wait. Then use binjovictl status zerotea to check its release and any configured deployment. Telemetry explains time spent; immutable artifact and revision evidence establish completion.