manawenuz/featherChat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
3e0889e5dc321594d82109601de3bf0d4b1120ce
featherChat/warzone/docs/PROGRESS.md
Siavash Sameni 3e0889e5dc v0.0.21: TUI overhaul, WZP call infrastructure, security hardening, federation 
TUI:
- Split 1,756-line app.rs monolith into 7 modules (types, draw, commands, input, file_transfer, network, mod)
- Message timestamps [HH:MM], scrolling (PageUp/Down/arrows), connection status dot, unread badge
- /help command, terminal bell on incoming DM, /devices + /kick commands
- 44 unit tests (types, input, draw with TestBackend)

Server — WZP Call Infrastructure (FC-2/3/5/6/7/10):
- Call state management (CallState, CallStatus, active_calls, calls + missed_calls sled trees)
- WS call signal awareness (Offer/Answer/Hangup update state, missed call on offline)
- Group call endpoint (POST /groups/:name/call with SHA-256 room ID, fan-out)
- Presence API (GET /presence/:fp, POST /presence/batch)
- Missed call flush on WS reconnect
- WZP relay config + CORS

Server — Security (FC-P1):
- Auth enforcement middleware (AuthFingerprint extractor on 13 write handlers)
- Session auto-recovery (delete corrupted ratchet, show [session reset])
- WS connection cap (5/fingerprint) + global concurrency limit (200)
- Device management (GET /devices, POST /devices/:id/kick, POST /devices/revoke-all)

Server — Federation:
- Two-server federation via JSON config (--federation flag)
- Periodic presence sync (every 5s, full-state, self-healing)
- Message forwarding via HTTP POST with SHA-256(secret||body) auth
- Graceful degradation (peer down = queue locally)
- deliver_or_queue() replaces push-or-queue in ws.rs + messages.rs

Client — Group Messaging:
- SenderKeyDistribution storage + GroupSenderKey decryption in TUI
- sender_keys sled tree in LocalDb

WASM:
- All 8 WireMessage variants handled (no more "unsupported")
- decrypt_group_message() + create_sender_key_from_distribution() exports
- CallSignal parsing with signal_type mapping

Docs:
- ARCHITECTURE.md rewritten with Mermaid diagrams
- README.md created
- TASK_PLAN.md with FC-P{phase}-T{task} naming
- PROGRESS.md updated to v0.0.21

WZP submodule updated to 6f4e8eb (IAX2 trunking, adaptive quality, metrics, all S-tasks done)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-28 16:45:58 +04:00

13 KiB
Raw Blame History

Warzone Messenger (featherChat) — Progress Report

Current Version: 0.0.21 Last Updated: 2026-03-28

Project Timeline

Phase 0 — Python Prototype (pre-Rust)

The project began as chat.py, a Python WebSocket chat with basic features:

  • Basic chat server + web UI
  • WebSocket SSH tunnel
  • Nginx reverse proxy + ArvanCloud deployment
  • ECDH + AES-GCM DMs (no forward secrecy)
  • Group chat with passwords
  • PWA support
  • File upload

Phase 1 — Identity & Crypto Foundation (Rust Rewrite)

The Rust rewrite established the cryptographic foundation:

Feature Version Status
Cargo workspace scaffold (5 crates) 0.0.1 Done
Seed-based identity (Ed25519 + X25519) 0.0.2 Done
BIP39 mnemonic generation and recovery 0.0.2 Done
Seed encryption at rest (Argon2id + ChaCha20-Poly1305) 0.0.3 Done
Pre-key bundle generation and storage 0.0.4 Done
X3DH key exchange implementation 0.0.5 Done
Double Ratchet for 1:1 messaging 0.0.6 Done
Basic server: axum, sled DB, store-and-forward 0.0.4 Done
CLI client with subcommands 0.0.5 Done
WASM bridge (warzone-wasm crate) 0.0.8 Done
Server auth (challenge-response, bearer tokens) 0.0.9 Done
OTP key replenishment 0.0.9 Done
Fetch-and-delete delivery 0.0.7 Done
Aliases with TTL, recovery keys 0.0.10 Done
17 protocol tests 0.0.10 Done
CLI ↔ Web interop verified 0.0.10 Done

Phase 2 — Core Messaging

Built on the Phase 1 foundation to deliver a complete messaging experience:

