DEV Community: arcker

cidx v3.0.0 — deleting the things that lied

arcker — Sun, 09 Aug 2026 09:38:22 +0000

cidx is a declarative CI/CD runner I build (in Go) — you describe your pipeline once, it runs the same locally and in CI. This post stands on its own.

Here's how the week started. A public Docker image, on GitHub Container Registry. A clean ENTRYPOINT ["cidx"]. Release after release, green CI every time.

And no binary inside. Not once. Ever.

.dockerignore excluded bin/. The Dockerfile did COPY bin/cidx /usr/local/bin/cidx. So the path was absent from the build context, kaniko matched nothing — and did not error. Green pipeline, published release, ENTRYPOINT pointing at a file that wasn't there.

No test and no code review could have caught it. Everything, at every step, looked like it worked.

That's the best illustration of what v3.0.0 turned out to be — cidx's first major since v2.0.0. Five breaking changes, 70 commits, 55 issues closed in seven days. And reading them back cold, they all tell exactly the same story.

Five breaking changes, one motive

A breaking change usually removes something ugly, or renames, or modernises. Not here. Each of the five removes a feature that looked like it worked.

1. local_behavior = "no-push" — a dry-run with a promise it could not keep.

The documentation said:

local_behavior = "no-push" ✅ Recommended for Docker
Build without push — validates the Dockerfile and build process

The code said otherwise: no-push set IsDryRun, exactly as dry-run did. The command was never handed to a backend. Nothing was built. The two modes were behaviourally identical, and the one promising more was the lie.

2. [branch] auto_cleanup — parsed, and read by nobody.

A config key that existed, was accepted, was documented. No code ever consulted it. You'd set it, re-run, nothing happened — and nothing said so.

3. Unknown cidx.toml keys — a typo indistinguishable from a valid setting.

[branch]
stale_dayz = 15          # typo of stale_days
typo_key = "whatever"    # not a key at all

$ cidx validate
✓ Configuration is valid

stale_days silently kept its default of 30, and nothing said why. You had configured something. The tool confirmed it was valid. It wasn't.

4. go-test didn't run every package. The preset tested less than it appeared to. The green bar described a wider scope than the real one.

5. The cidx action command tree — removed after a 3.5-month deprecation window. The only ordinary one of the five: it removes something announced as leaving, not something misleading.

Four out of five, then: not quality defects — honesty defects. A tool that prints ✓ valid over a typo doesn't waste your time by being slow. It wastes it by earning your trust.

Why they were findable now

These things don't show up by reading code: everything compiles, everything passes, everything is green. You need a mechanism that actively hunts the gap between what is promised and what happens.

The no-push lie was caught by a BDD sweep: a scenario asserted "the Docker image should be built" locally under no-push… and that scenario could never have passed. It wasn't code indicting code — it was a written promise held against real behaviour.

Same for the empty image: found while replacing the kaniko image, and confirmed pre-existing — identical on the old version, so not a regression. Nobody was looking for it; someone went and checked.

This is the direct sequel to what I wrote in July: cutting a release with the tool's own release command produced seven papercuts, all filed the same day. That was the thesis; this is the demonstration at major-release scale. Those seven are closed, along with forty-eight more.

The load-bearing one: `/v3`

One breaking change wasn't a deletion. The module path moved to github.com/cidx-org/cidx/v3 — without it, v3 tags simply aren't go installable. That's the Go modules rule: from v2 on, the major version is part of the path. Skip it and you publish a major nobody can install.

And the guardrail that came with it, in the same spirit as the rest: release create now refuses to cut a major the current module path cannot publish — rather than letting the tool produce a dead tag with a smile.

What it teaches

The same pattern showed up elsewhere the same week, in another project. In Verbose, the worst defect closed this week: the self-hosted compiler silently dropped every rule after any top-level item it didn't recognise — and exited 0. Your code wasn't compiled, and you were told everything was fine.

Two projects, two domains, one week, the same underlying defect: success reported while the work never happened.

A tool doesn't become reliable by accumulating features. It becomes reliable when you remove the ones that pretend. A deleted no-push is more honest than a no-push claiming to validate a build; a cidx.toml that rejects an unknown key is more useful than an agreeable ✓ valid; a missing image would have been less harmful than a published, empty one.

