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>
This commit is contained in:
Siavash Sameni
238
warzone/docs/FUTURE_TASKS.md
Normal file
238
warzone/docs/FUTURE_TASKS.md
Normal file
@@ -0,0 +1,238 @@
|
||||
# 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.*
|
||||
Reference in New Issue
Block a user