manawenuz/featherChat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
95 Commits 3 Branches 0 Tags
210fbbb35b826c5dc32eb5236cf574ac6a9a31a0
Commit Graph

11 Commits

Author SHA1 Message Date
Siavash Sameni
210fbbb35b feat: bot alias reservation + BOT_API.md documentation 
- Aliases ending with Bot/bot/_bot reserved for registered bots only
- Non-bot users get clear error directing to /v1/bot/register
- Bot registration auto-creates alias (@name_bot suffix)
- BOT_API.md: full developer guide with endpoints, examples, echo bot
- LLM_HELP.md: expanded bot section with update types + Python example

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-29 07:34:45 +04:00
Siavash Sameni
7b72f7cba5 feat: friend list, bot API, ETH addressing, deep links, docs overhaul 
Tier 1 — New features:
- E2E encrypted friend list: server stores opaque blob (POST/GET /v1/friends),
  protocol-level encrypt/decrypt with HKDF-derived key, 4 tests
- Telegram Bot API compatibility: /bot/register, /bot/:token/getUpdates,
  sendMessage, getMe — TG-style Update objects with proper message mapping
- ETH address resolution: GET /v1/resolve/:address (0x.../alias/@.../fp),
  bidirectional ETH↔fp mapping stored on key registration
- Seed recovery: /seed command in TUI + web client
- URL deep links: /message/@alias, /message/0xABC, /group/#ops
- Group members with online status in GET /groups/:name/members

Tier 2 — UX polish:
- TUI: /friend, /friend <addr>, /unfriend <addr> with presence checking
- Web: friend commands, showGroupMembers() on group join
- Web: ETH address in header, clickable addresses (click→peer or copy)
- Bot: full WireMessage→TG Update mapping (encrypted base64, CallSignal,
  FileHeader, bot_message JSON)

Documentation:
- USAGE.md rewritten: complete user guide with all commands
- SERVER.md rewritten: full admin guide with all 50+ endpoints
- CLIENT.md rewritten: architecture, commands, keyboard, storage
- LLM_HELP.md created: 1083-word token-optimized reference for helper LLM

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-29 07:31:54 +04:00
Siavash Sameni
f8eaf30bb4 refactor: federation uses persistent WS instead of HTTP polling 
- Server-to-server communication via WebSocket at /v1/federation/ws
- Auth as first WS frame (shared secret), presence + forwards over same connection
- Auto-reconnect every 3s on disconnect, instant presence push on connect
- Replaces HTTP REST polling (no more 5s intervals, lower latency)
- Removed dead HMAC helpers (auth is now direct secret comparison over WS)
- Simplified ARCHITECTURE.md mermaid diagrams for Gitea rendering

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-28 16:56:13 +04:00
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
Siavash Sameni
65f639052e Append WZP integration tasks to FUTURE_TASKS.md (238→676 lines) 
featherChat side (10 tasks):
  WZP-FC-1: CallSignal WireMessage variant (2-4h)
  WZP-FC-2: Call state management + sled tree (1-2d)
  WZP-FC-3: WS handler for call signaling (0.5d)
  WZP-FC-4: Auth token validation endpoint (2-4h)
  WZP-FC-5: Group-to-room mapping (1d)
  WZP-FC-6: Presence/online status API (0.5-2d)
  WZP-FC-7: Missed call notifications (0.5d)
  WZP-FC-8: Cross-project identity verification test (2-4h) CRITICAL
  WZP-FC-9: HKDF salt investigation — VERIFIED: no mismatch (b""→None == None)
  WZP-FC-10: WZP web bridge shared auth (1-2d)

WZP side suggestions (9 items):
  WZP-S-1 through WZP-S-9 covering auth, signaling bridge,
  room access control, proto publishing, CLI flags, and
  6 hardcoded assumptions that conflict with integration.

All tasks reference specific file:line in both codebases.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-28 08:50:13 +04:00
Siavash Sameni
007ca7521d FUTURE_TASKS.md: 18 optional tasks with questions-before-starting 
High priority:
  1. Auth enforcement middleware
  2. Session auto-recovery
  3. Crypto audit plan

Medium priority:
  4. Extract web client from monolith
  5. Session state versioning
  6. Periodic auto-backup
  7. WireMessage versioning

Normal priority:
  8. Mule binary implementation
  9. libsignal migration assessment
  10. OIDC identity provider
  11. Smart contract ACL
  12. DNS federation
  13. WarzonePhone integration

Low priority:
  14. Message search
  15. Read receipts
  16. Typing indicators
  17. Message reactions
  18. Voice messages

Each task includes: what, why, effort estimate, and blocking
questions that must be answered before work begins.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-28 08:21:14 +04:00
Siavash Sameni
de1ce77fea IDP_SMART_CONTRACT.md: featherChat as IdP + on-chain ACL (1111 lines) 
featherChat as Identity Provider:
- OIDC provider endpoints (/auth/oidc/authorize, /token, /userinfo)
- JWT tokens with fingerprint, alias, eth_address, groups claims
- Authentik integration (featherChat as upstream IdP, group sync)
- SAML support for enterprise

