Two modes, one archive
Local directory mode
Open a tool, click Add Directory, point it at a folder. The tool reads files directly via the File System Access API. No upload, no server, no account.
Enough for individual users and small teams on a shared drive (network share, Dropbox, OneDrive, syncthing).
Online mode
Take the same local directory and put it behind any web server (nginx, Caddy, Apache, even python -m http.server). The Archive Browser tool talks to the server's directory listings instead of the local filesystem.
Read-only, no special server software, works in any browser.
That's it. Same on-disk layout, two access mechanisms. The convention is the contract; the mode is an access decision.
What zddc-server adds
zddc-server is a small Go binary built specifically to serve ZDDC archives. It is a web server, so it gives you online mode out of the box — but it adds things a generic web server can't:
- If the server reads email headers, it can enforce access control. Behind any reverse proxy that authenticates users (Authelia, oauth2-proxy, your own SSO) and sets an
X-Emailrequest header, zddc-server consults.zddcYAML files in directories. Cascading bottom-up; deeper rules override shallower ones. No database, no admin UI — edit the files with any text editor. - Virtual
.archiveURL space.GET /Project/.archive/123-XYZ.htmlresolves to the canonical revision file (the one in the chronologically earliest transmittal that contains it). Computed from filenames at request time — no cache, no separate index file. Restart the server and it rebuilds. - Per-request access logging keyed to the authenticated user's email — method, path, status, bytes, duration.
- TLS, ETags, conditional GET, CORS, autoindex. The mundane glue that makes a directory pleasant to serve.
In short: any web server can do online mode for reads. zddc-server adds ACL, a virtual archive index, and audit logging while remaining a thin wrapper around the same directory.
Still just files in folders
The on-disk layout is the same whether you access locally or online. The server doesn't transform the archive — it serves it. Stop the server and the directory is still a perfectly valid ZDDC archive that opens in local-directory mode.
ZDDC_ROOT/
index.html ← landing tool
archive.html ← archive browser
transmittal.html
…
Project-001/
.zddc ← ACL (optional, YAML)
2025-10-31_123456-EM-MDL-0001 (IFR) - Master Deliverables List/
123456-EM-MDL-0001_A (IFR) - Master Deliverables List.pdf
2025-11-12_123456-EL-SPC-2623 (IFR) - Specification For Switchgear/
123456-EL-SPC-2623_A (IFR) - Specification For Switchgear.pdf
Project-002/
…
This keeps the "Zero Day" promise: the server is convenience, not lock-in. Walk away from zddc-server tomorrow and the archive is still a perfectly valid convention-named folder tree, fully usable with nothing more than a file manager.
Get it
The server lives at codeberg.org/VARASYS/ZDDC under zddc/. Operations and configuration — environment variables, TLS modes, the .zddc ACL syntax, the virtual archive index URL patterns, container vs native binary deployment — are documented in zddc/README.md.
Quick start (with podman available):
git clone https://codeberg.org/VARASYS/ZDDC.git cd ZDDC/zddc ZDDC_DATA_DIR=/path/to/your/archive podman-compose up --build
For the deployment-side install of the tools onto a zddc-server instance — including the level-1/level-2 bootstrap pattern, install.zip, and the channel-tracking track-*.zip bundles — see bootstrap/README.md.