Feature Version Status
TUI client (ratatui + crossterm) 0.0.7 Done
Web client (WASM) 0.0.8 Done
WebSocket real-time push 0.0.11 Done
Delivery receipts (sent/delivered/read) 0.0.12 Done
File transfer (chunked, SHA-256 verified) 0.0.13 Done
Group chat (server fan-out) 0.0.10 Done
Group management (create/join/leave/kick) 0.0.14 Done
Sender Keys for group encryption 0.0.15 Done
Message deduplication (bounded FIFO) 0.0.16 Done
Ethereum-compatible identity (secp256k1) 0.0.14 Done
Encrypted backup/restore 0.0.17 Done
Local message history (sled) 0.0.17 Done
Contact list with message counts 0.0.17 Done
Alias auto-renewal on activity 0.0.18 Done
Multi-device key registration 0.0.18 Done
DB lock handling with user-friendly errors 0.0.19 Done
Readline-style TUI editing (Ctrl-A/E/U/W) 0.0.19 Done
Reply shortcut (/r, /reply) 0.0.19 Done
28 protocol tests 0.0.20 Done

Phase 2.5 — WZP Integration & TUI Overhaul (v0.0.21)

Feature Version Status
warzone-protocol standalone-importable 0.0.21 Done
CallSignal WireMessage variant 0.0.21 Done
Auth token validation endpoint 0.0.21 Done
TUI modular split (7 modules from 1) 0.0.21 Done
TUI message timestamps [HH:MM] 0.0.21 Done
TUI message scrolling (PageUp/Down/arrows) 0.0.21 Done
TUI connection status indicator 0.0.21 Done
TUI unread message badge 0.0.21 Done
TUI /help command 0.0.21 Done
TUI terminal bell on incoming DM 0.0.21 Done
44 TUI unit tests (types, input, draw) 0.0.21 Done
Call state management (server) 0.0.21 Done
WS call signaling awareness 0.0.21 Done
Group-to-room mapping + group call API 0.0.21 Done
Presence/online status API 0.0.21 Done
Missed call notifications 0.0.21 Done
WZP relay config + CORS 0.0.21 Done
WZP submodule: all 9 S-tasks done 0.0.21 Done
72 total tests (28 protocol + 44 client) 0.0.21 Done

Current Version: v0.0.21

Codebase Statistics

Metric Value
Crates 5 (protocol, server, client, wasm, mule)
Total tests 72 (28 protocol + 44 client)
Server routes 12 files, 9 new endpoints
TUI modules 7 (split from 1 monolith)
Rust edition 2021
Min Rust version 1.75
License MIT

Protocol Crate Modules

Module Approximate Scope
identity Seed, keypair derivation, fingerprints
crypto HKDF, ChaCha20-Poly1305 AEAD
prekey Signed + one-time pre-keys
x3dh Extended Triple Diffie-Hellman
ratchet Double Ratchet state machine
message WireMessage (8 variants incl. CallSignal)
sender_keys Sender Key encrypt/decrypt/rotate
history Encrypted backup format
ethereum secp256k1, Keccak-256, EIP-55
types Fingerprint, DeviceId, SessionId
mnemonic BIP39 encode/decode
store Storage trait definitions
errors Error types

Feature Summary

Working end-to-end:

  • 1:1 encrypted DMs with forward secrecy (X3DH + Double Ratchet)
  • Group messaging with Sender Keys
  • WebSocket real-time delivery + offline queue
  • File transfer (up to 10 MB, chunked, SHA-256 verified)
  • Delivery and read receipts
  • TUI client with full command set
  • Web client (WASM) with identical crypto
  • Alias system with TTL, recovery, admin
  • Challenge-response authentication
  • Ethereum address derivation from same seed
  • Encrypted backup and restore
  • Contact list and message history
  • Multi-device support (basic)

Test Suite

72 tests across protocol + client crates:

Protocol Tests (28)

Module Tests Coverage
identity 3 Deterministic derivation, mnemonic roundtrip, fingerprint format
crypto 4 AEAD roundtrip, wrong key, wrong AAD, HKDF determinism
x3dh 1 Shared secret match between Alice and Bob
ratchet 5 Basic, bidirectional, multiple, out-of-order, 100 messages
sender_keys 4 Basic encrypt/decrypt, multiple messages, rotation, old key rejection
ethereum 5 Deterministic derivation, address format, checksum, sign/verify, different seeds
history 2 Roundtrip encryption, wrong seed rejection
prekey 3 SPK verify, tamper detection, OTPK generation
mnemonic 1 BIP39 roundtrip

Client Tests (44)

Module Tests Coverage
tui::types 10 App init, scroll/connected defaults, ChatLine timestamps, normfp, add_message
tui::input 25 8 text editing, 7 cursor movement, 2 quit, 8 scroll keybindings
tui::draw 9 Rendering smoke, header fingerprint, connection dot (red/green), timestamps, scroll show/hide, unread badge

