Roadmap
Kimosabe.AI is built in honest phases. We ship Phase 1 as a real product, then expand the surface area without ever weakening the privacy core.
Phase 1 — MVP (current)
Goal: A real, end-to-end encrypted cloud messenger as an installable PWA.
| Status | Item |
|---|---|
| ✅ | Email + password auth via Lovable Cloud |
| ✅ | Username discovery (@handle) |
| ✅ | Identity keypair (ECDH P-256) generated in browser at signup |
| ✅ | Recovery key (one-time, 120-bit) — re-wraps private key |
| ✅ | Wrapped private key stored server-side as ciphertext |
| ✅ | 1:1 E2EE chat (AES-GCM-256 + ECDH) |
| ✅ | Realtime delivery via Supabase Realtime |
| ✅ | Disappearing messages — per-conversation TTL (off / 1d / 7d) |
| ✅ | Encrypted image attachments |
| ✅ | Settings: change password, rotate recovery key, export identity, delete account |
| ✅ | Passwordless recovery flow (zero-knowledge edge function) |
| ✅ | Landing + /trust page (public threat model) |
| ✅ | PWA manifest + 430px mobile polish |
| ✅ | pg_cron job to purge expired messages server-side |
| ✅ | Delivery + opt-in read receipts |
| ✅ | Service worker for offline thread cache + queued sends |
| 🚧 | Accessibility audit (WCAG 2.2 AA — see STANDARDS.md) |
Phase 2 — Group chats & verified contacts
- Group chat E2EE via MLS (RFC 9420). No custom ratchet.
- Asynchronous handshake via X3DH + Double Ratchet for 1:1 forward secrecy & PCS.
- Safety numbers for out-of-band identity verification (Signal-style).
- Voice notes (encrypted audio attachments — HPKE envelope, RFC 9180).
- Sealed sender (v1) for direct messages.
- Encrypted push notifications — server pushes ciphertext envelope; service worker decrypts.
- Optional WebAuthn / Passkeys as a second factor.
See STANDARDS.md for the full spec list and REQUIREMENTS.md for the requirement IDs each item satisfies.
Phase 3 — Metadata reduction
- Sealed sender (v2) for groups.
- Optional Tor-like relay to hide IPs from the server.
- Encrypted profile data — display name, avatar wrapped to contacts only.
- Federated identity attestation so users can prove control of an external handle (Mastodon, GitHub, etc.) without uploading it to us.
Phase 4 — Off-grid (NATIVE app, not web)
The web app cannot do mesh. iOS Safari has no Web Bluetooth, no background execution, and no raw radio access. Phase 4 ships a separate native client that shares the same identity keys and account so users move between web and native seamlessly.
- React Native or Swift/Kotlin client.
- Bluetooth + Wi-Fi-Direct mesh for nearby-device messaging when the internet is down.
- Optional LoRa companion (Meshtastic-compatible) for grid-down scenarios.
- Web app remains the primary surface; the native app is the "off-grid mode."
Phase 5 — Super-app surfaces
Once the messaging core is rock-solid, expand carefully:
- Moments-style feed — encrypted to your contact graph, server-blind.
- P2P payments via a regulated processor (Stripe / Paddle).
- Mini-app container with a strict permission model — apps cannot read messages.
Phase 6 — AI agents (see docs/AGENTS.md)
Agent frameworks like Hermes, OpenClaw, and Agent Zero plug in as first-class users of Kimosabe — they have their own identity keypair, their own recovery key, and they encrypt to you the same way another human would. No backdoors, no special server access. See docs/AGENTS.md for the full integration contract.
Out of scope (forever)
These are not on the roadmap. They would compromise the core promise.
- Server-side message search.
- Plaintext push notifications.
- Backup of message history to any cloud we control.
- Government or operator backdoor of any kind.
- Phone number requirement.
- Contact-graph upload.