Kez/nodejs
Tudisco d0db6f00f1 Initial implementation of KEZ — protocol, two impls, and storage server
KEZ is a portable, decentralized identity graph: a person signs claims
linking their many accounts, publishes those claims in places only the
claimed account can publish to, and anyone can verify the connections
without trusting a central server.

Layout
------
- SPEC.md            Language-agnostic protocol spec (v0.2)
- rust/              Rust implementation: kez-core, kez-channels, kez-cli
- nodejs/            TypeScript port at full parity
- rust-sig-server/   Optional axum + SQLite storage server for sigchains
- crosstest.sh       Cross-implementation interop harness

Capabilities (both implementations, byte-compatible)
----------------------------------------------------
- Two primary-key algorithms: nostr/secp256k1 Schnorr (BIP-340) and
  Ed25519 (RFC 8032). Identifiers: nostr:npub1... and ed25519:<hex>.
- JCS (RFC 8785) canonicalization for everything signed.
- Four proof encodings: JSON envelope, compact (kez:z1:<base64url(zstd(json))>),
  Markdown fence, DNS TXT.
- Five channel plugins (no API keys, no auth needed for any of them):
    dns:        system resolver, _kez.<domain> TXT records
    github:     public gist scan + <user>/<user> profile README fallback
    nostr:      kind-30078 events from default relays
    bluesky:    public AppView author feed
    ap:         WebFinger + actor JSON (alias mastodon:)
- Identical CLI surface:
    kez identity new [--key-type nostr|ed25519]
    kez claim create <subject> (--nsec | --ed25519-seed) [--format ...] [--out ...]
    kez claim dns <domain>     (--nsec | --ed25519-seed)
    kez verify file <path>
    kez verify id <identifier>
    kez sigchain add|revoke|show|export|publish
- Sigchains: append-only signed log per primary, hash-chained per spec §6,
  stored locally at ~/.kez/sigchains/, exportable as JSONL or kez:zc1: bundle.
- Sigchain publish destinations: chain server, web (file dump), DNS (zone
  record print), nostr (kind-30078 wrapping event).

kez-sig-server
--------------
Optional storage tier. Axum + SQLite, single binary, no external deps.

- No auth — the cryptography is the access control. The server validates
  every signature, every seq, every prev hash before storing.
- REST API: POST /v1/sigchains/{scheme}/{id}/events (append signed event,
  201 with new head hash or 4xx); GET /{scheme}/{id} (full chain as JSONL);
  GET /head; GET /healthz.
- Designed for one central instance for now; the design doesn't preclude
  running more later (clients gain a configurable list, verifiers
  reconcile per spec §6.2).
- Channel-based publishing remains the always-available fallback if the
  server is unavailable.

Tests
-----
- rust/                 99 tests
- rust-sig-server/      10 integration tests (real HTTP, real SQLite)
- nodejs/               91 tests (vitest)
- crosstest.sh          19 cross-impl scenarios — proves JCS bytes,
                        Schnorr + Ed25519 sigs, all four claim encodings,
                        and the sigchain JSONL bundle are byte-compatible
                        between Rust and Node in both directions.

What's not done yet
-------------------
- verify id consulting the sigchain for revocations (data path exists,
  just not wired into the verifier output).
- rotate and add_device sigchain ops (types reserved).
- expires_at enforcement during claim verification.
- Typed VerificationStatus.status reflecting the five failure modes.
- Auth-required publishers (GitHub gist, Bluesky, ActivityPub).
2026-05-24 14:41:00 -06:00
..

KEZ — Node.js Implementation

TypeScript port of KEZ, structurally mirroring the Rust implementation — three packages (core, channels, cli) with the same CLI surface, the same proof formats, and the same five channel plugins. Wire-compatible with the Rust version: a claim signed in Rust verifies in Node and vice versa.