Bugs Fixed

Bug Version Fixed Description
X3DH OTPK mismatch 0.0.8 Web client regenerated SPK on each page load, causing X3DH failures. Fixed by persisting SPK secret in localStorage and restoring on load.
Axum route syntax 0.0.11 Route path parameters used wrong syntax for axum 0.7. Updated to /:param format.
WASM SPK regeneration 0.0.12 WasmIdentity regenerated pre-keys on every bundle_bytes() call. Fixed by caching the bundle and storing SPK secret bytes.
DB lock handling 0.0.19 sled database lock caused cryptic panic when another warzone process was running. Added user-friendly error message with recovery instructions.
Dedup overflow 0.0.16 Dedup tracker grew unbounded. Fixed with FIFO eviction at 10,000 entries.
Alias normalization 0.0.18 Fingerprints with colons caused lookup failures. Added normalize_fp() to strip non-hex characters.
Receipt routing 0.0.12 Receipts sent to wrong fingerprint when switching peers in TUI. Fixed by including correct sender_fingerprint in Receipt wire messages.

Known Issues and Limitations

Current Limitations

  1. No perfect forward secrecy in groups: Sender Keys provide forward secrecy within a chain but not per-message PFS like Double Ratchet. Acceptable for groups under 50 members.

  2. No sealed sender: The server sees sender and recipient fingerprints in message routing metadata. Planned for Phase 6.

  3. No server-at-rest encryption: The sled database on the server is unencrypted. Message content is E2E encrypted, but metadata (fingerprints, timestamps, group membership) is visible to the server operator.

  4. Auth tokens in memory: Challenge-response tokens are partially stored in memory (challenges are in a static HashMap). Production deployment should use the DB for all auth state.

  5. No rate limiting: No protection against message flooding or registration spam. Planned for Phase 7.

  6. Single server only: No federation between servers yet. Planned for Phase 3.

  7. No push notifications: Users must keep a WebSocket connection open or poll. ntfy integration planned for Phase 7.

  8. Web client: no OTPKs: The web client does not generate one-time pre-keys (cannot reliably store secrets). X3DH works without DH4, but replay protection is slightly weaker.

  9. Web client: localStorage only: Seed and session data stored in browser localStorage. Clearing browser data = lost identity.

  10. No message ordering guarantees: Messages may arrive out of order. The Double Ratchet handles this for decryption, but the UI does not reorder displayed messages.

Roadmap: What's Next

Phase 3 — Federation & Key Transparency (next priority)

  • DNS TXT record format for server discovery
  • User self-signed key publication to DNS
  • Key verification: server vs DNS cross-check
  • Server-to-server mutual TLS
  • Federated message delivery
  • Server key pinning (TOFU)
  • Gossip-based peer discovery

Phase 4 — Warzone Delivery

  • Mule protocol specification and implementation
  • Mule authentication and authorization
  • Message pickup with capacity declaration
  • Delivery receipt enforcement
  • Outer encryption layer (hide metadata from mule)
  • Bundle compression (zstd)
  • Mule CLI binary

Phase 5 — Transport Fallbacks

  • Bluetooth mule transfer (phone-to-phone)
  • LoRa transport layer (compact binary format)
  • mDNS / LAN discovery for local mesh
  • Wi-Fi Direct for nearby device sync

Phase 6 — Metadata Protection

  • Sealed sender (server doesn't know the sender)
  • Onion routing between federated servers (opt-in)
  • Padding and traffic shaping
  • Traffic analysis resistance

Phase 7 — Polish & Operations

  • ntfy push notification integration
  • DNS-over-HTTPS for censored networks
  • Admin CLI for server management
  • Rate limiting and abuse prevention
  • Monitoring and health checks
  • Audit logging
  • Server-at-rest encryption (optional --encrypt-db flag)
  • Cross-compilation CI (Linux x86/ARM, macOS, Windows, WASM)
  • PWA: service worker, offline shell, install prompt

Priority Order (Updated v0.0.21)

  1. Security (FC-P1) — auth enforcement, rate limiting, device revocation
  2. TUI call integration (FC-P2) — /call, /accept, /hangup commands
  3. Web call integration (FC-P3) — WASM CallSignal + browser call UI
  4. Protocol hardening (FC-P4) — session/message versioning
  5. Federation (Phase 3) — multi-server deployment
  6. Mule protocol (Phase 4) — physical delivery
  7. Polish (FC-P6) — search, reactions, typing indicators

See TASK_PLAN.md for the detailed task breakdown with IDs and dependencies.

Reference in New Issue View Git Blame Copy Permalink