ZDDC

Download ZDDC

Pick how you want to use it. Pick the version you want. Every link below points at a real, immutable file you can save into your archive — your tools, your version, forever.

Changes every download link below.

Path A — Self-host the server

One small Go binary. All five tools are baked in via //go:embed; the server picks the right one for each folder of your archive. Adds ACL via .zddc files, the virtual .archive document index, and SSO header passthrough. Stop the server and the directory is still a perfectly valid ZDDC archive — the server is convenience, not lock-in.

⬇ Download for Linux (x86_64) zddc-server_linux-amd64

After download: chmod +x the file, set ZDDC_ROOT=/path/to/archive, run. Need a different platform? Build from source at the matching tag.

Path B — Standalone tools

Every tool is a single self-contained HTML file. Open it locally and point it at a folder on your disk — no install, no server, no account. Same on-disk layout the server uses. Use one tool, use all five, mix and match — there is no orchestration to set up.

Archive Browser Browse and download from a ZDDC archive. Download → Transmittal Creator Build, sign, and verify transmittal packages. Download → Classifier Rename loose files to ZDDC convention. Download → File Browser Browse the project tree; includes the markdown editor. Download → Landing Project picker for multi-project servers. Download →

Your version, forever

Your server may run v0.0.8 next month and v0.1.0 the month after. Your project doesn't have to follow. If you depend on a specific behavior in archive v0.0.5, save that version into your archive — the next server upgrade can't take it away from you. Two ways to do it:

Drop a copy into your archive

Save the tool's HTML at the path the server would serve it from. The server's resolution order picks up real files first — before any cascade or embedded fallback.

curl -o MyProject/archive.html \
  https://zddc.varasys.io/releases/archive_v0.0.26.html

Now MyProject/archive.html is yours. The server serves your bytes; nothing about a future --release can change them.

Pin via .zddc

Less invasive — no copies in your archive, just a small config entry telling the server which version to fetch and cache. Closer-to-leaf wins, so subprojects can pin further.

# MyProject/.zddc
apps:
  archive: v0.0.26

Server fetches once on first hit, caches under _app/, falls through to the embedded copy if the fetch fails.

Your archive's tools are yours. The server is convenience; deletion of the server doesn't break your archive — every per-version download above is a real, immutable static file. Save what you trust.

Build your .zddc apps: block

Pick a channel or pinned version for each tool. The YAML on the right updates as you go — copy it into a .zddc file at the level of your archive where you want the config to apply. Closer-to-leaf wins, so a project subdirectory can override what its parent says.

Tip: leave a tool on stable if you don't have a reason to pin it. Pin specific versions when you depend on a behavior in that release. The server's resolution order is: a real file in your archive → .zddc apps: entry (closer-to-leaf wins) → embedded fallback.

Verify your downloads

Every artifact published here is signed with a long-lived Ed25519 key. You can verify any download against the public key using stock openssl — no special tooling. zddc-server verifies automatically when fetching tools via the apps: cascade once the operator configures ZDDC_APPS_PUBKEY — same posture as TLS certificates: the binary bakes nothing in, the operator points it at the public key they trust.

Public key

Download pubkey.pem

SHA-256 fingerprint of the DER-encoded SubjectPublicKeyInfo:

7766dc8cf963f32156ddcc96825c52ba0333ffe4c243ad54f9eaf26195b065ab

Verify the fingerprint after downloading:

openssl pkey -pubin -in pubkey.pem -outform DER | sha256sum

Verify a download

Each artifact has a matching .sig file alongside it (archive.html → archive.html.sig, etc.). Fetch both, then:

curl -O https://zddc.varasys.io/releases/archive.html
curl -O https://zddc.varasys.io/releases/archive.html.sig
openssl pkeyutl -verify -pubin -inkey pubkey.pem \
    -rawin -in archive.html \
    -sigfile archive.html.sig

Output is Signature Verified Successfully on a clean download. Any other output (or no output and a non-zero exit) means the bytes do not match the published signature — do not trust them.

Configure zddc-server to auto-verify

For server deployments, configure the public key once and the apps fetcher verifies every apps:-pinned URL automatically. Two equivalent ways — pick whichever matches how you already manage config:

Env var (k8s, systemd, Docker)

Save pubkey.pem on your server, then point zddc-server at it:

curl -o /etc/zddc/pubkey.pem \
  https://zddc.varasys.io/pubkey.pem

ZDDC_APPS_PUBKEY=/etc/zddc/pubkey.pem \
ZDDC_ROOT=/srv/zddc ./zddc-server

Fits the deployment shape where env vars are already the config plumbing — Helm chart values, systemd unit-file Environment=, Docker -e.

Inline in root .zddc

Paste the PEM contents under apps_pubkey: in the root .zddc:

# <ZDDC_ROOT>/.zddc
admins: [you@yourcompany.com]
acl:
  permissions:
    '*@yourcompany.com': r
apps_pubkey: |
  -----BEGIN PUBLIC KEY-----
  MCowBQYDK2VwAyEAXXaxIUIyOFnhD1eZs02nEt3xZ8izOi7bURFcpJ9iWZY=
  -----END PUBLIC KEY-----

Honored only at the root .zddc (root-only, like admins:). When both forms are set, the env var wins. Subtree .zddc files with apps_pubkey: are silently ignored — the trust anchor doesn't cascade.

When configured, the resolver fetches the .sig automatically on every URL-pinned apps: entry and rejects any unsigned or invalid-signature artifact, falling back to the embedded copy. Operators enforcing signature verification on locally-saved artifacts (Path A, "drop a copy into your archive") run the openssl verify command above as part of their save workflow.