Inline + chunked file transfer. No central host, no separate file
encryption key — the existing v2 envelope crypto + nostr publish
path covers it. Files up to 10 MB; larger refused with a friendly
error.
Inline path (≤80 KB raw)
- File body is a JSON kez-file-v1 / inline payload with base64
data, sealed by the normal envelope and published as a single
kez-DM event. Same delivery semantics as text.
Chunked path (80 KB – 10 MB)
- Raw bytes split into ~80 KB chunks (each fits comfortably under
the ~256 KB envelope-content ceiling most relays enforce).
- Each chunk is its own kez-DM event with body kez-file-chunk-v1
(file_id + i + n + base64). One signed event broadcast to all
5 default relays → ~99.999% per-chunk delivery.
- Publish throttled to ~5 events/sec to keep stricter relays
happy. A 5 MB image lands in ~12 seconds end-to-end.
- Pointer event (kez-file-v1 / chunked mode) sent last — it's
the user-visible message; chunks are silent plumbing.
Receive path
- parseFileBody discriminates plain text vs inline vs pointer vs
chunk on the existing inbox-service decrypt path. Plain text
still routes through the regular appendInbound.
- Pointer arrival: create a "pending" attachment row + record the
destination on the chunk-buffer entry.
- Chunk arrival: append to the chunk buffer keyed by file_id;
once n/n are present AND a destination is known, finalize.
- Finalize: assemble in-order, decode to a data URL, save to the
local attachment store, flip the attachment.state to "ready".
- Pointer-before-chunks and chunks-before-pointer both work — IDB
chunk buffer survives reloads so a partial transfer resumes.
UI (Messages.svelte)
- Paperclip button next to the emoji button. Hidden file input
with accept=image/* (broader types easy to enable later).
- Optimistic local echo on send: bubble + image preview appear
instantly from the local-copy data URL. Status icon proceeds
"sending" → "sent" → "delivered" exactly like text messages.
- Bubble render branches on m.attachment:
• image MIME + ready → inline <img>
• non-image MIME + ready → filename + size + download link
• pending → spinner with "Receiving N/M…"
• failed → red ⚠ chip
Storage (attachment-store.ts)
- kez-chat:attachments:v1 — ready files keyed by
peer_primary|seq, value = {filename, mime, data_url, size}.
- kez-chat:chunk-buffer:v1 — in-flight chunks keyed by file_id,
value = {n, received: {i: bytes}, destination?}.
Schema (conversations-store.ts)
- ConversationMessage.attachment? = {filename, mime, size, state,
file_id?, received_chunks?, total_chunks?}.
- Helpers: appendInboundAttachment, appendOutboundAttachment,
patchAttachmentState, findAttachmentByFileId.
Out of scope (intentional for v0.1)
- Larger than 10 MB: refused with a friendly error.
- Reed-Solomon erasure coding: not needed — single signed event
broadcast to 5 relays delivers reliably enough. Recovery from
the rare missing chunk via DM round-trip is a future hook.
- Reverse channel ("still need chunks [3,7]"): protocol slot
left open; not implemented.
- HEIC → JPEG conversion: iOS Safari may hand us the original
HEIC bytes; recipients on non-Apple devices can't render. Fix
in the picker layer if it bites.
- Server-transport stub: throws a clear "use VITE_TRANSPORT=nostr"
error so the UI can't silently misroute.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.