manawenuz/featherChat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
007ca7521d0fa675e20603b03d3ec58a48ed65cd
featherChat/warzone/docs/FUTURE_TASKS.md
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

9.7 KiB
Raw Blame History

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 View Git Blame Copy Permalink