Plan — bahalaka Buildout
Full C core. Vanilla HTML/JS frontend. No frameworks. Ship to phones.
The Architecture Decision
The Question
The original plan said Flutter. But Flutter is a framework — a big one. You said full C, roll your own, HTML and JS. So what actually ships to phones?
Recommended: C + WASM + Vanilla HTML/JS + Capacitor
- C core → WebAssembly — compile crypt.c, aes_gcm.c, sha256.c, journal.c, wire.c, store.c to WASM via Emscripten. Your security stack runs in pure C in the browser. No JavaScript reimplementation. No trust issues.
- Frontend → Vanilla HTML/CSS/JS — exactly what bahalaka.com is now. You already know how to build it. No React, no Vue, no framework. Just the DOM.
- Mobile → Capacitor — thin native shell wrapping your web app. One codebase → iOS + Android. Gives you GPS, camera, push notifications, biometrics. The shell is ~50 lines of config. Your app is still HTML/JS.
- Server → Pure C relay — relay_server.c already exists. Stores encrypted blobs. Nothing to build.
Why Not Flutter
- Flutter is 200MB+ SDK, Dart language, widget trees, state management patterns
- Your C code needs FFI bindings — a layer of glue you'd maintain forever
- You'd learn a whole new UI framework instead of using HTML/JS you already own
- If Flutter dies or pivots, your app dies with it
Why Not PWA Alone
- iOS limits PWA capabilities — no background sync, limited push, no GPS in background
- Capacitor gives you native APIs without the framework tax
- PWA is the fallback — if someone hits bahalaka.com in a browser, it just works
The Stack
Four Layers
- Layer 1 — C Engine (WASM)
crypt.c + aes_gcm.c + sha256.c + journal.c + store.c + wire.c + policy.c + audit_engine.c
Compiled to libbahalaka.wasm via Emscripten. Runs client-side. All crypto, all storage, all policy enforcement happens here. JS never touches a key.
- Layer 2 — JS Bridge
Thin wrapper: bahalaka.js — calls into WASM exports.
bahalaka.encrypt(msg), bahalaka.sign(data), bahalaka.journal.append(entry)
~500 lines. Translates between DOM events and C functions.
- Layer 3 — UI (HTML/CSS/JS)
Vanilla. No build step. No bundler. No framework.
Pages: login, chat, status, schedule, finances, agreements, stories, settings
Same dark theme, same approach as bahalaka.com today.
- Layer 4 — Native Shell (Capacitor)
Wraps the web app for iOS + Android.
Provides: GPS (status verification), camera (grade proofs), push notifications, biometric unlock
Config only — no native code to write.
Build Phases
Phase 1 — Foundation ~2 weeks
Get C running in the browser. Prove the architecture.
- Emscripten build chain: compile crypt.c + aes_gcm.c + sha256.c → WASM
- bahalaka.js bridge: key generation, encrypt/decrypt, sign/verify
- journal.c → WASM: append-only log working in browser (IndexedDB backing)
- store.c → WASM: triple store with local persistence
- wire.c → WASM: binary frame encode/decode
- Auth gate: TOTP login page (reuse lakemedical.org pattern)
- Demo: Generate keys, encrypt a message, store it, retrieve it, verify signature — all in C/WASM, all in the browser
Phase 2 — Chat ~3 weeks
Forward-only messaging. The core of the app.
- WebSocket connection to relay_server.c
- Noise Protocol XX handshake (compose from crypt.c + wire.c)
- Message send/receive: text, photo, voice memo
- Forward-only journal: no delete, no unsend, edits preserve original
- Read receipts + typing indicators (always on)
- Offline queue: messages encrypted + stored locally, sent on reconnect
- Chat UI: vanilla HTML/JS, dark theme, mobile-first
Phase 3 — Status + Schedule ~2 weeks
Asymmetric visibility. Geo-verified presence.
- status.c → WASM: manage status states (home/work/school/friend/favorite)
- GPS integration via Capacitor: auto-match to registered locations
- Provider dashboard: see all connections' statuses, invisible to them
- Schedule UI: calendar view, time request flow, approve/decline
- schedule.c: compose from store.c + journal.c + policy.c
- Complete isolation: connection A never sees connection B
Phase 4 — Finances ~3 weeks
Allowance, savings, sponsorships, sponsor requests. The ledger is the truth.
- ledger.c: compose from journal.c + store.c — append-only financial log
- Allowance engine: cycles, withholding, disbursement journal entries
- Savings: running balance computed from journal (no mutable balance field)
- Sponsorships: institution tracking, grade proof uploads (camera via Capacitor), semester lifecycle
- Sponsor requests: submit → in discussion → approved/denied → funded (forward-only state machine)
- Financial dashboard: provider view (total outflow, savings held, pending) + connected person view
Phase 5 — Agreements + Trust ~3 weeks
The agreement system. Promises. Concern detection.
- agreement.c: compose from store.c + journal.c + crypt.c — template selection, dual Ed25519 signatures, 48-hour cooling period
- 3-part template system: Her Ask (7) + His Declaration Part 1 (7) + Part 2 (3) = 147 combinations
- Mismatch detection: flag conflicts before signing
- declare.c: intentions, dreams, promises (with deadline tracking), commitments (mutual sign)
- concern.c: compose from audit_engine.c + journal.c — pattern detection across 7 signal types
- Provider-only dashboard for concern flags
Phase 6 — Stories + Polish ~2 weeks
Field guide. Onboarding. Final UX pass.
- Stories engine: curated content, tagged, searchable, forward-only archive
- Contextual suggestions when concern patterns detected
- Onboarding flow: key generation, identity creation, first-week story set
- Settings: notification preferences, location management, connection management
- Capacitor build: iOS + Android packages
Phase 7 — Ship ~1 week
Deploy, test with friends, iterate.
- Relay server deployment (relay_server.c — already exists)
- Capacitor → App Store + Play Store submission
- Web version live at bahalaka.com (replaces proposal with app)
- Friends-only invite codes
- Feedback loop: real usage → fix → ship → repeat
New C Modules
6 Composed from Existing
ledger.c — financial engine (journal.c + store.c)schedule.c — calendar + time requests (store.c + journal.c + policy.c)declare.c — promises, commitments, intentions (journal.c + crypt.c)agreement.c — template system + signatures (store.c + journal.c + crypt.c)concern.c — pattern detection (audit_engine.c + journal.c)noise_xx.c — Noise Protocol XX handshake (crypt.c + wire.c)
2 Fresh
bahalaka.js — WASM bridge (~500 LOC)UI pages — vanilla HTML/CSS/JS (login, chat, status, schedule, finances, agreements, stories, settings)
What Stays, What Goes
Stays
- Pure C for all crypto, storage, policy, audit — compiled to WASM
- Vanilla HTML/CSS/JS for all UI — no frameworks
- relay_server.c as the backend — stores noise, no keys
- Dark theme, mobile-first, same design language as today
- Cloudflare Pages for hosting (web version)
Goes
- Flutter — replaced by Capacitor (thin native shell, your web app inside)
- Dart — replaced by JS (you already write it)
- Dart FFI — replaced by WASM bridge (simpler, no native compilation per platform)
- Firebase/Firestore for comments — replaced by your own relay + journal (sovereign)
Constraints
- No external JS dependencies. If it's not vanilla, don't use it.
- No build tools for the frontend. No webpack, no vite, no bundler. Load the HTML.
- WASM is the only "build" — Emscripten compiles C, outputs .wasm + glue .js.
- Capacitor is config, not code — capacitor.config.ts + native project scaffolding.
- Every feature journal-logged. No mutable state. Forward-only everywhere.
- Server never sees plaintext. Encrypted blobs in, encrypted blobs out.