Plan — bahalaka Complete App (v2)

Pure C → WASM. Nous wire protocol for everything. Vanilla HTML/JS. Zero frameworks. Ship to phones.
Updated after comparison with NOUS Desktop → Pantheon decoupling plan.

Intent

Build bahalaka as a sovereign relationship platform where every byte of data flows through the nous wire protocol (NTRP0001) via nous relay servers. No Firebase. No REST APIs. No HTTP to the catalog-server. No third-party backends. One channel, one protocol, one door. Every feature is atoms packed by wire.c, encrypted by crypt.c, routed through relay_server.c. The C stack is the app.

Proven Pattern — NOUS Desktop

Same Architecture, Already Working

The NOUS Desktop → Pantheon tool decoupling follows the exact same pattern we're using. Their approach:

Vendor the C SDK — copy the minimum required sources (wire.c, crypt.c, http.c, pack.c) into an sdk/ folder. Self-contained. No dependency on the full nous tree.
Create a relay client — relay_client.c packs triples, encrypts with cockpit key, sends to relay, decrypts response. All backend communication through the relay. No direct calls to catalog-server.
Replace in-process calls with wire requests — where they used to call receive_loop_json_buf() directly, they now pack {loop, action, none} + {question, content, none} triples, encrypt, send to relay. The relay forwards to the intelligence engine and returns the result.
Zero backend changes — the desktop tool adapts to the existing relay/wire API surface. kastil-systems/nous stays as-is.

