Jason Tudisco 5cb46e2aa1 feat(kez-chat): v0.1 chat — encrypted 1:1 messages (server + web client)
Time to actually chat. Server is a dumb relay storing opaque envelopes;
recipients decrypt client-side. Everything below is end-to-end encrypted,
the server can't read anything it stores.

Server (kez-chat-server):
  • New messages table (seq autoinc, recipient_handle, envelope blob,
    created_at). Indexed by (recipient, seq) for cursor paging.
  • POST /v1/messages
      body: { to: handle, envelope: <opaque JSON> }
      validates recipient exists; rejects > 256 KB envelopes.
  • GET /v1/inbox/:handle?since=<seq>&limit=<n>
      auth: X-KEZ-Auth: <unix_ts>:<sig_hex>
      sig = ed25519(handle's primary,
                    "GET\n/v1/inbox/<handle>\nsince=<n>\n<ts>")
      60s clock-skew tolerance; signed message includes cursor so a
      captured header can't page through history.
  • New ApiError::Unauthorized → 401.
  • kez-core: verify_ed25519_hex is now pub so the auth handler can
    use it for arbitrary-message verification (outside JCS envelopes).

Crypto (browser):
  • ed25519 seed → x25519 priv via Montgomery conversion
    (ed25519.utils.toMontgomerySecret).
  • ed25519 pubkey → x25519 pubkey for the recipient (toMontgomery).
  • ECDH → 32-byte shared secret → HKDF-SHA256(salt=nonce, info=
    "kez-chat-msg-v1") → AES-256-GCM key.
  • Per-message random 12-byte nonce; each message gets a unique AES key.
  • Sender signs envelope-minus-sig with their ed25519 primary so the
    recipient can confirm the sender authored the ciphertext + binding.

SPA UI:
  • /messages route, two-pane layout (sidebar conversations, thread view,
    compose box).
  • 5-second poller against /v1/inbox using the global cursor; new
    messages get decrypted + appended to the right thread.
  • Local IDB cache (lib/conversations-store.ts) so decrypted history
    survives reloads. Dedupes by seq+direction.
  • Page-specific max-w-6xl so the two-pane layout has room.

Tests:
  • 6 new unit tests in messages.rs covering auth header verification
    (stale ts, wrong handle, wrong cursor, malformed).
  • 4 new integration tests in tests/http.rs: full send + inbox round-
    trip, wrong-signer rejected, missing header rejected, unknown
    recipient → 404.
  • All 17 chat-server tests pass.

Followups (deferred):
  • NATS WebSocket push (live messages without 5s poll lag).
  • Group chats with proper member-key rotation.
  • Reverse handle resolution (/v1/by-primary) so the UI can show
    "@alice" instead of the truncated ed25519 hex.
  • At-rest encryption for the IDB conversations cache.
  • Sender spam mitigation on POST /v1/messages.

Live at https://kez.lat — try /messages with two browsers.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-25 16:10:43 -06:00

KEZ

KEZ is a portable, decentralized identity graph. It lets a person say:

"These accounts, keys, domains, and identities are all me."

…without depending on any central authority. Every connection is proven by a cryptographic signature against a key the user already controls (a nostr key, an Ed25519 key, etc.), and the proofs are published in places only the claimed account itself can publish to (their gist, their DNS, their nostr relay event). Anyone can verify the graph without trusting a server.

Repository layout

.
├── SPEC.md              ← The protocol. Language-agnostic, normative.
├── rust/                ← Rust implementation (kez-core, kez-channels, kez-cli)
├── nodejs/              ← TypeScript/Node implementation (same shape, same CLI)
├── rust-sig-server/     ← Optional HTTP store for sigchains (axum + SQLite)
├── crosstest.sh         ← Interop test: artifacts move between implementations
└── README.md            ← (this file)

Two parallel implementations. Wire-compatible: a claim signed in Rust verifies in Node and vice versa. The cross-test harness proves it.

A separate rust-sig-server/ crate provides an optional HTTP storage tier for sigchains — useful when a user doesn't want to set up DNS/hosting/nostr, but never required; the protocol stays decentralized.

Documentation

Start here:

  • SPEC.md — the language-agnostic protocol spec (v0.2). Normative for every implementation.
  • rust/README.md — Rust implementation guide: crate layout (kez-core / kez-channels / kez-cli), full CLI reference, channel plugin model, library examples, and the gap list.
  • nodejs/README.md — Node/TypeScript port: same shape as Rust, npm workspaces layout, crypto stack rationale, CLI reference.
  • rust-sig-server/README.md — the optional storage server: API reference, no-auth design + threat model, deployment recipes (bare-metal, Docker, PaaS), and how channel-based publishing remains the fallback if the server is down.

Quick start

Rust

cd rust
cargo build
cargo test                                                # 99 tests
cargo install --path crates/kez-cli                       # → `kez` on PATH
kez verify id github:jason

Full guide: rust/README.md.

Node.js

cd nodejs
npm install
npm test                                                  # 91 tests
npm run cli -- verify id github:jason

Full guide: nodejs/README.md.

Sigchain storage server (optional)

cd rust-sig-server
cargo build --release
./target/release/kez-sig-server                           # listens on :7878

Full guide: rust-sig-server/README.md.

Cross-testing

./crosstest.sh

Runs 19 scenarios that swap implementations at the artifact boundary:

# Scenario
12 nostr-signed JSON claim, both directions
34 nostr-signed compact claim, both directions
56 nostr-signed markdown claim, both directions
78 nostr-signed DNS zone form, both directions
910 ed25519-signed JSON claim, both directions
1112 ed25519-signed compact claim, both directions
1314 ed25519-signed markdown claim, both directions
15 rust builds 3-event nostr sigchain → node parses + shows
16 rust-exported sigchain JSONL == node-exported JSONL (byte-identical)
17 node builds 3-event nostr sigchain → rust parses + shows
18 rust builds ed25519 sigchain → node parses + shows
19 node builds ed25519 sigchain → rust parses + shows

If all 19 pass: JCS canonicalization, both signature suites (BIP-340 Schnorr and Ed25519), the compact kez:z1: zstd+base64url encoding, the Markdown fence, the DNS TXT shape, and the sigchain JSONL bundle format are all byte-compatible across implementations.

Pass -v for verbose output (echoes intermediate commands and proofs).

What ships in v0.2

  • Five channel plugins in each implementation: dns:, github:, nostr:, bluesky:, ap: (alias mastodon:).
  • Four wire encodings: JSON, compact, Markdown fence, DNS TXT.
  • Two primary-key algorithms: nostr/secp256k1 Schnorr (BIP-340) and Ed25519 (RFC 8032).
  • JCS (RFC 8785) canonicalization for everything signed.
  • No API keys required for any channel.

What's not done yet

Tracked in rust/README.md and the spec:

  • verify id consulting the sigchain. Sigchain types, CLI commands (kez sigchain add/revoke/show/export/publish), and the storage server all exist. But proof verification doesn't yet fetch the chain to check for revocations — every verify is still a single one-shot proof check.
  • rotate and add_device sigchain ops.
  • expires_at enforcement during claim verify.
  • Typed VerificationStatus.status reflecting the five failure modes (valid / revoked / expired / unreachable / fork).
  • Auth-required publishers (GitHub gist, Bluesky, ActivityPub).

License

Dual-licensed under MIT or Apache-2.0.

Description
No description provided
Readme 1.7 MiB
Languages
TypeScript 38.9%
Rust 31.8%
Svelte 18.2%
Python 5.4%
Shell 2.8%
Other 2.9%