nodejs/
├── package.json                 npm workspaces root
├── tsconfig.base.json
├── packages/
│   ├── kez-core/                Types, signing, verification, JCS, all four encodings
│   ├── kez-channels/            One file per channel (github, dns, nostr, bluesky, activitypub)
│   └── kez-cli/                 Thin CLI dispatching through the channel registry
└── README.md                    (this file)

Requirements

  • Node.js 22+ (for the built-in WebSocket the nostr channel uses)
  • npm 9+ (for workspaces)

Install & test

npm install                  # one-time
npm test                     # runs all packages' vitest suites
npm run typecheck            # strict tsc --build across all packages

CLI

The CLI mirrors the Rust CLI exactly. Run it via the workspace script:

# Create a key
npm run cli -- identity new

# Sign a claim — pick either key type
npm run cli -- claim create github:jason --nsec nsec1... --format markdown --out github.kez.md
npm run cli -- claim create github:jason --ed25519-seed <64-char-hex> --format markdown --out github.kez.md

# Generate an ed25519 identity instead of nostr
npm run cli -- identity new --key-type ed25519

# Local sigchain (state at ~/.kez/sigchains/<safe-primary>.jsonl)
npm run cli -- sigchain add    github:jason --nsec nsec1...
npm run cli -- sigchain revoke github:jason --nsec nsec1...
npm run cli -- sigchain show   --nsec nsec1...
npm run cli -- sigchain export --nsec nsec1... --format jsonl

# Publish the sigchain to one or more destinations
npm run cli -- sigchain publish --nsec nsec1... \
  --server http://localhost:7878 \
  --web --out chain.jsonl \
  --dns example.com \
  --nostr wss://relay.damus.io

# Verify a local file
npm run cli -- verify file github.kez.md

# Verify any KEZ identifier over the network
npm run cli -- verify id github:jason
npm run cli -- verify id dns:jason.example.com
npm run cli -- verify id nostr:npub1...
npm run cli -- verify id bluesky:jason.bsky.social
npm run cli -- verify id ap:@jason@mastodon.social
npm run cli -- verify id mastodon:@jason@mastodon.social

Channels

File System Implementation
dns.ts dns: Node dns/promises resolver, abstracted behind TxtResolver for testing
github.ts github: fetch against the public REST API, no auth
nostr.ts nostr: Built-in WebSocket to default relays, abstracted behind NostrFetcher
bluesky.ts bluesky: fetch against the public Bluesky AppView, no auth
activitypub.ts ap:, mastodon: WebFinger + actor JSON, no auth

Each channel implements:

interface Channel {
  readonly system: string;
  fetchAndVerify(identity: Identity): Promise<ChannelHit>;
}

…and is registered in Registry. Adding a new channel is one file + one r.register(new MyChannel()) line in defaultRegistry.

Library use

import { Identity } from "@kez/core";
import { defaultRegistry } from "@kez/channels";

const registry = await defaultRegistry();
const hit = await registry.verify(Identity.parse("github:jason"));
console.log(hit.status); // VerificationStatus

Crypto stack

  • Schnorr signatures@noble/curves/secp256k1 (BIP-340)
  • SHA-256@noble/hashes/sha2
  • bech32 (npub/nsec)@scure/base
  • JCS (RFC 8785)canonicalize
  • zstdfzstd (pure JS, no native deps)
  • base64url@scure/base
  • HTTP — Node 18+ built-in fetch
  • WebSocket — Node 22+ built-in WebSocket
  • DNS TXT — Node dns/promises

No native dependencies. Runs on Node, Bun, and (mostly) Deno.

Cross-implementation interop

The whole point of having two implementations is to demonstrate that the proof format is portable. The repo root has a crosstest.sh script that generates artifacts in Rust and verifies them in Node, and vice versa. See ../README.md for the runner.

Tests

npm test                          # full suite
npx vitest run --project core     # one workspace package

The test suite hits no network — HTTP channels use an injected fetch, DNS uses a TxtResolver interface, nostr uses a NostrFetcher interface.

License

Dual-licensed under MIT or Apache-2.0.