And the limit, named as usual: five issues remain open, all design questions rather than bugs. v3.1.0 landed the next morning (tag-rebuild detection, digest-pinned scanners, refusing to merge onto a commit the remote doesn't have). The pace will drop — two back-to-back sprint weeks is a window, not a cadence.

What's left is a simple triage rule going forward: when a feature and its documentation disagree, the documentation isn't the first thing to fix. The first question is how long you've been believing it.

French original on arcker.org.

943 bytes that answer HTTP

arcker — Sun, 02 Aug 2026 07:51:58 +0000

Verbose is a small experimental language I build — its compiler proves properties about your code (termination, sound types, declared effects) and emits tiny x86-64 machine code: no runtime, no GC, no libc. This post stands on its own.

Picture a 943-byte file. Smaller than a long text message. You run it and send this:

GET / HTTP/1.0

It answers:

HTTP/1.0 200 OK
Content-Length: 29

Hello from Verbose over HTTP!

No Node, no Python, no nginx in front. No runtime, no garbage collector, not even the C library. 943 bytes, alone against the network.

And that's not even the interesting part. That binary was written by a compiler which is itself written in Verbose — the one that, last month, reproduced itself byte for byte. The language no longer merely compiles itself: it now produces the kind of program people actually write.

Serving HTTP when you have nothing

The analogy first, before any jargon.

You open an office. To receive clients you need four things, in this order:

Get a phone line installed. No number yet, just the handset.
Get a number — 18893. Now people can reach you.
Lift the handset and put it on the desk: you're reachable, calls can queue up.
Take the calls, one at a time. Each one: listen, answer, hang up. Then take the next.

That is exactly what a server does, with four calls into the kernel:

  socket()      →  "install me a line"                → returns a file number (fd)
  setsockopt()  →  "when I hang up, free the line      (SO_REUSEADDR)
                    immediately, don't hold it
                    blocked for a minute"
  bind(18893)   →  "my number is 18893,                (INADDR_ANY = on every
                    on every line"                      network interface)
  listen()      →  "handset off the hook: queue
                    incoming calls"

  ┌── loop, forever ──────────────────────────────────┐
  │  accept()   →  take the next call                 │
  │                (waits if there is none)           │
  │  read()     →  listen to what the client says     │
  │  write()    →  answer                             │
  │  close()    →  hang up THIS call                  │
  └──────────────── and start over ───────────────────┘

That's it. There is nothing else in an HTTP server. Everything you know — Express, Flask, Spring — is a comfort stack on top of those four lines. The comfort isn't useless, but it isn't necessary: that's why 943 bytes are enough.

The first slice (S1) does precisely that and no more: the handler returns a response written ahead of time, the same for everyone. It's the smallest object still deserving the name "server".

The pivot: reading what the client said

A server that always answers the same thing is an answering machine. To go further you must understand the request. That's slice S2 — the pivot of the whole arc: nothing after it exists without it.

The client sends a run of bytes. Raw. Two pieces of information have to be cut out of it:

  What arrives on the wire (bytes):

    G  E  T     /  h  e  l  l  o     H  T  T  P  /  1  .  0  \r \n \r \n
    └──┬──┘  ▲  └────┬────┘       ▲
       │     │       │            │
       │   space     │          space
       │             │
    method          path

  What the parser extracts, into two "slots":

    req.method  →  pointer to "GET"     + length 3
    req.path    →  pointer to "/hello"  + length 6

One detail that matters: nothing is copied. We only note where it starts and how long it is. The bytes stay where the kernel dropped them. An address and a length — two numbers — not a string copied somewhere else.

Those two slots, req.method and req.path, are the raw material for everything that follows.

Answering differently per request

Slice S3: routing. Once you know what was asked, you can answer differently. Then S4: build the response body from the request.

Here is a real example from the repo (examples/echo_path.verbose), trimmed:

rule echo_handler
  input:
    req : HttpRequest
  output:
    resp : HttpResponse
  logic:
    resp = if req.method == "GET"
             then HttpResponse { status: 200, body: concat("got GET on ", req.path) }
           else if req.method == "POST"
             then HttpResponse { status: 200, body: concat("got POST on ", req.path) }
           else
             HttpResponse { status: 404, body: concat("unsupported method ", req.method) }
  proofs:
    purity:
      reads : [req.method, req.path]

service echo_server
  listen:
    protocol    : http_1_0
    port        : 18893
    max_request : 4096
  handler: echo_handler

Walk one call through, concrete values at every step:

  1. Client sends     :  "GET /hello HTTP/1.0\r\n\r\n"
  2. Parser fills     :  req.method = "GET"   req.path = "/hello"
  3. Rule evaluates   :  req.method == "GET"  →  true, first branch
  4. concat assembles :  "got GET on " + "/hello"  →  "got GET on /hello"
  5. Binary writes    :  HTTP/1.0 200 OK
                         Content-Length: 17

                         got GET on /hello

Note the proofs: block. It declares: this rule reads req.method and req.path, and nothing else. That's not a comment — the compiler checks it. If the logic read a third field without declaring it, it wouldn't compile. The language's standing promise: the author declares, the binary doesn't drift.

And the concat in step 4 deserves a note. Until S4, the response body had to be written ahead of time. From S4 on it is assembled at call time — and its buffer lives on the iteration's stack. The loop frees it in one instruction before the next call, whichever branch ran. No allocation, no deallocation to track, no possible leak.

The detail that lands: one log line, one syscall

Slices S5a and S5b: the server now writes its access log. And that's where the most instructive part hides.

A log block looks like this (real example, examples/audit_strict.verbose):

log:
  append_file "/tmp/audit.jsonl"
    concat("{\"method\":\"", req.method, "\",\"path\":\"", req.path, "\"}\n")
  on_error: abort

The first implementation did the obvious thing: one write() per piece of the concat. Disassembling the compiled binary showed it plainly — four successive writes:

  0x202  open      ← open the file
  0x217  write     ← "{\"method\":\""
  0x23a  write     ← "GET"
  0x24c  write     ← "\",\"path\":\""
  0x26f  write     ← "/hello\"}\n"
  0x279  close     ← close

It works. As long as there is exactly one client.

Now two requests arrive at once. The kernel may interleave their writes — it has no reason not to:

  What you wanted:
    {"method":"GET","path":"/hello"}
    {"method":"POST","path":"/submit"}

  What you can get:
    {"method":"GET","{"method":"POST","path":"/hello"}
    path":"/submit"}

Two corrupted lines. Neither is true. And it's the worst kind of bug: it doesn't show up in development (one client), it doesn't crash anything, it only appears under load now and then — and it damages precisely the file you read to understand what happened. An audit log that lies under load is worse than no log at all.

The fix (PR #138): replace the N writes with one writev. Same idea as an envelope. Instead of mailing four sheets separately and hoping they arrive in order, you put them all in one envelope and mail that. The postman can no longer shuffle them with the neighbour's.

  BEFORE — 4 calls, interleavable          AFTER — 1 call, atomic

  write(fd, "{\"method\":\"", 11)          iov[0] = ("{\"method\":\"", 11)
  write(fd, "GET",             3)          iov[1] = ("GET",             3)
  write(fd, "\",\"path\":\"",  10)         iov[2] = ("\",\"path\":\"",  10)
  write(fd, "/hello\"}\n",      9)         iov[3] = ("/hello\"}\n",      9)
                                           writev(fd, iov, 4)
  open → write → write → write → write     open → writev → close
       → close

The iov array (four address + length pairs) is built on the stack, and syscall 20 consumes it in one go. All or nothing: the whole line is written, or none of it is. Never half.

It looks like an optimization detail. It is one — six syscalls down to three. But above all, it's a change of guarantee: the log file becomes a sequence of complete lines, by construction, under any concurrency. And it's the prerequisite for the next slice, on_error: abort — "if I can't write the audit trail, stop everything". That promise means nothing if a line can already come out cut in half.

What it means

The seven slices:

  S1   a server that always answers the same        → 943-byte ELF
  S2   parse the request (method, path)             → the pivot
  S3   route on method and path
  S4   build the body from the request
  S5a  write log lines
  S5b  logs containing request fields
  5b.5 one line = one writev = atomic

In six days the self-hosted compiler went from "it can reproduce itself" to "it can produce a web service that parses, routes, answers and traces". Those are very different things. The first proves the language stands up; the second proves it's good for something.

And the limit, named as usual: v0.10.0 still isn't tagged. main is 54 commits ahead of v0.9.0 — the fixed point, the verifying bootstrap, the effects tier, and now the service arc. There's a release-shaped moment there, ripe for weeks. It's waiting on a decision, not on code.

943 bytes that answer HTTP. Written by a compiler that wrote itself. No runtime, no libc, and logs you can believe.

French original on arcker.org.

probatum — your tests pass. does it actually boot?

arcker — Sun, 26 Jul 2026 07:58:47 +0000

probatum is a test-oriented check runner I build (in Rust) — one config file, embedded checks (curl, grep and process supervision built in), and only the failures that matter surfaced. This post stands on its own: it's about why I wrote it next to cidx, my CI/CD runner.

Here's the itch. Your test suite is green. 142 tests pass. You tag, you deploy. And the app doesn't boot — because the tests mocked the store, and the real boot replays the WAL, and one segment is missing. No test ever touched that path.

That gap — between the tests pass and it actually stands up — is the whole reason probatum exists.

What probatum checks (that tests don't look at)

One file, probatum.yaml. Flat checks, no logic. The curl, the grep, the process supervision are embedded — you just declare the rules that make a check pass or fail.

# start the real service, wait until it answers, keep it alive for what follows
- name: api boots
  run: ./target/debug/myapp --port 8080
  ready: http://127.0.0.1:8080/healthz
  timeout: 15

# embedded curl
- get: http://127.0.0.1:8080/api/version
  expect: 200
  contains: ['"version"']

# embedded grep — only the lines written DURING this run
- name: app log is clean
  log: /var/log/myapp/app.log
  absent: ["ERROR", "panic"]

probatum starts your real system, interrogates it, reads its logs — then kills the whole process tree on every exit path: normal end, probatum's own panic, Ctrl-C, SIGTERM. If probatum dies, nothing it started survives. No zombie port between runs, no orphan server hanging around.

And the contract that every hand-rolled bash script is missing:

failed (exit 1) ≠ couldn't observe (exit 2).

A missing binary, an unreachable URL, a dirty environment — that's not a bug in your code, that's "I couldn't look." Conflating the two makes you chase ghosts. probatum refuses an already-dirty environment (the port answers before the service starts) instead of destroying it: it never purges what it doesn't own.

The rest is the noise filter: panic, traceback, FATAL caught by default; and humble when unsure — it shows the tail of the output and says "exit 1", it never invents a cause. A false cause is worse than no cause.

Why not just a cidx stage?

The real question. I already maintain cidx, a declarative CI/CD runner: it runs tools against my code (trivy, gitleaks, go-test), identically local and in CI, grouped into phases and pipelines. So why a second tool?

The honest admission first: both can run an arbitrary command. A cidx stage could script the same checks. But they don't verify the same object:

  cidx  ──▶  the CODE, statically
            (which scanners/linters/tests run, local == CI)

  probatum ──▶ the RUNNING SYSTEM, dynamically
            (boot, readiness, HTTP behavior, log window, teardown)
            ← cidx has none of that machinery

The sharing rule is one line: run a tool against my sources → cidx stage. Start my system and observe its behavior → probatum.

So no merge. probatum joins the roster of tools cidx orchestrates — like trivy, like go-test — linked by a preset. One source of truth, two launchers:

  probatum.yaml  ← one file
      │
      ├── inner loop (a dev or an agent, in seconds) : probatum run
      └── outer loop (CI, pipeline)                  : cidx run test

And the guardrail — the actual design decision: if probatum grows phases and pipelines, it's becoming cidx → refuse. If cidx grows readiness and process ownership, it's becoming probatum → same. The boundary isn't an accident, it's held on purpose. Two small tools that each do one thing and keep their edge.

The proof engine with nothing to prove

Confession: probatum didn't start like this. It was born a "proof engine" — promises, oracles, an evidence registry, the whole vocabulary of formal verification. Impressive on paper.

I cut it. That vocabulary was overhead, not value — grandiosity around a simple need: one line, one file, run my checks, show me only what matters. A proof engine that, in the end, had nothing to prove — just something to make useful. (Yes, the pun is cheap. It's also exactly what happened.)

Dropping the word "proof" is the same discipline as everywhere in these projects: name the limit, throw out the vocabulary that inflates. A tool earns its words; it doesn't borrow them from theory to look impressive.

The real first reader is the agent

What drove the cut: probatum's first reader isn't a human scanning a terminal. It's an AI agent (and the human over its shoulder).

An agent chaining fifty ad-hoc bash runs drowns in output and piles up orphan servers on port 8080. probatum hands it one verdict (probatum run --json) and owns everything it starts — so you can loop it tight without cleaning up behind it. That's the differentiator versus "just run bash": process ownership, the collapsed verdict, and the evidence trail to replay. A misspelled YAML key is an error, never a silently skipped check — because an agent believing it tested something it didn't is the worst lie of all.

Where it actually stands

probatum is twelve days old. v0.1.0, 21 commits, a ~1 MB static binary, a 14 MB image, zero external contributors, zero users besides me. It's not on crates.io — I haven't decided to claim the name yet.

What's solid today: the contract is frozen (sources × flat rules, exit 0/1/2, process ownership on every exit path), it tests itself — the root probatum.yaml builds, lints, runs the demo end-to-end and asserts the negative scenarios are actually caught — and it runs inside cidx 2.1.0 as a test-phase preset. The two dogfood each other: cidx's pipeline runs inside probatum, probatum ships as a cidx preset. Each has already found bugs in the other.

What's not done: everything else. This is a v0.1.0, and this post is about its boundary, not its maturity.

The ecosystem I'm aiming at

The map, then: cidx orchestrates the outer loop, probatum verifies the running system in the inner loop. They dogfood each other — cidx's pipeline runs inside probatum, probatum ships as a cidx preset — both are built for the agent, and each refuses to become the other.

It's not a platform. It's a toolchain where every link does one thing, stays replaceable, and is honest about its edge. The bet isn't in the size of each tool — it's in the boundaries between them, held on purpose. probatum is one more link: the one that answers, once the tests are green, the only question left — sure, but does it actually stand up?

French original on arcker.org.

cidx v2.1.0 — the most useful output of a release was its seven bug reports

arcker — Sun, 19 Jul 2026 08:56:20 +0000

cidx is a declarative CI/CD runner I build (in Go) — you describe your pipeline once, it runs the same locally and in CI, exit-code parity guaranteed. v2.1.0 just shipped. And the most useful thing it produced wasn't the tag.

The interesting part of a release is almost never the changelog. It's what cutting the release teaches you.

The short part (the diff)

11 commits since v2.0.0, after 59 quiet days. A probatum test-phase preset, a pr edit action (retitle a PR without dropping to the platform UI), and six fixes: prebuilt cargo-audit (faster security phase), anonymous-pull fallback when a registry 401s on stale creds, pinning the bootstrapped cidx to the version that generated it (no more @latest drift), cpw waiting for the CI workflow to actually start, branch prefixes derived from commit type, and check drift resolving the workflow file instead of guessing .github/workflows/ci.yml. Correct, useful, boring. On to the real story.

Cutting a release with your own tool

cidx can cut a release: cidx release create. So I used it to cut its own. And that's exactly where it gets interesting — a tool on a tidy demo never shows its rough edges; a tool on a real, high-stakes task (tag it, push a version) shows them all.

Seven, that day. Filed same-day, tag still warm:

#184 — release create pushes the version-bump commit straight to main… and gets rejected by branch protection. Recovery is a hand-rolled PR-then-cherry-pick-then-tag. The tool doesn't know the rules of the repo it runs on.
#185 — release preview computes the version from three sources (VERSION, .cz.toml, latest tag) with no reconciliation. First run: it suggested v1.8.0 when the latest tag was v2.0.0. A single source of truth was missing.
#186 — release tag prepare waits on an editor with no TTY detection. It hangs.
#180 — cpw reports "nothing to commit" for untracked files.
#178 — cidx's own cidx.toml now has real drift — precisely because fix #177 finally lets check drift see it: docker and release phases declared, no matching jobs in ci.yml. The tool finding its own mismatch.
#175 — breaking-change detection reads type!: from parsed commits, but the parser regex can't capture the !. Latent bug.
#174 — ~20 CLI hints still point at the deprecated cidx action … namespace.

None of those show up reading the code. Each is a knot you only feel by pulling on the rope for real.

The loop working, not the loop breaking

cidx's CLAUDE.md states a rule: "we eat our own cooking; if a command has bad UX, that becomes the next priority." v2.1.0 is that sentence in action. The release ships, and the release-tooling backlog grows the same day. That's not a release failure — it's the only honest way to know where the tool hurts: take it seriously on its own most sensitive task.

And here's the nuance. Everyone says "we dogfood — we use our own tool." The honest version is different: you use it on the scary thing, and you write down, publicly and same-day, every place it bit. The rough edges aren't swept under the rug waiting for a user to find them. They're the roadmap — dated, numbered.

What's next

The v2.1.0 → v2.2.0 backlog is already those seven issues plus the #178 drift call. The next release will be quieter on features, heavier on release plumbing: TTY detection, one source of truth for "current version", protection-aware push routing, the deprecated-hint sweep. Small releases, tight loop — and each turn, the tool knows a little better where it hurts, because we dared to use it where it counts.

French version on arcker.org.

The fixed point: a compiler written in its own language just reproduced itself, byte for byte

arcker — Sun, 12 Jul 2026 09:08:49 +0000

Verbose is a small experimental language I'm building — its compiler proves properties about your code (termination, sound types) and emits tiny x86-64 machine code, no runtime, no GC, no libc. This post stands on its own. The news: the compiler, written in Verbose itself, just reached the classic self-hosting fixed point — it reproduced its entire self, byte for byte.

Photocopy a photocopy of a photocopy and each generation degrades. Except there's a magic case where the copy is perfect — identical to the original, forever. That's a fixed point: applying the operation once more changes nothing. Every language whose compiler is written in itself eventually faces one question: the version of me I just produced, when asked to produce me, does it produce exactly me? On 2026-07-11, Verbose answered yes, to the byte. And it's on main now — not a branch — 18 commits closing the arc opened June 13.

Three generations

  gen0  ← the Verbose emitter, compiled by the Rust host compiler.
          (what a fresh checkout builds)
            │  feed it the 855 KB of Verbose source
            ▼
  gen1  ← the emitted ELF: the Verbose emitter, but compiled BY Verbose.
            │  feed it the SAME 855 KB source
            ▼
  gen2  ← the ELF gen1 emits in turn.

  The gate:   gen1  ==  gen2   (byte for byte)

gen0 is the Rust-built bootstrap. gen1 is Verbose compiled by itself once. gen2 is Verbose-compiled-by-Verbose compiling itself again. Verdict: gen1 == gen2 == 1,302,980 bytes, same sha256 001481eb…. Not "it works" — the same binary, bit for bit, two generations running. Verified by an #[ignore]d regression test (needs ~9 GB RAM, ~30 s).

Why byte-identical, not just "it compiles"

"It compiles" only asks for a binary that runs. The fixed point asks more: that the compiler, reproducing itself, doesn't drift by a single byte. If it drifted — even one bit — gen1 and gen0 wouldn't be the same compiler; one would emit something the other doesn't. Byte-identity proves the language stands on its own floor: from here, Verbose no longer needs Rust to rebuild itself identically.

What almost stopped it — and why the diagnosis is the real story

A first attempt crashed. Hypothesis: a 32-bit integer overflow in the emitter's counters. Reasonable, given the input size. It was wrong — and it's written up as wrong in the commit, not quietly dropped. ptrace + objdump at the actual faulting address gave the real cause: arena exhaustion. The faulting instruction wrote a node 40 bytes past the 1 GiB arena. 10.3M nodes × 104 bytes = exactly the limit, crossed by 40 bytes. Not a wild pointer — a clean overflow at the boundary.

Why does gen1 overflow when gen0 holds, on the same input? Two different memory models:

  gen0 (Rust backend)          gen1 (self-hosted emitter)
  stack-passes records         arena-stores EVERY record AND variant
  reuses the space             never reclaims
  ~1.5M nodes at peak          ~84M nodes, ~8.7 GB RSS at peak

gen0 works on a whiteboard it wipes as it goes; gen1 writes in a notebook it never tears a page from. Fine for a factorial; it overflows compiling the whole compiler.

The fix — and the fix that waits, on purpose

PR #102's fix is small: the emitter's ELF prologue now mmaps 16 GiB with MAP_NORESERVE. Reserving is free — like reserving a whole parking lot but paying only for the spots you actually use; only the ~8.7 GB actually touched costs RAM, and small programs touch almost none.

But the real memory fix (dedupe an O(sites × program) recompute, reclaim the arena between procedures) is documented and explicitly deferred. It would melt the 8.7 GB peak toward gen0's footprint. It would not change the byte-identical output.

That decoupling is the point. A classic trap in self-hosted-compiler milestones is coupling the correctness proof to a specific optimization. Here they're separate: byte-identity is a semantic property of the emitter, and it holds today; the memory footprint is a resource property, and it improves later. The proof doesn't depend on the perf. Same discipline as everywhere in these projects: name the limit instead of hiding it — the 8.7 GB peak, the O(sites × program) recompute, all written on the same commit that ships the fixed point.

What it means

The full chain the project was built toward is now demonstrated in itself: parse → verify (four proofs: lints, sound types, purity, termination) → interpret → emit → self-compile byte-identical → reproduce its entire self. The self-hosted checker verifying its own proofs, the self-hosted emitter emitting its own ELF, and the byte-identity gate between generations — three claims holding at once. A perfect photocopy of itself, twice over. Verbose stands on its own.

Full version (in French) on arcker.org.

lithair 1.0 — I'm here, and yet

arcker — Sun, 05 Jul 2026 14:00:48 +0000

lithair is a memory-first Rust web framework I'm building — one compiled binary serves the frontend, runs the cluster, and is the database, event-sourced, no external services when the working set fits. This post stands on its own. Eight weeks after v0.2, it hit 1.0. And I want to be honest about how that actually feels, because it isn't a story about code.

The tag is cut. v1.0.0. I should be celebrating, and instead I'm looking at the screen thinking there's still stuff left. That it isn't quite finished — even though it's tested end-to-end, soaked in production under real traffic, and survived its own upgrade without losing a single record. Objectively: solid. Subjectively: I don't quite believe it yet.

It took me a while to understand why.

What the distrust is actually rating

It isn't rating lithair. The numbers are there: the measured cluster envelope, backup proven by actually restoring, eight roadmap gates closed one by one. The distrust is rating something else — what it is to put something you care about out there under your name.

There's the small voice: "an AI wrote it anyway." And it's true an AI generated a lot of the lines. But a framework isn't its lines — it's its decisions. Choosing to publish the cluster's envelope instead of claiming infinite scale. Making the admin secure by default. Naming the limits instead of burying them. Deciding, after two years, what to build and — more importantly — what to refuse. The AI typed. The idea, the calls, the standard — those are mine. Typing isn't authorship.

And there's the question of whether it gets seen. But I have to be precise here, because this is where I could misrepresent myself: I didn't build it to break through. I built it for myself — to propose my vision and see it hold. People showing up would please me; it was never the goal, and I'm not waiting on it. Traction is a lottery anyway — timing, luck, network. Pinning two years of work to a draw I don't control would be handing my peace to chance, when the real reward is already here: the vision exists.

What's actually there

So I strip the feeling and look at the thing.

Two years ago, lithair was an idea. One stubborn idea: what if a single binary could serve the site, run the cluster, and be the database? Not three services, not six layers, not an infra to operate. A compiled binary, state in memory when it fits, history in an event store, security close to the runtime.

Today that idea compiles. It runs. It's tested. And it holds this very site on its own — three sites, one binary, secure admin, hot-reload. Website, cluster, database, in the same executable. The all-in-one isn't a line on a slide anymore; it's a process with a PID that replays its log on boot and serves pages. That's not nothing. That's the whole thing.

Honest about what remains

A 1.0 isn't a finish line. It's "the floor is solid enough to build on." Optimizations remain — compute throughput, true zero-downtime on a binary upgrade (today it's a brief graceful restart, which I wrote in the docs instead of pretending otherwise). But the starting base is the right one: a stable API contract, on-disk format unchanged since 0.13, and what's there is measured and documented — limits included. That's what I always meant by "production-ready": not "it does everything," but "the envelope is measured and written down." The load plate, bolted to the wall.

What no one can take

The AI codes at the start. Then the rest — the standards, the judgment, the ecosystem built around it, the two years. lithair is just one exhibit of that, next to my other projects. And the idea from two years ago — an all-in-one that holds — is here. Really here.

Maybe I don't quite believe it yet. But it exists now. And that, no one can take from me.

A compiler written in its own language just emitted a standalone Linux executable

arcker — Sun, 21 Jun 2026 08:47:45 +0000

Verbose is a small experimental language I'm building. Its compiler proves properties about your code — like termination — and emits tiny, readable x86-64 machine code: no runtime, no GC, no libc. This post stands on its own (you don't need the rest of the series). What it's about: a compiler written in Verbose itself reached the point where a single rule emits a standalone Linux ELF that runs and prints its answer.

Honesty first: this lives on a working branch — not merged, not tagged. It's verified (green test suite, real in-memory execution, a measured benchmark), but it isn't in a released version, and it covers a sub-language (scalar arithmetic), not all of Verbose. More on that at the end.

Two halves of a compiler

A compiler has a half that reads (text → tokens → tree) and a half that writes (tree → machine code). The reading half is the usual story. The new part is the writing half — and the thing that makes it interesting here is that the code generator is itself a Verbose rule. The Rust compiler underneath (verbosec) only runs it; the machine code is emitted by rules written in the language.

Follow factorial all the way down

@proof termination decreasing : n
rule fact (n : number [0, 20]) -> number {
  if n == 0 then 1 else n * fact(n - 1)
}

Note the guardrails that survive all the way to the bytes: @proof termination decreasing : n (the compiler requires proof the recursion ends) and [0, 20] (the declared domain of n). The generator walks this tree and emits, per node:

  n == 0              cmp ; sete            → boolean in a register
  if … then … else …  jz over_then ; <then> ; jmp end ; over_then: <else> ; end:
  n * fact(n - 1)     <compute fact(n-1)> ; imul
  fact(n - 1)         call <offset>         → it calls itself

The jumps carry computed offsets: you only know a jump's distance once both branches are emitted, so the generator runs twice — measure, then write — the way you number a book's pages only after laying it out.

The milestone is that call/ret. When fact calls itself, it's a stack of plates you build up, then unwind while multiplying:

  build up                   unwind (ret)
  fact(3) n=3                3 × 2 = 6   ◄── final
   └ fact(2) n=2             2 × 1 = 2
      └ fact(1) n=1          1 × 1 = 1
         └ fact(0) n=0 ─► 1  (base case)

This is the first time a rule written in Verbose emits machine code that references itself.

From a byte blob to a real executable

Bytes in a buffer don't run on their own — you have to wrap them so Linux will launch them. That wrapper is the ELF format, and the rule now generates the whole thing, like a ready-to-ship parcel:

  ELF64 header         ← "this is a Linux executable"
  LOAD program header  ← "map this into memory, r+x"
  _start               ← call main ; rax → itoa ; sys_write ; sys_exit
  code for main, fact  ← the computation itself

No sections, no symbols, no linked library. A few hundred bytes. The last brick added itoa (int → decimal ASCII) in machine code — without it the binary computed 120 but couldn't show it. Now:

$ ./verbosec examples/factorial.verbose --run lower factorial 5 > a.out
$ chmod +x a.out
$ ./a.out
120

Standalone — no verbosec needed to run the result.

The honest benchmark

The long-standing question — "what does a binary built this way actually buy versus C/Rust/Go?" — finally has a measured answer (Ubuntu 24.04, gcc 13.3, rustc 1.90, go 1.25.4):

  trivial (print a constant, exit)
              size        wall(ms)  RSS(kB)  syscalls
  verbose        512       0.19      352        2
  gcc        706 584       0.24      664       17
  rustc    3 871 984       0.57    2 112       62
  go       2 254 335       1.28    2 132      228

  fib(40) = 102334155  (deep recursion — raw compute)
              size        wall(ms)  RSS(kB)  syscalls
  verbose        635      ~713       352        2
  gcc        706 584      ~135       664       17
  rustc    3 872 832      ~224     2 216       62
  go       2 254 624      ~380     2 232      406

Read it both ways. Wins, by construction: ~1100–1380× smaller than gcc -static, ~6000× vs rustc; two syscalls vs 17–228; RSS down 2–6×. Because there's no runtime — nothing to initialize, no global allocator, no dynamic library. These are audit-defensible: there's almost nothing to audit. Loss, by design: on fib(40), Verbose is ~5× gcc's wall time. The emitted blob has seen no optimizer — no register allocation, no inlining, no constant folding past the AST. That was a decision (a direct, line-by-line auditable emitter, not an LLVM backend), and the compute cost is the price of that legibility — published, not hidden.

What isn't there yet

It's a sub-language: scalar arithmetic (+ − × ÷ %, comparisons, and/or, if/else, let, recursive calls). No strings, no I/O, no services, no TLS.
It's branch-only, not merged, not tagged.
No optimization — deliberately deferred to keep every byte auditable.

The point isn't "Verbose beats gcc." It's "here's exactly what Verbose buys, and what it costs, measured." The read half and the write half of a self-hosting compiler just met one notch closer.

Full walk-through (in French) on arcker.org.

Every elevator has a load plate. Tests are supposed to kill fear, not feed it.

arcker — Sun, 14 Jun 2026 14:37:31 +0000

Every elevator has a small metal plate near the doors: 8 persons — 630 kg. It doesn't mean the car snaps at the ninth person. It means an engineer loaded it, measured it, and signed an envelope: this is what I guarantee, within these limits, with margin. The plate isn't a confession of weakness. It's the exact thing that lets you step in without a second thought.

I build Lithair — a small, memory-first Rust web framework. This post isn't about its API; it stands on its own. It's about a sentence I've come to believe — DevOps without the test isn't DevOps — and the reason for it is probably not the one you expect. It's not about laziness. It's about fear.

The plate is permission to stop worrying

Look around and the load-bearing things in the physical world all carry their envelope stamped on the outside. A bridge has a weight rating. A cable has an amperage. A climbing carabiner has a kN number etched into the spine. None of those numbers are bureaucracy. Each one is permission: you don't have to be afraid of this, here's exactly how far it's been taken. The plate converts a private unknown into a public, re-checkable fact, and the reward for that conversion is that nobody has to feel the unknown anymore.

That is what a test is for. Not a gate. Not a ritual. A way to stop being afraid of your own system.

What I've actually seen

I've spent years around enterprise software, and when real testing existed, it usually wore one of two shapes — and both, underneath, were shaped by fear.

There were the dedicated performance teams: a silo you handed the question to, where the schedule was measured in quarters, and where sometimes the software itself had to be bent to fit the benchmark rather than the other way around. Real rigor, but distant — the envelope lived in someone else's backlog.

And there were the functional-test teams who panicked the moment anyone touched anything. Change the color of a logo and you'd get a straight face and the words "non-regression testing." Not because they were unreasonable — because they had no fast, trustworthy way to know whether your one-line change broke something three modules away. So they did the only thing fear leaves you: they said don't touch it.

I want to be careful here, because it's easy to read this as contempt and it isn't. That fear is completely rational when you can't verify. If I couldn't check, I'd guard the gate too. The tragedy isn't the fear. It's that the one thing built to dissolve it — automated tests, ideally backed by a dedicated tool — so often gets turned into another thing to be afraid of.

Tests are the cure for that fear

A test you actually trust does something quietly radical: it gives you back the right to change things. Change the logo color and the suite tells you, in seconds, that the checkout flow still works. Change the storage engine and the harness tells you the throughput still holds. The fear doesn't get managed or scheduled or escalated — it just leaves, because the unknown it fed on is now a number on a screen.

That's the whole point of the plate. You can step into the elevator because someone already took it to the edge and wrote down where the edge is. Automated tooling is how you stamp that plate cheaply enough to do it for everything, not just the one system important enough to rent a perf team. And DevOps — the actual discipline, not the job title — is made for exactly this: turning "don't touch it" into "touch it freely, the tooling will tell you the truth."

So we built the bench

Lithair's cluster had no performance team behind it and no QA gate in front of it. There was just the question — what does it hold? — and nobody to hand it to. So the test became the work: we wrote our own stress harness and ran it until the numbers stopped being opinions.

A three-node cluster. 170,200 writes. Zero drops, zero panics, zero replication divergence across all three nodes. Good numbers — but the one that actually matters isn't a success, it's a ceiling: ~210–240 single-writes per second, per leader. Past that wall, the latency you measure isn't instability — it's pure queueing against the ceiling. The mild decay over a long run (241 → 206 ops/s) traces to in-memory state growth, which is exactly what a memory-first design predicts — not a leak.

We wrote all of it down. That's the plate. And the real payoff isn't the throughput number — it's that I can now change the cluster code and not be afraid of it, because the harness will tell me the moment I leave the envelope.

A plate only kills fear if it's honest

This is the part that's tempting to skip. A load rating that hides its caveats is worse than none, because it manufactures fresh fear later — the kind that shows up at 3 a.m. So the runbook names the ugly bits out loud:

The leader election isn't Raft — it's static, lowest live node ID wins. Always keep a node 0.
There's a brief two-leaders window when an old leader rejoins after a partition. Documented and non-blocking — committed split-brain is prevented elsewhere, by majority-ack on writes — but it's real, so it's on the page.
A couple of endpoints are still stubs in this version. Named, not buried.

None of that is comfortable to publish under your own name. All of it belongs on the plate. A caveat you wrote down is one nobody has to discover in production.

Why the test is the deliverable, not the feature

The cluster code already worked before any of this started — replication, election, failover, all running. What it lacked wasn't capability. It lacked a plate, and you cannot stamp a plate you didn't measure.

"Production-ready" without an envelope test is an adjective: you believe it or you don't, and belief is just fear wearing optimism. With the test it becomes a falsifiable claim anyone can re-run — and a falsifiable claim is the only kind that lets a whole team relax. Strip the test out and what's left isn't speed or risk, it's the fear: the "don't touch it," the non-regression theater over a logo color, the silo nobody wants to disturb. DevOps was supposed to be the discipline that retires all of that. Without the test, you've kept the dashboards and the dread, and quietly thrown away the engineering.

You can put a plate on almost anything

The format generalizes to nearly every load-bearing thing you ship:

an API's requests/sec before tail latency cliffs,
a queue's depth before backpressure kicks in,
a batch job's row count before it OOMs,
a cluster's writes/sec before it's just queueing.

It's always the same shape: here's what I hold, here's why it moves, here's where you leave the tested region. And the reward is always the same too — not bragging rights, but the simple ability for you and the people around you to stop being afraid of your own system. Sometimes the entire tax is one afternoon with a stress harness and the nerve to write down what you actually find.

The full numbers, the cluster runbook, and the v0.13.0 release that earned the plate are in the companion post on arcker.org (in French).

A program is a tree — building a Verbose compiler in Verbose

arcker — Sun, 14 Jun 2026 09:11:25 +0000

Verbose is a small experimental language I'm building. Its compiler proves properties about your code — like termination — and emits tiny, readable x86-64 machine code: no runtime, no GC, no libc. This post stands on its own (you don't need the rest of the series). What it's about: I'm now writing a Verbose compiler in Verbose itself, and this is the foundation brick — how you represent a program as data so a compiler can work on it.

(English version of an article from my French series, originally on arcker.org.)

After cryptography, we take on something more vertiginous: a Verbose compiler written in Verbose. The language starting to describe itself.

Let's be honest up front — it matters. This is not (yet) verbosec compiling the entirety of its own source. What exists today is a complete front end — tokenizer, parser, analyses, interpreter, type checker — written in Verbose, for a toy subset of the language. The whole thing compiled by verbosec to native machine code. Not an interpreted demo: a ~60 KB ELF binary that reads your program and tells you what's wrong with it. That's examples/vexprparse.verbose: 102 concepts, 219 rules.

We'll walk through it brick by brick. This chapter lays the foundation without which nothing else exists: how to represent a program.

Why write the compiler in Verbose?

The question deserves an answer, because it isn't just an exercise — it touches Verbose's whole thesis.

Today, the compiler (verbosec) is written in Rust. And some of the logic — certain primitives — is Rust that emits x86-64 directly, with no Verbose source. The concrete consequence: to audit a Verbose binary, to really understand what it does, at some point you have to read Rust. And trust that Rust — and whoever, or whatever, wrote it.

That's precisely what Verbose refuses. The whole series rests on four words: you don't trust, you verify. You read the source, declared and proven. If the path from source to binary runs through unverifiable Rust, trust leaks out there.

Writing the front end in Verbose moves that logic into the language itself: the tokenizer, the parser, the analyses become a .verbose file, verified under Verbose's proof regime, then compiled native. The auditor reads Verbose, not Rust. The remaining Rust shrinks to a small, stable, trusted-once base (the verifier). Per-binary trust moves from Rust to the proven source.

And it's the ultimate dogfooding: a compiler is the hardest thing to express. If Verbose can describe its own front end, under its own proof regime, then the language isn't a toy — it holds up on the most demanding task there is.

From text to a tree

A compiler can do nothing with flat text. x + y * 2, to a human, is a string of characters; to a compiler, it's a structure — a tree, where the multiplication nests under the addition (operator precedence):

  The text  "x + y * 2"  is really a tree:

            ( + )
           /     \
         x      ( * )
               /     \
             y         2

Everything starts there. Before evaluating, type-checking, or catching an undefined variable — you first have to turn the text into that tree. That's the AST (Abstract Syntax Tree). And to build it, you need a way to represent a tree as data.

A tree is a recursive sum type

This is where the earlier chapters pay off. A tree is declared in Verbose as a sum type — a type that can take several shapes — some of whose shapes reference themselves:

concept Ast
  variants:
    AstNum  of (value : number)
    AstVar  of (start : number, len : number)
    AstBin  of (op : number, lhs : Ast, rhs : Ast)
    AstNeg  of (inner : Ast)
    AstIf   of (cond : Ast, thn : Ast, els : Ast)
    AstCall of (callee_start : number, callee_len : number, args : ArgList)
    ...

Read AstBin: a binary operation holds an operator, a left subtree Ast, and a right subtree Ast. The type contains itself. That's the recursion of a tree: an addition whose two sides are, themselves, expressions. AstIf holds three (condition, then branch, else branch). AstNum and AstVar are leaves — they hold no other Ast.

Our example then becomes, exactly:

  AstBin( + ,
          AstVar(x),
          AstBin( * , AstVar(y), AstNum(2)) )

The tree drawn above, written as a value. And a.b.c? AstField(AstField(AstVar(a), b), c) — the nesting follows the structure.

No pointers: an index arena

One problem remains. Verbose has no heap and no pointers — one of the reasons its binaries are so small and so verifiable. So how do you build a tree of arbitrary size?

The answer: an arena. All nodes live in a single bounded space, and a node points to its children by their index, not by a pointer.

  concept_group VExpr [max_depth: 4096, max_nodes: 65535]

  arena:  [0]  AstVar(x)
          [1]  AstVar(y)
          [2]  AstNum(2)
          [3]  AstBin( * , lhs=1, rhs=2)    ← references indices 1 and 2
          [4]  AstBin( + , lhs=0, rhs=3)    ← the root

The tree is built bottom-up: leaves first, then the nodes that link them. max_depth: 4096, max_nodes: 65535 aren't decorative — they're the static bounds the verifier needs to prove everything stays finite. No dynamic allocation, no possible overflow, and yet a tree of any shape.

In the same group live the tokens, the environments, and the diagnostics — all variants of VExpr, all linked by index. One arena for the whole front end.

Why this brick first

Because everything else plugs into it. The tokenizer will produce Tokens in this arena. The parser will consume them to build Asts. The analyses will walk the tree to find your mistakes. The interpreter will descend it to compute a result. Without a way to represent the tree — recursive, bounded, verifiable — there's no compiler at all.

And it's the direct payoff of what we built before: the recursion of chapter 1, the termination proofs of chapter 3. An AST is the recursive structure par excellence — and Verbose represents it under the same guarantees as everything else: bounded, pointerless, proven finite.

The program has become data. The next chapter builds it from raw text: the tokenizer.

Originally published on arcker.org, where the full series lives.

TLS 1.3 without a library — a real browser does the handshake against Verbose machine code

arcker — Thu, 11 Jun 2026 13:44:22 +0000

Verbose is a small experimental language I'm building — its compiler proves properties about your code (like termination) and emits tiny, readable x86-64 machine code, with no runtime, no GC, no libc. This post stands on its own; you don't need any prior context. And it describes the wildest thing Verbose has done so far.

(English version of an article from my French series, originally on arcker.org.)

When your browser shows a little padlock next to a URL, it has just held a cryptographic conversation with the server — the TLS handshake. That conversation is usually handled by enormous C libraries: OpenSSL, BoringSSL, hundreds of thousands of lines nobody ever reads in full.

This article is the capstone of the crypto arc of the series. It shows the payoff: a real browser opens an HTTPS page served by a binary whose every cryptographic transform — the key exchange, the identity signature, the bulk encryption, the hash — is machine code emitted by Verbose. Not one line of OpenSSL. And the browser, the most demanding TLS client there is, can't tell the difference: it completes the handshake and renders the page.

We build on SHA-256 (chapter 1 of the arc) — it shows up everywhere in TLS. The details of each brick (AES, Ed25519) get their own chapters; here we pull up and watch the whole thing work.

A handshake, in three ideas

Before any encrypted exchange, the browser and the server have to settle three things. That's all of TLS, one sentence each:

Agree on a secret that no eavesdropper can guess, even after hearing the entire conversation (the key exchange).
Prove identity — the server shows a certificate and signs, so you know you're talking to the right party (the signature).
Talk encrypted — once the shared secret exists, everything else is encrypted with a fast symmetric algorithm (the bulk encryption).

On the wire, it looks like this:

  BROWSER                                 SERVER (Verbose binary)
      │                                          │
      │ ─── ClientHello ───────────────────────► │  "here are my algos + my key"
      │ ◄── ServerHello ─────────────────────── │  "here's mine"
      │            (encrypted from here on)       │
      │ ◄── Certificate + signature ──────────── │  "here's who I am, signed"
      │ ─── Finished ──────────────────────────► │
      │ ◄══ HTML page (AES-GCM encrypted) ══════ │  "Hello from Verbose TLS"
      │                                          │

Each of the three ideas needs a cryptographic ingredient. And that's where Verbose comes in.

The ingredients — and where the boundary runs

Here's the part that matters for Verbose's thesis. All the cryptography is Verbose machine code. The host (in Python) only does plumbing: open the socket, frame the TLS messages, and draw the one random secret (os.urandom).

  ┌──────────────────────────────────────────────────────────┐
  │  HOST (Python)  : socket, TLS record framing,              │
  │                   os.urandom (the only secret input)       │
  ├──────────────────────────────────────────────────────────┤
  │  VERBOSE (x86-64 machine code) :                           │
  │     X25519          the key exchange                       │
  │     Ed25519 / P-256 the identity signature                 │
  │     AES-128-GCM     the bulk encryption                    │
  │     SHA-256 + HKDF  the hash and key derivation             │
  └──────────────────────────────────────────────────────────┘

Every line of the Verbose block was validated byte-for-byte against a reference before being assembled:

AES-128-GCM against the NIST GCM Test Case 2 vector;
X25519 against RFC 7748;
Ed25519 against the three RFC 8032 §7.1 vectors;
HKDF against RFC 5869;
SHA-256, as we saw in chapter 1, against sha256sum.

Nothing is taken on faith because "it worked once." Each brick is checked against the official spec, in isolation, before it's stacked into the next.

The only loop in all of TLS: the X25519 ladder

Almost all the cryptography here is unrolled: each operation finishes in a fixed number of steps the verifier can follow statically. There's exactly one real loop — the X25519 key exchange, which climbs a "ladder" (the Montgomery ladder) over 255 rungs.

In Verbose, a loop is written as recursion, and — like in chapter 3 — it has to prove it terminates:

rule ladder
  logic:
    ...
    out = if s.i == 0 then <the ladder result>
          else ladder(LadderState { ..., i: s.i - 1, ... })
  proofs:
    termination:
      decreasing : i

(The real state carries ~50 fields — the field elements over 10 limbs — elided here.) The key point: decreasing : i is a compile-time-verified promise. The rung i strictly decreases on every call, so the compiler proves the ladder stops. The 255 iterations run at runtime; the guarantee that they finish is established before the binary even exists. No general loop construct was added to do TLS — the proof tools from chapter 3 are enough.

The catch: a real browser doesn't compromise

The first server signed its identity with Ed25519. Against openssl s_client — the usual test client — everything passed: Verify return code: 0 (ok), signature ed25519. We could have declared victory there.

Except a real browser refused. Flat: illegal_parameter.

Why? In its ClientHello, the browser announces the signature schemes it accepts (the signature_algorithms extension). And browsers offer ecdsa_secp256r1_sha256 (P-256), not Ed25519. RFC 8446 requires the server to sign with an offered scheme. Ed25519 wasn't offered → immediate rejection.

That's exactly the value of a real browser as a target: it imposes constraints a test client lets slide. So we had to build the whole ECDSA P-256 stack — GF(p256) field arithmetic, point add/double, scalar multiplication, the modular inverse, and ECDSA-P256-SHA256 signing (RFC 6979 deterministic nonce, DER encoding, low-s) — validated against the RFC 6979 §A.2.5 vectors and openssl dgst -verify.

With a P-256 certificate, the browser stops saying illegal_parameter. It completes the handshake. It renders the page: "Hello from Verbose TLS". The only remaining warning is the expected self-signed-certificate one. Not a crypto failure. The page renders.

The detail that's fun: smaller, for free

Two recursive rewrites, the same week, at zero compute cost:

p256_ninv: 11.2 MB → 84 KB of native code (131× smaller), 8/8 byte-for-byte vs the unrolled version.
x25519_finish: 1.3 MB → 42 KB (31× smaller), 266 field multiplications identical to the unrolled version. openssl handshake re-validated after the cure.

Same algorithm, same exact output, zero CPU overhead. The recursive path introduced for self-hosting (Phase A) turned out to be the right tool for collapsing huge unrolled cryptographic chains into compact machine code.

Why it matters

TLS 1.3 is not a toy: it's a stack of cryptographic primitives, inside a state machine, inside a wire format, with a public client — your browser — that won't compromise on any of it. Making it work end-to-end is empirical proof that the language and its compiler can express, verify, and run a real protocol, not a demo.

And the method is the message. The cryptography here isn't credible because a tool produced it — it's credible because it's confronted, brick by brick, with the RFC vectors, then with OpenSSL, then with a browser that forgives nothing. You don't trust, you verify. That's the whole difference, and that's all of Verbose: a binary small enough to read, proofs declared in source, and output checked against reality at every step.

The arc began with a 12 KB hash in chapter 1. It ends with a browser rendering a page encrypted by a binary you can read line by line. In between, each brick still needs telling in detail — AES, Ed25519, the Montgomery ladder. Those are the next chapters.

Originally published on arcker.org, where the full series lives.

DEV Community: arcker

cidx v3.0.0 — deleting the things that lied

Five breaking changes, one motive

Why they were findable now

The load-bearing one: /v3

What it teaches

943 bytes that answer HTTP

Serving HTTP when you have nothing

The pivot: reading what the client said

Answering differently per request

The detail that lands: one log line, one syscall

What it means

probatum — your tests pass. does it actually boot?

What probatum checks (that tests don't look at)

Why not just a cidx stage?

The proof engine with nothing to prove

The real first reader is the agent

Where it actually stands

The ecosystem I'm aiming at

cidx v2.1.0 — the most useful output of a release was its seven bug reports

The short part (the diff)

Cutting a release with your own tool

The loop working, not the loop breaking

What's next

The fixed point: a compiler written in its own language just reproduced itself, byte for byte

Three generations

Why byte-identical, not just "it compiles"

What almost stopped it — and why the diagnosis is the real story

The fix — and the fix that waits, on purpose

What it means

lithair 1.0 — I'm here, and yet

What the distrust is actually rating

What's actually there

Honest about what remains

What no one can take

A compiler written in its own language just emitted a standalone Linux executable

Two halves of a compiler

Follow factorial all the way down

From a byte blob to a real executable

The honest benchmark

What isn't there yet

Every elevator has a load plate. Tests are supposed to kill fear, not feed it.

The plate is permission to stop worrying

What I've actually seen

Tests are the cure for that fear

So we built the bench

A plate only kills fear if it's honest

Why the test is the deliverable, not the feature

You can put a plate on almost anything

A program is a tree — building a Verbose compiler in Verbose

Why write the compiler in Verbose?

From text to a tree

A tree is a recursive sum type

No pointers: an index arena

Why this brick first

TLS 1.3 without a library — a real browser does the handshake against Verbose machine code

A handshake, in three ideas

The ingredients — and where the boundary runs

The only loop in all of TLS: the X25519 ladder

The catch: a real browser doesn't compromise

The detail that's fun: smaller, for free

Why it matters

The load-bearing one: `/v3`