Smart Contract Access Control:
- FeatherChatACL Solidity contract (server/group/feature access)
- secp256k1 address from same BIP39 seed = on-chain identity
- NFT-gated access (ERC-721/ERC-1155 membership)
- Token-gated access (ERC-20 staking)
- DAO governance for group membership decisions
- UUPS upgradeable proxy pattern

Hybrid architecture:
- OIDC token carries on-chain permissions as claims
- Event-driven sync (WebSocket RPC + periodic poll + sled cache)
- L2 deployment (Arbitrum/Base/Polygon) for low gas costs

Feasibility: 7-11 weeks across 4 phases.
Comparison with SpruceID, Ceramic, Lens, XMTP.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-28 08:07:34 +04:00
Siavash Sameni
1c7b39c395 Rewrite WZP_INTEGRATION.md with confirmed code references (1209 lines) 
All [SPECULATIVE] markers replaced with [CONFIRMED] from actual WZP code.

Key discoveries:
- HKDF info string mismatch: featherChat uses "warzone-ed25519",
  WZP uses "warzone-ed25519-identity" — same seed, different keys.
  Requires 2-line fix in wzp-crypto/src/handshake.rs before integration.
- Media is NOT DTLS-SRTP: WZP uses ephemeral X25519 DH + ChaCha20-Poly1305
  with deterministic nonces (WireGuard-like, not WebRTC-like)
- Transport is QUIC (quinn), not WebRTC/ICE
- FEC is RaptorQ fountain codes, not Opus inband
- 5 codecs: Opus 24k → Codec2 1200bps with adaptive switching
- Relay operates on encrypted packets (zero-knowledge relay)

18 sections with concrete API contracts, code file:line references,
and phased implementation roadmap.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-28 08:02:30 +04:00
Siavash Sameni
f7a517d8ea WZP_INTEGRATION.md: featherChat ↔ WarzonePhone integration spec (1001 lines) 
Covers: shared identity model (same BIP39 seed), authentication flow
(Ed25519 signed tokens), call signaling via WireMessage::CallSignal,
DTLS-SRTP media encryption bootstrapped from Double Ratchet,
group calls (SFU + Sender Keys), warzone scenarios (voice messages
as attachments, mule delivery for missed calls).

Phased roadmap: shared identity → signaling → encrypted calls → group calls.

featherChat-side details confirmed against code.
WZP-side details marked [SPECULATIVE] (WZP codebase was inaccessible).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-28 05:38:45 +04:00
Siavash Sameni
2dbbc61dfe Comprehensive documentation: architecture, usage, integration, progress, security 
docs/ARCHITECTURE.md (531 lines):
  System design, ASCII diagrams, crypto stack, dual-curve identity,
  wire protocol (7 WireMessage variants), server/client architecture,
  data flow diagrams, storage model, extensibility points

docs/USAGE.md (550 lines):
  Complete user guide: installation, all CLI commands (10),
  all TUI commands (20+), all web commands, file transfer,
  identity management, aliases, groups, multi-device, backup,
  keyboard shortcuts

docs/INTEGRATION.md (542 lines):
  WarzonePhone concept, Ethereum/Web3, OIDC, DNS federation,
  transport abstraction, multi-server mode, custom clients,
  ntfy, how-to guides for extending message types/commands/storage

docs/PROGRESS.md (234 lines):
  Timeline, Phase 1 (16 features), Phase 2 (16 features),
  v0.0.20, 28 tests, bugs fixed, known limitations, Phase 3-7 roadmap

docs/SECURITY.md (438 lines):
  Threat model, 8 crypto primitives, key derivation paths,
  forward secrecy, Sender Keys trade-offs, seed security,
  server trust, WASM security, known weaknesses,
  comparison with Signal/Matrix/SimpleX

Total: 3,751 lines across 8 doc files.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-28 05:25:46 +04:00
Siavash Sameni
60a7006ed9 Add documentation: protocol spec, server admin, client guide 
docs/PROTOCOL.md (520 lines):
- Identity model (seed → Ed25519 + X25519 via HKDF)
- X3DH key exchange (4 DH operations, ASCII flow diagram)
- Double Ratchet (chain/DH ratchet, skipped keys, state machine)
- KDF chains with domain separation strings
- AEAD (ChaCha20-Poly1305)
- Wire format (WireMessage enum, bincode serialization)
- Pre-key bundle format and lifecycle

docs/SERVER.md (429 lines):
- Build and run instructions
- Full API reference with request/response examples
- Database structure (sled trees)
- Deployment (nginx reverse proxy, systemd unit)
- Security considerations
- Backup and recovery

docs/CLIENT.md (507 lines):
- Quick start guide
- All CLI commands with examples
- Identity management and mnemonic backup
- Web client usage and limitations
- Session and pre-key management
- Threat model table
- Troubleshooting guide

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-26 21:59:19 +04:00