bahalaka follows this exact pattern. The only difference: browser clients need WebSocket (they can't do raw TCP), and bahalaka introduces new atom verbs that need handlers on the prime.

The One Rule

Everything Is an Atom Through the Relay

User action → JS event → bahalaka.js → WASM (wire.c packs atom) → WASM (crypt.c encrypts)
→ WebSocket → relay (forwards, never reads) → prime (routes by atom verb)
→ prime unpacks → stores as triples → responds via same path

Chat message? Atom through the relay. Status update? Atom through the relay. Financial transaction? Atom through the relay. Agreement signature? Atom through the relay. Comment on the proposal? Atom through the relay. There is no other path.

Why Wire, Not HTTP

The relay is already the authenticated gateway. Auth, encryption, and routing are already solved. Adding HTTP to the catalog-server would mean a second auth path, a second transport, and a second attack surface. Wire keeps it to one channel — one key, one protocol, one door.

This is the same reasoning the NOUS Desktop plan uses. It works. Don't add doors.

NTRP0001 Wire Protocol

Format: binary atom packing, ~30 bytes per atom
Structure: {subject, predicate, object} — every piece of data is a triple
Packing: wire.c → compiled to WASM, runs client-side in the browser
Encryption: crypt.c → AES-256-GCM per atom, Ed25519 signatures
Transport: WebSocket to relay → relay forwards to prime → prime routes by verb
The relay never decrypts. It forwards encrypted blobs. Stores noise.

Architecture

Four Layers

Layer 1 — C Engine (WASM)
Vendored from nous into sdk/: wire.c, crypt.c, aes_gcm.c, sha256.c, pack.c, journal.c, store.c, policy.c + their headers.
Compiled to libbahalaka.wasm via Emscripten. Self-contained — no dependency on the full nous tree. All atom packing, all crypto, all local storage happens in C. JS never touches a key, never packs an atom.
Layer 2 — JS Bridge (our relay_client)
bahalaka.js (~500 LOC) — the browser equivalent of NOUS Desktop's relay_client.c.
Translates DOM events into WASM calls. Manages the WebSocket connection to the relay.
bahalaka.send(verb, data) → WASM packs atom → encrypts → returns binary → JS sends over WebSocket.
bahalaka.recv(binary) → WASM decrypts → unpacks atom → returns JS object → UI renders.
Same pattern as relay_client.c — pack triples, encrypt, send to relay, decrypt response.
Layer 3 — UI (HTML/CSS/JS)
Vanilla. No build step. No bundler. No framework.
Pages: login, chat, status, schedule, finances, agreements, stories, settings.
Dark theme. Mobile-first. Same design language as bahalaka.com today.
Layer 4 — Native Shell (Capacitor)
Wraps the web app for iOS + Android. Provides GPS, camera, push notifications, biometrics.
Config only — no native code to write. webDir: 'app' points to the same folder.

Server Side (Already Running)

Relay (relay_server.c) — 3 regions (Virginia, London, Singapore). Authenticates connections (HMAC + nonce + session token). Forwards encrypted atoms to user's prime. The relay already routes atoms — it doesn't need to know what they mean. It forwards blobs based on session routing. Needs: WebSocket transport layer for browser clients (currently raw TCP only).
Prime (catalog_server.c) — 3 regions (Oregon, Belgium, Taiwan). Receives atoms from relay, decrypts with transport key, unpacks, routes by atom verb. Already handles store queries and intelligence requests. Needs: new atom verb handlers for bahalaka-specific verbs (chat, status, schedule, finance, agree, declare, concern). Per-user store paths.
Scout (google-scout) — Iowa. Content acquisition for stories/field guide.

URL Structure

Three URLs, One Codebase

bahalaka.com/               → proposal site (live now, stays)
bahalaka.com/app/            → the web app (one URL, works everywhere)
bahalaka.com/app/get/        → smart download page (auto-detects OS)

/app/ — The web app. Same HTML/JS/WASM on every device. Also the PWA fallback.
/app/get/ — Auto-detects Android/iOS/desktop. Shows the right store button. One link to share.
Native apps — Capacitor bundles /app/ locally. Never loads from URL. Runs offline.

Folder Structure

bahalaka/
  index.html                  ← proposal site (existing)
  be/                         ← Be artifacts
  app/
    index.html                ← web app shell (loads WASM + bridge)
    bahalaka.js               ← JS bridge / relay client
    bahalaka.conf.js          ← config: relay host, relay port, key paths
    libbahalaka.wasm          ← C→WASM binary
    libbahalaka.js            ← Emscripten glue
    pages/
      login.html              ← TOTP auth
      chat.html               ← forward-only messaging
      status.html             ← GPS-verified presence
      schedule.html           ← calendar + time requests
      finances.html           ← allowance + ledger + sponsorships
      agreements.html         ← templates + dual signing
      stories.html            ← field guide
      settings.html           ← preferences + connections
    css/
      app.css                 ← dark theme, mobile-first
    get/
      index.html              ← smart download page
  sdk/
    wire.c / wire.h           ← vendored from nous
    crypt.c / crypt.h         ← vendored from nous
    aes_gcm.c / aes_gcm.h    ← vendored from nous
    sha256.c / sha256.h       ← vendored from nous
    pack.c / pack.h           ← vendored from nous
    journal.c / journal.h     ← vendored from nous
    store.c / store.h         ← vendored from nous
    policy.c / policy.h       ← vendored from nous
  Makefile                    ← Emscripten build: sdk/ → libbahalaka.wasm

SDK Vendor Strategy

Copy the Minimum, Cut the Cord

Same approach as NOUS Desktop. Copy the self-contained C modules from C:\kastil\nous into sdk/. These modules have zero nous-internal dependencies — they're pure data transforms, pure crypto, pure storage. No #includes reaching back into the nous tree.

wire.c/h — NTRP0001 atom pack/unpack (pure data transform, no I/O)
crypt.c/h — Ed25519, AES-256-GCM, SHA-256 (no platform deps)
aes_gcm.c/h + sha256.c/h — crypto primitives
pack.c/h — binary packing helpers
journal.c/h — append-only log (I/O shimmed to IndexedDB via Emscripten IDBFS)
store.c/h — triple store for local offline cache (I/O shimmed to IDBFS)
policy.c/h — client-side rule enforcement

The Makefile compiles sdk/*.c → app/libbahalaka.wasm + app/libbahalaka.js. No Emscripten reaches outside sdk/.

Configuration

bahalaka.conf.js

Same pattern as NOUS Desktop's desktop.conf. All connection parameters in one file. No hardcoded relay addresses.

const BAHALAKA_CONFIG = {
  relay_host: 'relay-us.3-nous.net',
  relay_port: 8443,
  relay_ws_path: '/ws',
  key_storage: 'indexeddb',       // where Ed25519 keys live
  offline_journal: 'indexeddb',   // local journal backing
  version: '2.0'
};

The bridge reads this at startup. WebSocket connects to wss://{relay_host}:{relay_port}{relay_ws_path}. One channel. One config.

Data Model — Everything as Triples via Wire Protocol

Chat

{msg:a1b2, from, user:joey} {msg:a1b2, to, user:maria} {msg:a1b2, text, "kumusta ka?"} {msg:a1b2, time, 1712345678} {msg:a1b2, sig, ed25519:abc123...}

Each triple is an atom packed by wire.c, encrypted by crypt.c, sent through relay. Forward-only — no delete. Edits create new triples preserving the original.

Status

{user:maria, status, at_home} {user:maria, status_time, 1712345678} {user:maria, location:home, geo:14.5995,120.9842}

GPS auto-matches registered locations via Capacitor. Status transitions are atoms through the relay, journal-logged on prime.

Schedule

{timereq:001, from, user:maria} {timereq:001, to, user:joey} {timereq:001, slot, 2026-04-05T18:00} {timereq:001, status, pending}

Request → approve/decline. All atoms through the relay. Prime enforces isolation — connection A never sees connection B's schedule.

Finances

{allowance:001, recipient, user:maria} {allowance:001, amount, 5000} {allowance:001, cycle, weekly} {disbursement:042, allowance, allowance:001} {disbursement:042, net, 4000} {disbursement:042, sig, ed25519:def456...}

Balance = computed sum of all disbursement + withdrawal triples on prime. No mutable balance field. The ledger is the truth. Every transaction is a signed atom through the relay.

Agreements

{agree:001, her_ask, template:1} {agree:001, his_dec_1, template:III} {agree:001, his_dec_2, template:A} {agree:001, sig_her, ed25519:aaa...} {agree:001, sig_him, ed25519:bbb...} {agree:001, cooling_start, 1712259278}

3-part template system: Her Ask (7) + His Declaration Part 1 (7) + Part 2 (3) = 147 combinations. Dual Ed25519 signatures, 48-hour cooling period enforced by timestamp math. All atoms through the relay.

Concern Detection — reason.c

{concern:c01, type, promise_ratio} {concern:c01, user, user:maria} {concern:c01, kept, 2} {concern:c01, total, 6} {concern:c01, confidence, 0.78}

reason.c walks the triple graph on prime, counts patterns, scores confidence. 7 signal types: promise ratio, request frequency, status anomalies, edit frequency, response asymmetry, schedule conflicts, financial patterns. Results pushed to provider as atoms through the relay.

Comments (Migration)

{comment:c01, section, 3} {comment:c01, author, "Joey"} {comment:c01, text, "this is fire"} {comment:c01, time, 1712345678}

Proposal site comments migrate from Firestore REST API to nous triples. Same UI, same UX — different backend. Comments become atoms through the relay like everything else.

C → WASM Strategy

What Compiles to WASM (Client-Side)

All sources vendored into sdk/. Emscripten compiles only from that folder.

wire.c — NTRP0001 atom pack/unpack. The protocol runs in the browser.
crypt.c — Ed25519 keypair/sign/verify, AES-256-GCM encrypt/decrypt, SHA-256
aes_gcm.c + sha256.c — crypto primitives
pack.c — binary packing helpers
journal.c — local append-only log (IndexedDB backing via Emscripten IDBFS)
store.c — local triple store for offline cache (IndexedDB backing)
policy.c — client-side rule enforcement (cooling periods, forward-only checks)

Output: app/libbahalaka.wasm + app/libbahalaka.js (Emscripten glue)

Exports: wire_pack, wire_unpack, crypt_encrypt, crypt_decrypt, crypt_sign, crypt_verify, crypt_keypair, journal_append, store_insert, store_query

What Stays Server-Side C

relay_server.c — WebSocket + TCP forwarder. Authenticates. Never decrypts. Routes atoms by session.
catalog_server.c — prime. Receives atoms via relay, routes by verb. Stores triples. Runs reason.c.
reason.c — concern detection. Walks the full triple graph. Needs all user data. Server-only.
auth.c — session management, TOTP verification, nonce ring. Server-only.
audit_engine.c — tamper detection, pattern analysis. Server-only.

Server-Side Changes (2 Total)

1. WebSocket Transport on Relay

relay_server.c currently speaks raw TCP (NTRP0001 binary frames). Browser clients can't do raw TCP — they need WebSocket. Add RFC 6455 handshake + frame decode/encode as a transport layer. The NTRP0001 atoms ride inside WebSocket frames. Same protocol, different transport.

NOUS Desktop connects via raw TCP (native C binary). bahalaka connects via WebSocket (browser). Both send the same atoms to the same relay. The relay doesn't care which transport delivered them.

Firewall: Open WebSocket port on relay VMs (Virginia, London, Singapore).

2. Bahalaka Atom Verb Handlers on Prime

The prime already receives atoms from the relay, decrypts them, and routes by content. It already handles store queries and intelligence requests — that's how NOUS Desktop works today.

For bahalaka, we register new atom verb handlers on the prime. Not an HTTP endpoint. Not a new service. Just new verbs that the existing atom routing processes:

chat — store message triples in sender + recipient stores
status — store/query status triples with isolation enforcement
schedule — store/query time request triples
finance — store financial triples, compute balances from journal sums
agree — store agreement triples, enforce cooling period timestamps
declare — store promise/commitment triples with deadline tracking
concern — trigger/query reason.c pattern walks
story — query curated content triples

Each verb handler operates on per-user encrypted stores at /data/bahalaka/{user_id}/. store.c already supports different paths — just a new directory per user. Encrypted at rest with AES-256-GCM. WAL journaled.

Atoms arrive through the relay the same way NOUS Desktop's intelligence queries do. Same channel. Same auth. Same encryption. New verbs.

Build Phases

Phase 1 — WASM Foundation

Vendor the SDK. Prove C runs in the browser. Set up the app folder. Build the bridge.

Vendor nous C modules into sdk/ — copy wire.c, crypt.c, aes_gcm.c, sha256.c, pack.c, journal.c, store.c, policy.c + headers
Create /app/ folder structure (shell, pages, CSS, config)
Emscripten Makefile: compile sdk/*.c → app/libbahalaka.wasm
bahalaka.js bridge / relay client: keypair generation, sign/verify, encrypt/decrypt, atom pack/unpack, WebSocket management
bahalaka.conf.js: relay host, port, WS path
journal.c + store.c I/O shimmed to Emscripten IDBFS for local persistence
TOTP auth page: login → auth atom to relay → session token back
Demo: generate Ed25519 keys in C/WASM, pack an atom with wire.c, encrypt it, send to relay via WebSocket, get response — all from the browser

Phase 2 — Server Infra + Registration

Two server-side changes. User registration. Connection pairing. All via atoms through relay.

WebSocket transport layer in relay_server.c (RFC 6455 handshake, frame decode/encode)
Open WebSocket port on relay firewall (3 regions)
Register bahalaka atom verb handlers on prime (chat, status, schedule, finance, agree, declare, concern, story)
Per-user encrypted store paths on prime (/data/bahalaka/{user_id}/)
User registration: keypair → registration atom through relay → prime creates user store
Connection pairing: provider sends signed invite atom through relay → connected person accepts

Phase 3 — Chat

Forward-only messaging. The core use case. Everything over wire protocol through relay.

Chat UI: vanilla HTML/JS, dark theme, mobile-first
Message send: type → WASM packs chat atoms → encrypts → WebSocket to relay → prime stores triples via chat verb handler
Message receive: prime pushes atoms via relay → WASM decrypts + unpacks → JS renders
Forward-only journal enforcement: no delete verb. Edit atoms preserve original.
Read receipts + typing indicators: read and typing atom verbs through relay
Offline queue: WASM encrypts + packs → local journal (IDBFS) → sends on reconnect
Photo + voice: binary atoms with type metadata, same path through relay

Phase 4 — Status + Schedule

Asymmetric visibility. Geo-verified presence. Calendar as atoms through relay.

Status atoms: {user, status, location_type} packed by wire.c, sent through relay, prime stores via status verb handler
Capacitor GPS plugin: auto-match to registered locations, send verification atom
Provider status dashboard: query atom through relay → prime returns all connections' status triples
Schedule: time slot triples, request/approve/decline atoms through relay
Connection isolation enforced on prime — verb handler filters by user, connection A never sees connection B

Phase 5 — Finances

Allowance, savings, sponsorships. Every transaction a signed atom through the relay.

Financial atoms: allowance, disbursement, savings, withdrawal, sponsorship — all through finance verb handler on prime
Allowance engine: cycle configuration, withholding, disbursement — all as signed atoms
Savings + withdrawal tracking: balance computed from journal triples on prime
Sponsorship lifecycle: created → accepted → active → semester proof → renewed/suspended
Grade proof: photo upload as binary atom through relay
Sponsor request flow: submit → in discussion → approved/denied → funded (forward-only state machine)
Financial dashboard: provider + connected person views, queried from prime through relay

Phase 6 — Agreements + Trust

Templates, promises, dual signatures, concern detection. The crown jewel.

Agreement templates stored as triples on prime, queried via agree verb handler
Template selection → 48-hour cooling → dual Ed25519 signature → sealed. All atoms through relay.
Mismatch detection: policy.c (client WASM) checks her_ask vs his_dec before signing atom sent
Promises + commitments: declare atoms with optional deadlines, tracked on prime via declare verb handler
Concern detection: scheduled reason.c walks on prime — promise ratio, request frequency, status anomalies, edit frequency, response asymmetry, schedule conflicts, financial patterns
Provider concern dashboard: concern result atoms pushed through relay to provider client

Phase 7 — Stories + Ship

Field guide. Onboarding. App stores. Friends-first launch.

Stories engine: curated content as triples on prime, queried via story verb handler through relay
Contextual suggestions: when concern pattern detected, prime sends relevant story atom through relay
Onboarding flow: key generation in WASM, identity creation atom through relay, first-week story set
Smart download page at /app/get/ — auto-detects OS, links to store
Capacitor → iOS + Android builds from /app/ folder
Friends-only invite codes: signed invite atoms through relay
Migrate proposal comments from Firestore → nous triples through relay
App Store + Play Store submission

What Dies

Killed

Firebase / Firestore — replaced by nous triples through relay. Comments, auth, everything.
Cloudflare Workers proxy — no longer needed. Client talks to relay via WebSocket.
API keys in client code — gone. Auth is Ed25519 + session tokens via atoms.
Flutter — replaced by Capacitor (thin native shell, web app inside).
Dart — replaced by JS (you already write it).
REST APIs — gone. Everything is NTRP0001 atoms through the relay.
HTTP to catalog-server — gone. One channel. One door. Adding HTTP would mean a second auth path, a second transport, and a second attack surface.

Constraints

All data flows through NTRP0001 wire protocol via nous relay. No exceptions. No REST fallbacks. No HTTP to catalog-server.
SDK vendored, not linked. Copy the minimum C sources into sdk/. No dependency on the full nous tree. Self-contained build.
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 sdk/, outputs .wasm + glue .js.
Capacitor is config, not code — webDir: 'app' + native project scaffolding.
Every feature journal-logged via atoms. No mutable state. Forward-only everywhere.
Server never sees plaintext. Encrypted atoms in, encrypted atoms out.
Relay never decrypts. Stores noise. Forwards blobs.
kastil-systems/nous stays as-is except the 2 changes: WebSocket on relay, verb handlers on prime.

Summary

What This Is

Follows the proven NOUS Desktop pattern — vendor SDK, build relay client, all traffic through relay as atoms
Zero new backend infrastructure — nous relay + prime already running in 3 regions
Zero new database — nous triple store is the database
Zero new auth system — Ed25519 + TOTP + sessions already exist in nous
Zero new wire protocol — NTRP0001 carries everything
One communication path — every feature, every byte, every interaction goes through the relay as atoms. One channel. One protocol. One door.
2 server-side changes: WebSocket transport on relay + bahalaka atom verb handlers on prime
Client: vendored C SDK → WASM + bahalaka.js relay client + vanilla HTML/JS + Capacitor
Trust engine: reason.c — already built for knowledge queries, now pointed at relationship data