First real UI for kez-chat. Served by the chat-server as static
files; uses the same HTTP API a native client would (dogfoods the
contract).
Stack: Svelte 5 + TypeScript + Vite + Tailwind 4 + @noble/curves +
@scure/base + canonicalize + idb-keyval + svelte-spa-router.
Bundle: 113 KB JS / 14 KB CSS (gzip: 42 KB / 4 KB).
Pages (all behind hash routing):
/ Landing — sign up or restore from seed
/create Account creation flow:
1. Pick handle, set passphrase
2. Show seed for paper backup, require ack
3. Confirm
4. POST /v1/register, save passphrase-encrypted seed
to IndexedDB
/restore Stub for restore-from-seed (v0.2: needs
GET /v1/by-primary endpoint on the server)
/unlock Enter passphrase to derive the AES-GCM key,
decrypt the seed, populate session state
/dashboard Show handle, primary, registered_at, sigchain URL
/claims List locally-cached claims (with publication status)
/claims/add Add-a-claim wizard:
1. Pick channel (github/dns/web/nostr/bluesky/ap)
2. Enter identifier
3. SignedClaimEnvelope built + signed in-browser
using Ed25519 + JCS, matching the spec exactly
4. Show channel-appropriate publish instructions +
copyable markdown or JSON artifact
5. User marks it published (purely a local note —
actual verification is the verifier's job)
Crypto / KEZ helpers (src/lib/kez.ts):
- generateIdentity / identityFromSeed (32-byte Ed25519)
- canonicalBytes (RFC 8785 JCS via the `canonicalize` package — same
one our Node port uses; produces byte-identical output to Rust)
- signClaim, signRegistration (build envelopes; sign with
ed25519-sha512-jcs; same alg / key / sig shape as kez-core)
- toPrettyJson, toMarkdown (the same wire encodings the CLI emits)
Key storage (src/lib/identity-store.ts):
- IndexedDB via idb-keyval
- Seed encrypted under user passphrase: PBKDF2-SHA256
(600,000 iterations, OWASP 2024 guidance) → AES-GCM-256
- Documented limitation: browsers don't have an OS-keychain
equivalent. Native clients (future CLI/Tauri) will use the OS
keychain for better protection.
Bundle includes:
- Workaround for TS 5.6+ Uint8Array<ArrayBufferLike> vs ArrayBuffer
strictness (small asBuffer() helper that copies into a plain
ArrayBuffer for WebCrypto + Response calls).
Dockerfile updated: now multi-stage with a Node `webbuild` stage
that runs `npm run build` before the Rust binary stage. SPA dist
is copied into the runtime image at /app/web; chat-server's
KEZ_CHAT_WEB_DIR points at it so the SPA is served at /.
What works against the LIVE deployment right now (https://kez.lat):
- Open https://kez.lat → SPA loads (113 KB JS, 14 KB CSS)
- Create account → key gen happens in browser, seed shown for
backup, encrypted under passphrase, POSTed to /v1/register
- Dashboard → shows registered handle + primary + sigchain URL
- Claims wizard → sign for any of the 6 channels, get publish
instructions + the right wire format to copy
- Lock / unlock — passphrase-derived AES-GCM, no roundtrips
What's still TODO (v0.2):
- Restore-from-seed: needs GET /v1/by-primary on the server so the
SPA can discover the handle from a seed
- Actual NATS chat: needs server's auth callout (currently 501) +
nats.ws client (browser side; package is in deps but not used yet)
- Sigchain integration: append `add` event when user publishes a
claim, upload to sig-server (needs sig.kez.lat tunnel)
- Verification: in-browser channel fetches (some channels are
CORS-friendly, others need a server-side proxy)
- Compact (kez:z1:) form: the spec uses zstd, browsers don't have
native zstd CompressionStream support yet. Workaround in code
uses deflate-raw with a `kez:zd1:` prefix to make it obvious the
output isn't spec-compliant; replace with @bokuweb/zstd-wasm or
similar when we need true compact form in the SPA.
kez-chat-server
Home server for the kez-chat application. One Rust binary that hosts:
- Handle registry (
POST /v1/register,GET /v1/u/:handle) - WebFinger discovery (
GET /.well-known/webfinger) - NATS auth callout endpoint (
POST /internal/nats/auth) — stub in v0.1 - Static SPA serving (
GET /) — placeholder until the Svelte build lands - Healthz (
GET /v1/healthz)
Designed in document.md. Spec for the underlying KEZ
identity layer in ../SPEC.md.
What's in v0.1 (this is the scaffold)
✅ HTTP API end-to-end
✅ Ed25519-signed handle registration with replay protection
✅ SQLite-backed registry with uniqueness on both handle and primary key
✅ WebFinger endpoint
✅ Placeholder SPA at /
✅ docker-compose for full stack (chat + nats + sig-server)
✅ Multi-stage Dockerfiles
✅ 13 integration tests against a live router
⚠️ NATS auth callout returns 501 — wired up in v0.2 ⚠️ Svelte SPA build pipeline not yet in place — placeholder HTML for now ⚠️ TLS terminated upstream (no cert handling in this binary)
Quick start (local development)
# Run from source
cargo run -- --bind 127.0.0.1:6969 --db ./kez-chat.db --server kez.lat
# Or install once
cargo install --path .
kez-chat-server --bind 127.0.0.1:6969 --server kez.lat
Configuration via flags or env vars:
| Flag | Env | Default |
|---|---|---|
--bind |
KEZ_CHAT_BIND |
0.0.0.0:6969 |
--db |
KEZ_CHAT_DB |
kez-chat.db |
--server |
KEZ_CHAT_SERVER |
kez.lat |
--sig-server-url |
KEZ_CHAT_SIG_SERVER_URL |
http://localhost:7878 |
--web-dir |
KEZ_CHAT_WEB_DIR |
(unset → placeholder page) |
Logging: RUST_LOG=debug,hyper=info etc.
Quick start (Docker compose, full stack)
cd deploy
docker compose up -d --build
Brings up three services:
| Service | Port(s) | What it does |
|---|---|---|
chat-server |
6969 | HTTP API + SPA |
nats |
4222 (native), 8443 (WebSocket), 8222 (monitoring) | Dumb broker, JetStream enabled |
sig-server |
7878 | Sigchain storage (the existing rust-sig-server) |
Then point a reverse proxy / Cloudflare tunnel at localhost:6969.
Testing
cargo test # 13 integration tests (real server, real HTTP)
The tests stand up the router on a random local port and exercise it
via reqwest. No mocks. They cover: healthz, lookup, registration
(success + duplicate + wrong-server + reserved-name + tampered-sig +
stale-timestamp), WebFinger, the placeholder SPA, and the NATS auth
callout stub.
Endpoints in detail
GET /v1/healthz
{ "status": "ok", "server": "kez.lat", "version": "0.1.0" }
GET /v1/u/:handle
Returns:
{
"handle": "tudisco",
"fqhn": "tudisco@kez.lat",
"primary": "ed25519:2152f8d19b...",
"sigchain_url": "https://sig.kez.lat/v1/sigchains/ed25519/2152f8d19b...",
"registered_at": "2026-05-25T03:00:00Z"
}
Returns 404 if the handle isn't registered.
POST /v1/register
Request body — a signed registration envelope:
{
"kez": "handle_registration",
"payload": {
"type": "kez.chat.handle_registration",
"version": 1,
"handle": "tudisco",
"primary": "ed25519:2152f8d19b...",
"server": "kez.lat",
"created_at": "2026-05-25T03:00:00Z"
},
"signature": {
"alg": "ed25519-sha512-jcs",
"key": "ed25519:2152f8d19b...",
"sig": "<128-char-hex>"
}
}
Server validates:
- Envelope tag is
"handle_registration" - Payload type is
"kez.chat.handle_registration", version 1 signature.keyequalspayload.primary- Signature verifies against the primary key (Ed25519 only for chat)
payload.servermatches this server's configured domainpayload.handlepasses validation (length 3-32,a-z0-9_-, starts with letter/digit, not in reserved list)payload.created_atis within 5 minutes of server time
On success: 201 Created with the same body as GET /v1/u/:handle.
GET /.well-known/webfinger?resource=acct:user@server
Standard fediverse-style discovery. Returns the user's KEZ identity info as a WebFinger JRD. Used by other servers (federated lookup, future) and by tools like fediverse browsers.
POST /internal/nats/auth
NATS auth callout endpoint. Stub in v0.1 — returns 501. The real
implementation (v0.2) will: parse the NATS auth request JWT, extract
the connecting client's nkey, look up the corresponding handle, sign
a response permitting kez.inbox.<pubkey>.> subjects.
Deployment notes
- The
chat-serverDocker image is built from the repo root as context (so it can copyrust/crates/kez-corefor the path dep).docker-compose.ymlsets this correctly. - The
sig-serveris the existing../rust-sig-serverbinary, built into a separate image viaDockerfile.sig-server. - NATS config (
nats.conf) has WebSocket enabled on port 8443 so the browser SPA can connect vianats.ws. Theissuerfield inauth_calloutis a placeholder — generate a real nkey and replace before going to production. - TLS is not handled by this binary. Put a reverse proxy (Caddy, nginx, Cloudflare tunnel) in front for HTTPS.
License
Dual-licensed under MIT or Apache-2.0.