# Future Tasks & Improvement Suggestions

These are optional improvements identified during development. Each includes context, effort estimate, and questions to answer before starting.

---

## Priority: High (Security/Reliability)

### 1. Auth Enforcement Middleware
**What:** Add axum middleware to enforce bearer tokens on protected endpoints.
**Why:** Currently anyone can impersonate any fingerprint — the auth system issues tokens but doesn't require them.
**Effort:** Half a day (~200 lines)
**Blocked by:** Nothing — can be done now.

**Questions before starting:**
- [ ] Should we enforce auth on all `/v1/*` routes or only write operations (send, groups, aliases)?
- [ ] Should the web client use cookie-based auth (simpler) or bearer tokens (consistent with CLI)?
- [ ] What's the token refresh strategy — silent refresh or re-auth on expiry?

---

### 2. Session Auto-Recovery
**What:** When ratchet decryption fails (corrupted state), auto-send a new X3DH KeyExchange to re-establish the session.
**Why:** Currently a corrupted session = permanent inability to decrypt from that peer until manual intervention.
**Effort:** 1 day

**Questions before starting:**
- [ ] Should we show a warning ("security session was reset") like Signal does?
- [ ] Should we keep the old corrupted session state for debugging, or just delete it?
- [ ] How many auto-recovery attempts before giving up (prevent infinite loops)?

---

### 3. Crypto Audit Plan
**What:** Prepare the codebase for a professional cryptographic audit.
**Why:** We implemented X3DH + Double Ratchet from scratch. Production use requires independent verification.
**Effort:** 1 week (documentation + code cleanup), then $20-50K for audit firm

**Questions before starting:**
- [ ] Do we want to audit now (before federation) or after Phase 3?
- [ ] Budget range? Trail of Bits (~$50K), Cure53 (~$30K), NCC Group (~$40K)?
- [ ] Should we migrate to libsignal instead? (Avoids audit but loses WASM + static binary)

---

## Priority: Medium (Architecture/Quality)

### 4. Extract Web Client from Monolith
**What:** Split the ~1000-line JS embedded in `web.rs` into separate files (app.js, crypto.js, ws.js, ui.js, style.css).
**Why:** Currently unmaintainable — one raw string in Rust containing all HTML/CSS/JS.
**Effort:** 1-2 days, zero functionality change

**Questions before starting:**
- [ ] Serve as static files from disk, or embed multiple files at compile time?
- [ ] Use ES modules (modern) or keep everything global (simpler)?
- [ ] Add a minimal build step (esbuild for bundling) or keep it build-free?

---

### 5. Session State Versioning
**What:** Add version byte to serialized ratchet/session state. Migrate old formats instead of failing.
**Why:** Any change to `RatchetState` struct breaks all existing sessions silently.
**Effort:** Half a day

**Questions before starting:**
- [ ] Just a version prefix byte, or a full envelope format (version + length + data)?
- [ ] Should we support migrating from v1→v2, or just re-establish sessions on version mismatch?

---

### 6. Periodic Auto-Backup
**What:** Automatically backup session state + contacts + history every N minutes to an encrypted local file.
**Why:** Currently backup is manual (`warzone backup`). If the process crashes, unsaved sessions are lost.
**Effort:** Half a day

**Questions before starting:**
- [ ] Backup interval? Every 5 minutes? Every new session? On quit?
- [ ] Where to store? Same directory as DB? Configurable?
- [ ] Keep N backups with rotation, or just latest?

---

### 7. WireMessage Versioning
**What:** Add a version field or envelope around the bincode `WireMessage` so old clients don't crash on new message types.
**Why:** Adding a new enum variant to `WireMessage` is a breaking change for all existing clients.
**Effort:** 1 day (careful, touches everything)

**Questions before starting:**
- [ ] Prefix with version byte before bincode, or switch to a self-describing format (protobuf, msgpack)?
- [ ] How do old clients handle unknown message types — ignore silently or show "update required"?
- [ ] Is this the right time to consider protobuf migration for the wire format?

---

## Priority: Normal (Features)

### 8. Mule Binary Implementation
**What:** Build the `warzone-mule` binary for physical message delivery between disconnected networks.
**Why:** Core warzone use case — the design is complete (DESIGN.md section 4) but no code exists.
**Effort:** 3-5 days

**Questions before starting:**
- [ ] Start with USB/file transport only, or include Bluetooth from the start?
- [ ] Do we need a mule GUI, or is CLI sufficient?
- [ ] How do we test this? Two isolated Docker networks? Physical devices?
- [ ] Should the mule have its own identity (keypair), or is it anonymous?

---

### 9. libsignal Migration Assessment
**What:** Evaluate replacing our custom X3DH + Double Ratchet with libsignal-client.
**Why:** Battle-tested, audited. But has trade-offs.
**Effort:** 1-2 weeks if we decide to do it

