nxtls is cryptography and a TLS 1.3 client written entirely in Nexium, my own language — no C libraries, no @cImport, and not one unsafe block, so a reviewer can read it end to end. It exists so Nexium programs can verify signatures and speak HTTPS without handing their security to a C library. Its first real user is a Discord helper I wrote for an amateur-radio club, which checks the Ed25519 signature on every request with it and talks to Discord through its TLS client.
verify, HKDF with TLS 1.3's expand_label, and X25519 and ChaCha20-Poly1305 in constant time.Every module is checked against its published vectors — FIPS 180-4 and RFCs 4231, 5869, 7748, 8032, 8439 and 8448 — and against Python's cryptography package, which a generator script uses as an oracle while it re-derives every constant table from its definition. The X.509 code is judged on 68 chains and 13 malformed certificates by cryptography's own path validation. The TLS client replays 35 recorded exchanges byte for byte, runs against OpenSSL 3's s_server in twelve configurations — including the ones it must refuse: the wrong host, an expired certificate, TLS 1.2 — and connects live to Discord, GitHub, Google and Cloudflare. CI runs all of it on Linux, Windows and macOS, and fails any module that grows an unsafe block, a mutable global, or a foreign call.
It's new, and nobody who knows TLS has reviewed it yet — the README says so up front, and that review is the next item on the plan. It also won't fall back to a weaker source of randomness: on Windows, where it has no /dev/urandom, tls.connect says so and stops. Until that review happens, treat it as a careful reading of the RFCs, not something to trust with anything that matters.