**Questions before starting:**
- [ ] Can we accept the BoringSSL C dependency? (Breaks pure Rust, complicates cross-compilation)
- [ ] libsignal doesn't support WASM — do we keep dual implementations (libsignal native + our ratchet for WASM)?
- [ ] Is the storage trait adaptation worth it? Their `IdentityKeyStore`/`SessionStore` are different from ours.
- [ ] Would an audit of our implementation be cheaper and better?

---

### 10. featherChat as OIDC Identity Provider
**What:** Add OIDC provider endpoints so external services (Authentik, Keycloak, Grafana) can use featherChat for SSO.
**Why:** Makes featherChat the identity backbone for an entire organization.
**Effort:** 1-2 weeks (see IDP_SMART_CONTRACT.md)

**Questions before starting:**
- [ ] OIDC only, or also SAML for enterprise environments?
- [ ] What claims to include in the JWT? (fingerprint, alias, eth_address, groups)
- [ ] Should Authentik integration be a priority, or generic OIDC first?
- [ ] Do we need a consent screen / authorization UI?

---

### 11. Smart Contract Access Control
**What:** Deploy a Solidity contract for on-chain permission management (server/group/feature access).
**Why:** Decentralized, auditable, censorship-resistant permissions.
**Effort:** 3-4 weeks (see IDP_SMART_CONTRACT.md)

**Questions before starting:**
- [ ] Which L2? Arbitrum, Base, Polygon, or deploy our own?
- [ ] Who pays gas? Admin only, or users too?
- [ ] Is NFT-gated access a priority, or start with simple ACL?
- [ ] How do we handle users who don't have a wallet? (featherChat-managed vs self-custody)

---

### 12. DNS Federation
**What:** Server discovery via DNS TXT records, server-to-server message relay.
**Why:** Multiple servers, no single point of failure.
**Effort:** 2-3 weeks (Phase 3)

**Questions before starting:**
- [ ] Do we run our own DNS server, or use existing infrastructure?
- [ ] DNSSEC required or optional?
- [ ] How do we handle split-brain (two servers think they're authoritative for the same user)?
- [ ] Is gossip discovery (no DNS) a sufficient fallback for warzone scenarios?

---

### 13. WarzonePhone Integration
**What:** Shared identity + call signaling through featherChat (see WZP_INTEGRATION.md).
**Why:** One seed, one identity, chat + calls.
**Effort:** 4-8 weeks across 4 phases

**Questions before starting:**
- [ ] Fix the HKDF info string mismatch first (`"warzone-ed25519"` vs `"warzone-ed25519-identity"`)?
- [ ] Who aligns — featherChat or WZP? (featherChat has more users/data to migrate)
- [ ] Start with shared identity only (Phase A), or jump to signaling (Phase B)?
- [ ] QUIC transport (WZP's choice) — should featherChat also adopt QUIC for messaging?

---

## Priority: Low (Polish/Nice-to-Have)

### 14. Message Search
**What:** Full-text search across local message history.
**Why:** "What was that config someone shared last week?"
**Effort:** 1 day (sled scan + substring match), 1 week (proper full-text index)

**Questions before starting:**
- [ ] Simple substring search, or proper full-text (tantivy crate)?
- [ ] Search across all contacts, or per-peer?
- [ ] Web client search too, or CLI only?

---

### 15. Read Receipts
**What:** Currently we have Delivered receipts. Add Read receipts (when user scrolls to/sees the message).
**Why:** Users want to know if their message was read, not just delivered.
**Effort:** Half a day

**Questions before starting:**
- [ ] Should read receipts be opt-in (privacy sensitive)?
- [ ] What constitutes "read"? Message visible in viewport for N seconds?
- [ ] TUI: is "displayed on screen" equivalent to "read"?

---

### 16. Typing Indicators
**What:** Show "User is typing..." when a peer is composing a message.
**Why:** UX polish.
**Effort:** Half a day

**Questions before starting:**
- [ ] Privacy concern — do we want to leak typing activity?
- [ ] Should this be opt-in?
- [ ] Encrypted or plaintext? (Plaintext is simpler, typing indicators aren't sensitive)

---

### 17. Message Reactions (Emoji)
**What:** React to a message with an emoji instead of a full reply.
**Why:** Quick acknowledgment without cluttering the chat.
**Effort:** 1 day

**Questions before starting:**
- [ ] New WireMessage variant, or encode as a special text message?
- [ ] Display inline (next to message) or as a separate line?
- [ ] Multiple reactions per message?

---

### 18. Voice Messages as Attachments
**What:** Record audio in the client, send as file attachment.
**Why:** Voice messages are critical in field use. Uses existing file transfer — no new protocol needed.
**Effort:** 1 day (CLI: pipe from mic, Web: MediaRecorder API)

**Questions before starting:**
- [ ] Codec? Opus at 16kbps is good. Or Codec2 for LoRa-compatible ultra-low bitrate?
- [ ] Max duration? 60 seconds? 5 minutes?
- [ ] Inline playback in web client, or download-only?

---

*Last updated: v0.0.20*
*To work on a task: answer the questions first, then implement.*