bahalaka.com

"Bahala ka" — "Up to you."

A sovereign relationship platform — built on Nous, rolled from pure C

Intent

The Problem

When an older foreigner and a young Filipina engage in a love affair, there are real challenges: trust gaps, communication transparency, financial accountability, schedule coordination across time zones, education sponsorship tracking, and the question of sincerity on both sides. Existing platforms offer a chat box and nothing else. No structure. No accountability. No sovereignty.

The Solution

Bahalaka is a mobile-first relationship platform purpose-built for these connections. Forward-only chat enforces honesty. The Nous security stack makes it sovereign. The financial system — allowances, savings, sponsorships — brings structure and transparency to support. The schedule system manages multi-relationship availability. All of it built on your existing pure C libraries, rolled from scratch. No frameworks. No dependencies. Your code.

What We Already Have — Nous C Inventory

150+ C source files. 5,000+ KB of production code. Zero external dependencies.

This is not a greenfield build. The engine exists. Bahalaka is a new vehicle on an existing powertrain.

Security Purpose — READY

crypt.c/h

Ed25519 signatures. Full scalar multiplication, point operations, batch verification. 80KB pure C.

C:\kastil\nous\security\skill\crypt\

auth.c/h

Identity verification, user authentication flows. 4,500 LOC.

C:\kastil\nous\security\skill\auth\

vault.c/h

Credential storage and retrieval. 3,800 LOC.

C:\kastil\nous\security\skill\vault\

policy.c/h

Policy enforcement engine. 4,000 LOC.

C:\kastil\nous\security\skill\policy\

Comms Purpose — READY

relay_server.c

Authenticated relay — Ed25519 identity + AES-256-GCM transport. Session management via triple store. 73KB.

C:\kastil\nous\comms\skill\relay\

mesh.c/h

Distance-vector routing, beacon/listen discovery, multi-hop forwarding. 28KB. 46 tests passing.

C:\kastil\nous\comms\skill\mesh\

wire.c/h

Binary serialization protocol. Message framing and encoding.

C:\kastil\nous\comms\skill\wire\

http.c/h

HTTP/1.1 server. 10KB.

C:\kastil\nous\comms\skill\http\

Memory Purpose — READY

store.c/h

Triple store (subject/predicate/object). 26KB, 5,400 LOC. The data engine.

C:\kastil\nous\memory\skill\store\

journal.c/h

Write-ahead log. Append-only by design. Forward-only IS the journal.

C:\kastil\nous\memory\skill\journal\

hash.c/h + index.c/h

Hash tables + triple indexing. Subject/predicate/object chains.

C:\kastil\nous\memory\skill\

mmap.c/h + pack.c/h

Memory-mapped I/O + serialization (variable-length ints, delta encoding).

C:\kastil\nous\memory\skill\

Target Runtimes — READY

aes_gcm.c/h

AES-256-GCM authenticated encryption. 17KB. Software implementation.

C:\kastil\target-runtimes\

aes_gcm_hw.c/h

Hardware-accelerated AES via AES-NI instructions. 14KB.

C:\kastil\target-runtimes\

sha256.c/h + sha256_hw.c/h

SHA-256 — both software and hardware-accelerated.

C:\kastil\target-runtimes\

audit_engine.c/h

Audit logging engine. 7,200 LOC. Forward-only audit trail.

C:\kastil\target-runtimes\

Metal Auth — READY

totp.c + qr.c

Time-based OTP + QR provisioning. 2,900 + 20KB.

C:\metal\auth\

gate.c + auth.c + crypt.c

Gate engine, auth gateway, crypto. Complete auth microservice.

C:\metal\auth\

What Needs Building — NEW

Noise Protocol (XX pattern)

Transport handshake. Ed25519 + AES-GCM already exist — Noise is the choreography layer on top.

NEW — compose from existing crypt + aes_gcm

Flutter/Dart FFI Bindings

Dart FFI bridge to compiled C libraries. Thin layer — calls straight into the C.

NEW — FFI wrappers for mobile

Financial Ledger Engine

Allowance, savings, sponsorship tracking. Built on triple store + journal.

NEW — compose from store + journal + policy

Schedule Engine

Multi-connection availability, time requests, reservation management.

NEW — compose from store + policy

Sovereign Security — Powered by Pantheon

SOVEREIGN

We don't say "encrypted." We say sovereign.
Your messages aren't just locked — they're invisible, untamperable, and yours forever.

What "Beyond Encrypted" Means — Your Code, Your Security

Security Layer	Nous Asset	What It Does
Transport	Noise XX pattern NEW (composed from crypt.c + aes_gcm.c)	Identity hiding, forward secrecy, zero-RTT. Both parties verify each other. Observer can't see who's talking.
Identity	crypt.c (Ed25519) + auth.c EXISTS	Sovereign key pairs. You own your identity. No platform dependency. Portable credentials.
Encryption	aes_gcm.c (256-GCM) + vault.c EXISTS	Per-conversation keys. Client-side only. Server stores noise — encrypted blobs with no keys.
Integrity	sha256.c + journal.c + hash.c EXISTS	Every message hash-chained. Append-only journal. Change one bit, chain breaks. Edit history is sealed.
Audit	audit_engine.c EXISTS	Forward-only audit trail. Every action logged, cryptographically linked, tamper-evident.
Policy	policy.c EXISTS	Enforces rules: no delete, no unsend, edit-only-for-typos. Architecture, not policy.
Traffic Analysis	wire.c + relay_server.c EXISTS	Binary wire format. Relay handles routing. Observer sees uniform encrypted frames.
Auth	totp.c + gate.c + qr.c EXISTS	TOTP 2FA, QR provisioning, gate-based access control.

Score: 6 of 8 security layers already exist as production C code. The Noise handshake choreography and Flutter FFI bindings are the only new work. The crypto primitives are all yours.

Scope — All Features

1. Chat — Forward Only

Rules

No delete. Ever. Messages are append-only entries in the journal (journal.c). Hash-chained via SHA-256.
No unsend. Once delivered, it exists for both parties permanently.
Edit for typos only. Edit = new journal entry referencing original hash. Original preserved. All edit history one tap away — timestamped, signed (Ed25519), tamper-evident.
Read receipts: always on. No option to disable. Transparency is the product.
Typing indicators: always on.
Message types: Text, photo, voice memo, location pin, schedule request, sponsor request.

Built On

journal.c (append-only log) + hash.c (hash chains) + crypt.c (Ed25519 signatures) + aes_gcm.c (per-message encryption) + wire.c (binary framing) + relay_server.c (authenticated relay)

2. Status — Asymmetric by Design

Core insight: When you support multiple girls and they can see you're online but not chatting to them — they assume the worst. "He's online but not talking to me? He's with someone else." This creates jealousy, drama, and paranoia. The solution: providers do not show online status. The girls operate on a "send and pray" model — send your message, trust it will be read, and live your life.

Provider (Support Person) — No Status Visible

What Girls See	Why
No online/offline indicator	Eliminates "he's online but ignoring me" anxiety
No "last seen"	Prevents obsessive checking and comparison between girls
No typing indicator (to them)	Provider can compose without pressure
Messages just arrive	Send and pray. Trust the system. Trust the man.
DO NOT DISTURB	Provider-only feature. Manual toggle. Silences all notifications. Girls see nothing different — their messages still send, they just won't get a response until DND is off.

The provider sees everything on their end — read receipts, typing indicators, all connection statuses. The asymmetry is intentional. The provider manages multiple relationships; the girls don't need to know the logistics of that.

Connected Person (Girl) — Full Status, Fixed Set

Status	How
At Home	Auto-set via GPS match to registered home (within radius)
At Work	Auto-set via GPS match to registered work location
Favorite 1-3	Up to 3 named places (e.g., "Starbucks Ayala"). Auto-set by geo.
At [Friend's Name]	Friend's registered location. Friend must be on bahalaka. Mutual geo-verification.

Rules

No DND for girls. Do Not Disturb is a provider-only feature. The sponsored person is always reachable. If you're being supported, you're available.
No custom text. No invisible mode. No stealth — for girls.
Provider is always "invisible" — not stealth, just absent from the status system entirely.
Status transitions are logged in the journal — forward-only.
Geo-verified locations show a trust badge.
Girls see each other's existence: never. Complete isolation between connections.

The Philosophy

The entire point of the system is trust and verify. When there is two-way respect and honesty, the app promotes this winning philosophy — it rewards good behavior with transparency and structure. When there is ill intent on either side, the system helps identify it and pushes concerns up to the users. The asymmetry serves this: the provider needs operational space to manage multiple relationships without creating unnecessary drama. The girls need to trust that the system works, that messages arrive, and that the financial commitments are being met. The schedule and financial features provide the proof. Status is noise.

Built On

store.c (location registry) + policy.c (asymmetric visibility rules) + journal.c (status transition log)

3. Schedule — Transparent Availability

Roles

Role	Description
Provider	The supporter. Manages schedule across multiple connections. Initiates connection requests.
Connected	Accepts connection. Sees the provider's schedule as it pertains to them. Can request time.

Visibility Matrix

Time State	Provider View	Connected Person View
Available	Open slot	"Available" — can request this time
Reserved	Reserved for specific person (shows who)	"Reserved for you" (or just "Busy" if reserved for someone else)
Busy	Full view — who, what	"Busy" — no details

Flow

Provider sends connection request
Girl accepts → sees provider's schedule (her view only)
Provider marks blocks: Available / Reserved / Busy
Girl requests time during Available blocks
Provider approves or declines → Approved becomes Reserved
All changes journal-logged. Forward-only.
Girl A never sees Girl B's name, details, or existence.

Built On

store.c (schedule triples: {person, available_at, timeslot}) + policy.c (visibility rules per role) + journal.c (schedule change log)

4. Financial — Allowance, Savings, Sponsorships

The financial system is a forward-only ledger. Every transaction, every approval, every denial is a journal entry — cryptographically chained, signed, and permanent. This is not an accounting app. This is a trust engine with money attached.

4a. Allowance

Structure

Field	Description
Cycle	Weekly, Bi-weekly, or Monthly — set per connection
Amount	Total allowance for the cycle
Savings Withholding	Amount automatically withheld from each allowance for savings
Net Allowance	Amount - Withholding = what the connected person receives
Pay Date	When in the cycle the allowance is due

Rules

Provider sets the cycle, amount, and savings withholding per connection
Connected person sees: cycle, net amount, next pay date, savings balance
Every disbursement is a signed journal entry — date, amount, savings withheld
Allowance changes are forward-only — old rate is preserved in history, new rate takes effect next cycle

4b. Savings

Structure

Savings are held by the provider — not in a bank account controlled by the connected person
Running balance visible to both parties
Every deposit (from withholding) is a journal entry
Withdrawals require provider approval — logged as journal entries with reason
Savings balance is a computed sum of all journal entries — no mutable balance field. The ledger IS the truth.

Display

Connected person sees: total saved, withholding rate, deposit history, pending withdrawal requests. Provider sees the same plus approval controls.

4c. Sponsorships

Example: Tuition at STI University

Field	Description
Institution	STI University (or any school)
Cost	Amount per semester
Cycle	Per semester — start/end dates
Status	Active, Suspended, Completed, Terminated

Rules & Requirements

Requirement	Verification
No boyfriend/girlfriend	Acknowledged agreement — signed journal entry at sponsorship start. Violation = suspension/termination (provider's discretion, logged).
Grade requirements	Grade proof required per semester. Photo/scan of grades uploaded as message attachment. Forward-only — can't delete proof or lack thereof.
Attendance requirements	Provider must be granted access to school website/portal. Attendance monitored. Proof screenshots uploaded as messages.
Part-time job required	Must maintain part-time employment to cover personal expenses. Proof of employment required (pay stubs, employer confirmation). Sponsorship covers tuition — personal expenses are the student's responsibility.

Sponsorship Lifecycle

Created → Requirements Accepted → Active → Semester End (proof due) → Renewed / Suspended / Completed

Every state transition is a journal entry. Forward-only. The entire sponsorship history is an immutable record.

4d. Sponsor Requests

The Flow

Connected person submits a request for additional support beyond the regular allowance. Examples: family outing, KKB (split cost) gathering, emergency, special occasion.

Request Structure

Field	Description
What	Description of the need (e.g., "Family outing to Enchanted Kingdom")
Amount	How much is being requested
When	Date of the event/need
Type	KKB (split cost), Full Sponsor, Partial, Emergency

Response States — Forward Only, Non-Editable

Submitted → Denied

Submitted → In Discussion → Denied / Approved

Submitted → Approved → Funded

Rules

Forward-only. Once submitted, the request cannot be edited or deleted.
Non-editable responses. Once a response is given (Denied, In Discussion, Approved, Funded), it cannot be changed — only a new response can be appended.
State can only move forward: Submitted → In Discussion → Approved → Funded. Or Submitted → Denied. No backwards movement.
"In Discussion" means the provider and connected person are negotiating in chat. The request stays visible as a card above the chat.
"Funded" means the money has been sent. Provider marks it funded. Journal entry created with amount + method.
Every state change is a signed journal entry with timestamp. The full request lifecycle is an immutable audit trail.

4e. Financial Dashboard

Provider View (across all connections)

Total monthly outflow (all allowances + active sponsorships)
Savings held (per connection and total)
Active sponsorships (count, total cost per semester)
Pending sponsor requests
Payment history timeline

Connected Person View (their relationship only)

Next allowance: amount, date
Savings balance
Active sponsorships: status, requirements, next proof due
Pending requests: status
Payment history

Built On

store.c (financial triples) + journal.c (ledger entries) + policy.c (approval rules, requirement enforcement) + audit_engine.c (immutable audit trail)

5. The Agreement — The Most Critical Feature

Reality check: All girls in the selling phase will pretty much agree to anything the foreigner wants. Let's be respectful and aware of their situation and assume this is always the case. She needs the support. She'll say yes to whatever terms get the money flowing. That "yes" means nothing until the dynamic settles and real behavior emerges. For this reason, we must have a formal agreement — pre-written, clearly defined, forward-only — that both parties sign with full understanding of what they're agreeing to.

Why Pre-Written Agreements

Custom agreements invite ambiguity, loopholes, and "I didn't understand what you meant." Pre-written agreements are clear, tested, and leave no room for misinterpretation. The provider selects the template that matches the reality of the arrangement. The girl reads it, understands it, and accepts or declines. No negotiation on the template — the terms are the terms. The only negotiation is which template fits.

Her Side — What She Wants from Him

These are the girl's expectations for the man's behavior. What does she want from him? How does she want him to conduct himself? Her voice, her ask.

#	Template	What She's Asking For
1	Stick to One	She wants him fully monogamous. Just her. No other girls. No bar fun. No side connections. All in, one woman.
2	Fun in the Bar with Limits	She's OK with him going to bars and having fun with other girls — within defined limits. The limits are explicit in the agreement: what's allowed, what crosses the line.
3	All the Fun You Want — I Don't Want to Know	She gives him full freedom. Do whatever, see whoever. She doesn't want to hear about it. What he does outside their time is his business.
4	All the Fun You Want — I Want to Know Everything	Full freedom, full transparency. He can do what he wants, but she wants to know all of it. Every detail. Forward-only chat makes this real — the honesty is on the record.
5	All the Fun You Want — I Want to Join	She wants in. Whatever he's doing, she wants to be part of it. Shared adventures. Together.
6	Make Me the Center	She wants to be the center of the fun. She drives it. He supports and participates on her terms. Her show.
7	You're the Man — Bahala Ka	Fully submissive. She wants him to control every aspect of her life. She wants to be the center of all his attention and adventures — but he produces and directs, always. His vision, his plan, his call. She's the star, he's the director. Bahala ka.

His Side — Two Declarations

Declaration 1: Who He Is (His Lifestyle)

The man declares honestly who he is and how he lives. No hiding. No surprises later. She knows what she's signing up for.

#	Template	What He's Declaring
I	One Woman	Fully monogamous. She's the only one. Period.
II	I See Others	He dates or sees other women. Honest about it.
III	I Support Others	He financially supports other women too. She's not the only one receiving support.
IV	I Short Time	He engages in casual paid encounters. Stated plainly.
V	I Do It All	All of the above. He lives the full expat lifestyle. No filters.
VI	I Travel With One or More	He takes women on trips — one or several. Part of how he lives.
VII	Full Open — All Out	Everything. He sees others, supports others, short times, travels with them, all of it. Complete transparency about the full picture.

Declaration 2: Structure for Her (Her Daily Life)

The structure the provider sets for the girl's daily routine and autonomy.

#	Template	What It Means
A	Full Structure	Home → School → Home → Job → Home. Strict routine. GPS-verified via status system. Deviations are visible and logged. Maximum accountability.
B	Guided Autonomy	Some freedom, but activities outside the routine require approval. Want to go out with friends? Request it. Provider approves or declines. Logged in the journal.
C	Full Autonomy	Live your life. The provider supports financially but does not control daily movement. Status system still runs (geo-verified), but no approval required for activities.

"Do as I do, not as I say" — This is allowed and promoted. The provider and the girl are in different stations. He can help, support, and provide — and he has needs that no single female can provide for. The agreement acknowledges this asymmetry openly and honestly. That's the whole point: state it up front. No surprises. No lies discovered later. She sees his declaration before she signs. She knows exactly who he is.

Zero promotion of bar work. Bahalaka will never propose, support, or normalize the idea of anyone working in a bar and selling anything. The platform exists to help people build better lives — education, employment, stability. The bar life is what many of these girls are trying to escape. We don't push them back in.

Agreement Combinations

Each connection has three parts: Her Ask (1-7) + His Declaration (I-VII) + His Structure (A-C). Examples:

Combo	Translation
1 + I + A	She wants him monogamous. He declares one woman. Full structure for her. The tightest arrangement — both all in, maximum accountability.
3 + VII + C	She doesn't want to know. He's full open, all out. Full autonomy for her. The loosest — financial support, zero strings, total honesty about the asymmetry.
4 + III + B	She wants to know everything. He declares he supports others. Guided autonomy for her. Trust but verify — she knows the full picture, he knows her schedule.
5 + V + C	She wants to join the fun. He does it all. Full autonomy for her. Shared adventures, open lifestyle, no daily control.
7 + VII + A	You're the Man + Full open + Full structure. The ultimate bahala ka — she gives him total control, he's all out, she's the star of his production. He directs everything.
1 + II + A	She wants him monogamous. He declares he sees others. Full structure for her. This is a mismatch — the system flags it. She's asking for one thing, he's declaring another. Both parties see the conflict before signing.

Mismatch detection: When Her Ask and His Declaration conflict (e.g., she wants "Stick to One" but he declares "I See Others"), the system highlights the tension before signing. It doesn't prevent the agreement — both adults can sign whatever they want — but it ensures nobody can claim they didn't see the contradiction.

Agreement Lifecycle

Provider Selects Templates → Girl Reviews (cooling period) → Girl Accepts / Declines → Active

Rules

Forward-only. Once signed, the agreement is permanent in the journal. It cannot be deleted or edited.
Can be superseded. Either party can propose a new agreement. If both sign the new one, it supersedes the old one. The old agreement remains in the record — the history of what was agreed to and when.
Cooling period. After the provider selects templates, the girl has a mandatory waiting period (48 hours minimum) before she can accept. This prevents pressure signing. She needs time to actually read and understand.
Both signatures required. Dual Ed25519 signatures. Both parties sign. The agreement is cryptographically bound to both identities.
Visible at all times. The active agreement is always accessible in the connection profile. One tap. No hiding what was agreed to.
Agreement history. Every past agreement, every supersession — all visible. The evolution of the relationship's terms is a permanent record.
No custom agreements. Templates only. Custom language invites ambiguity. The templates are clear, tested, and unambiguous.
Agreement informs concern detection. If the agreement says "Stick to One" (1) and the status system shows frequent unexplained absences or DND-like behavior, the concern engine notes the pattern.

Built On

journal.c (immutable agreement records) + crypt.c (dual Ed25519 signatures) + store.c (agreement triples: {connection, bound_by, agreement_1A}) + policy.c (cooling period enforcement, template validation, supersession rules)

6. Intentions, Promises & Commitments

Words are cheap. The journal makes them permanent. Either party can state intentions, dreams, ideas, promises, and commitments. Once stated, they live in the record forever. This is the accountability engine — it separates the sincere from the players.

Declaration Types

Type	Description	Example
Intention	What you plan to do. Lightweight. A signal of direction.	"I intend to visit in December"
Dream	A shared aspiration. No timeline, no commitment — just a vision.	"I dream of us having a small business together"
Idea	A suggestion for discussion. Open-ended.	"What if we enrolled your sister too?"
Promise	A binding statement with a timeline. The system tracks it.	"I promise to send the tuition by March 15"
Commitment	A formal agreement between both parties. Requires mutual acceptance.	"We commit to exclusive dating effective today"

Rules

Forward-only. Once declared, it cannot be deleted or edited. Ever.
Either party can declare. Provider or connected person. Both have a voice.
Promises have deadlines. The system tracks them. When a deadline passes, the promise shows as Kept or Unkept. No manual override needed — the journal speaks.
Commitments require mutual acceptance. One party proposes, the other accepts or declines. Both signatures on the journal entry. Forward-only — acceptance can't be revoked, only a new declaration can supersede.
Visible in profile. Active promises and commitments are displayed on each party's profile within the connection. The history is always one tap away.
Pattern visibility. Over time, the journal reveals patterns: Does this person keep promises? Do deadlines slip? Do commitments get honored? The data tells the story.

State Flow — Promises

Declared → Active (deadline pending) → Kept / Unkept / Extended

State Flow — Commitments

Proposed → Accepted / Declined → Active → Superseded (by new commitment only)

Built On

journal.c (immutable declarations) + store.c (relationship triples: {person, promised, thing}) + policy.c (deadline tracking, mutual acceptance rules) + audit_engine.c (pattern analysis over time)

7. Concern Detection — Trust & Verify

The Problem

Some girls are masters of the game. Double and triple talk. Misdirection. Emotional manipulation. Anyone who has lived with a Makati bar girl long enough will see the extent and level of gamesmanship going on behind the scenes. They are masters of the art of seduction — they will make your head spin, heart explode, and wallet drain simultaneously and without effort, all while seeing three other punters, building out houses and buying motorbikes for their local Filipino macho dancer, their province boyfriend, and their secret lesbian kabit.

When you know, you know. But many don't know — and they have no business getting involved in such monkey business without guidance.

The system can help. Not by judging — by surfacing data.

What the System Watches (Pattern Signals)

Signal	What It Might Mean	How
Promise/commitment ratio	Many promises, few kept = pattern of unreliability	Journal analysis — promises declared vs. kept over time
Sponsor request frequency	Escalating requests = possible financial exploitation	Request frequency + amount trending over time
Edit frequency on messages	Heavy editing = possible story management	Edit count per message, especially on sensitive topics
Status vs. schedule conflicts	"At Home" during scheduled work = inconsistency	Geo-status vs. declared schedule mismatches
Sponsorship compliance gaps	Missing grade proofs, attendance drops = priorities shifted	Proof submission patterns, deadlines missed
Agreement violations	Behavior inconsistent with signed agreement template	Agreement terms vs. actual status/schedule/financial patterns
Response time asymmetry	Instant responses when requesting money, slow otherwise	Response time correlation with message type

How Concerns Surface

No accusations. No labels. No judgments. The system presents data patterns, not verdicts.
Concerns appear as gentle flags in the provider's dashboard — "Pattern noticed: 4 of 6 promises from [name] have passed their deadline"
The provider decides what to do with the information. The system does not intervene.
Connected persons do NOT see concern flags about themselves. This is a provider-side awareness tool.
Concerns are generated from journal data — the same forward-only, tamper-evident record both parties contributed to.

Philosophy

When there is two-way respect and honesty, the app promotes the winning philosophy — clean records, kept promises, consistent behavior. The data validates the trust. When there is ill intent on either side, the system helps identify it. Not by spying. Not by accusing. By making the patterns in the permanent record visible to those who need to see them.

Built On

journal.c (the source of truth) + store.c (pattern queries over triples) + policy.c (threshold rules for flagging) + audit_engine.c (trend analysis)

8. Stories & Field Guide — "When You Know, You Know"

The Purpose

This is essential. Many foreigners who want to help don't have the experience — and for all intents and purposes have no business getting involved without education. The Stories & Field Guide is a curated, growing collection of real experiences, hard-won wisdom, and cautionary tales from people who've been in the trenches.

Content Types

Type	Description
Stories	Real narratives from real people. First-person accounts. Names changed, lessons preserved. Joey will contribute his own stories and curate others.
Quotes	One-liners and wisdom from experienced providers. Tagged with attribution. Real words only — no AI-generated content.
Patterns	Common manipulation tactics explained without judgment. "Here's what it looks like. Here's what's actually happening. Here's what you can do."
Red Flags	Specific warning signs with real examples. Not to create paranoia — to create awareness.
Success Stories	When it works. When trust is real. When the investment in a person's education changes a life. These stories matter too.
Cultural Context	Filipino culture, family dynamics, utang na loob (debt of gratitude), the province vs. city divide, bar culture vs. student culture. Understanding the context changes everything.

Rules

Real stories only. No AI-generated content. No fiction. Every story comes from a real person's experience.
Forward-only. Stories can be added, never deleted. The archive grows.
Tagged and searchable. By topic, by pattern, by outcome.
Contributed by community. Providers can submit stories through the app. Curated before publishing.
Never negative about people. About patterns, yes. About individuals, never. Zero trash talk. The goal is education, not shame.
Available to all users. Both providers and connected persons can read. Transparency goes both ways.

In-App Placement

Dedicated "Field Guide" tab — browse, search, read
Contextual suggestions — when a pattern is detected, relevant stories surface in the provider's concern dashboard
Onboarding — new users see curated starter stories during first week

Built On

store.c (story triples: {story, tagged_with, pattern}) + journal.c (forward-only archive) + content moderation via policy.c

Architecture

The Stack — Roll Your Own

Layer	Technology	Source
Mobile App	Flutter (Dart) — single codebase iOS + Android	NEW (Dart UI, FFI to C)
C Core Library	Compiled shared library (.so/.dylib/.dll)	EXISTS — Nous C stack
Dart FFI Bridge	dart:ffi bindings to C functions	NEW — thin wrappers
Crypto — Signatures	Ed25519 (crypt.c)	EXISTS — 80KB
Crypto — Encryption	AES-256-GCM (aes_gcm.c)	EXISTS — 17KB
Crypto — Hashing	SHA-256 (sha256.c + sha256_hw.c)	EXISTS
Crypto — Transport	Noise Protocol XX pattern	NEW — composed from existing primitives
Storage — Local	Triple store (store.c) + journal (journal.c)	EXISTS — 26KB + journal
Storage — Server	Relay server (relay_server.c) — stores encrypted blobs only	EXISTS — 73KB
Wire Protocol	Binary framing (wire.c)	EXISTS
Auth	TOTP + QR + Gate (metal/auth)	EXISTS
Audit	audit_engine.c	EXISTS — 7,200 LOC
Policy	policy.c	EXISTS — 4,000 LOC
Mesh (future)	mesh.c — P2P when both parties nearby	EXISTS — 28KB, 46 tests

Build ratio: 12 existing C modules, 3 new layers (Noise, FFI, Flutter UI).

The C core compiles as a shared library. Flutter calls it via Dart FFI. The crypto, storage, audit, policy, wire protocol, and relay are all your code. Zero dependencies. Pure C. The purist's way.

Data Flow

Sender Device                        Relay Server                      Receiver Device
┌──────────────────┐               ┌─────────────────┐              ┌──────────────────┐
│ Flutter UI (Dart) │               │ relay_server.c   │              │ Flutter UI (Dart) │
│       ↓ FFI       │               │ (73KB, existing) │              │       ↑ FFI       │
│ ┌──────────────┐  │               │                  │              │ ┌──────────────┐  │
│ │ journal.c    │  │               │  Ed25519 node ID │              │ │ journal.c    │  │
│ │ (append msg) │  │               │  AES-GCM session │              │ │ (append msg) │  │
│ │     ↓        │  │  Noise XX     │  Triple store    │  Noise XX    │ │     ↑        │  │
│ │ crypt.c      │  │──────────────→│  sessions        │─────────────→│ │ crypt.c      │  │
│ │ (Ed25519 sig)│  │ (identity     │                  │ (identity    │ │ (verify sig) │  │
│ │     ↓        │  │  hidden)      │  Stores ONLY     │  hidden)     │ │     ↑        │  │
│ │ aes_gcm.c    │  │               │  encrypted blobs │              │ │ aes_gcm.c    │  │
│ │ (encrypt)    │  │               │  No keys.        │              │ │ (decrypt)    │  │
│ │     ↓        │  │               │  No plaintext.   │              │ │     ↑        │  │
│ │ wire.c       │  │               │  No metadata.    │              │ │ wire.c       │  │
│ │ (frame)      │  │               │                  │              │ │ (deframe)    │  │
│ └──────────────┘  │               └─────────────────┘              │ └──────────────┘  │
└──────────────────┘                                                 └──────────────────┘

Server stores noise. That's it. That's the whole point.

Phases

Phase 1 — C Core Library (Weeks 1-3)

Compose Nous C modules into a single shared library (libbahalaka.so/.dylib)
Implement Noise Protocol XX handshake on top of existing crypt.c + aes_gcm.c
Build message model: journal entry + hash chain + Ed25519 signature + AES-GCM envelope
Build financial ledger model on triple store + journal
Build schedule model on triple store + policy
Build declaration model (intentions/promises/commitments) on journal + store
Cross-compile for iOS (arm64) and Android (arm64-v8a, armeabi-v7a)
Test suite — all existing tests pass in shared lib form

Phase 2 — Flutter App + FFI (Weeks 4-7)

Flutter project scaffold (iOS + Android targets)
Dart FFI bindings to libbahalaka — thin wrappers for each C module
Chat UI — message list, compose, edit-with-history, read receipts
Asymmetric status — provider invisible, girl status with geo-detection, DND
Schedule UI — calendar grid, time requests, approval flow
Connection management — invite, accept, link
TOTP auth flow with QR provisioning

Phase 3 — Financial System (Weeks 8-10)

Allowance configuration UI — cycle, amount, savings withholding
Savings dashboard — balance, deposit history, withdrawal requests
Sponsorship management — institution, cost, cycle, requirements, proof tracking
Sponsor request flow — submit, discuss, approve, fund (forward-only states)
Financial dashboard — provider aggregate view, per-connection detail view
All financial state backed by journal entries — computed balances, no mutable fields

Phase 4 — Agreements & Trust (Weeks 11-14)

Agreement system — pre-written templates (Her 1-6, His A-C), combination selection UI
Agreement lifecycle — cooling period (48hr), dual Ed25519 signatures, supersession chain
Agreement visibility — always accessible in connection profile, full history
Intentions, Promises & Commitments — declaration UI, deadline tracking, mutual acceptance
Promise scorecard — kept vs. unkept ratio visible on profile
Concern detection engine — pattern analysis over journal data, agreement-aware flagging
Provider dashboard flags — gentle pattern alerts (request frequency, promise ratio, response asymmetry, agreement violations)
Stories & Field Guide — content management, tagging, search
Contextual story suggestions — relevant stories surface alongside detected patterns
Onboarding flow — starter stories for new providers

Phase 5 — Polish & Ship (Weeks 15-17)

Push notifications (FCM + APNs)
Edit history UI polish — timeline view, one-tap access
bahalaka.com landing page
App Store + Google Play submission
Pantheon security branding + marketing
Multi-language: English, Filipino, Bisaya
Joey's initial story contributions + quote collection

Phase 6 — Growth (Post-Launch)

Mesh networking (mesh.c) — P2P when nearby, no server needed
Payment/remittance integration (GCash, PayMaya, Western Union)
Video calling (Noise-encrypted)
Advanced trust scoring — verified status + schedule adherence + sponsorship compliance + promise ratio
Community story submissions + curation pipeline
Group features — family connections, family outing coordination
Web app via Flutter Web

Constraints

Pure C for all crypto and core logic. No external libraries. Dart FFI to compiled C. The purist's way.
Flutter for UI only. Business logic lives in C. Flutter is the skin.
Forward-only everything. Chat, status, schedule, financials — all append-only journal entries. No delete. No mutation. The journal IS the truth.
Provider has NO visible status. No online, no last seen, no typing indicator to girls. Send and pray. The schedule and financials are the proof — not presence.
Girl status: fixed set, geo-verified. No custom text. No invisible mode. No fiction.
Savings held by provider. Not a bank. Not an escrow. Provider holds it, ledger proves it.
Sponsor requests are non-editable. Submit → state moves forward only. Denied is denied. Funded is funded.
Server stores noise. Encrypted blobs. No keys. No plaintext. No metadata. Relay_server.c as-is.
Promises are permanent. Declared with deadlines, tracked by the system. Kept or unkept — the journal decides.
Concern detection: data, not judgment. The system surfaces patterns. The provider decides what they mean. No accusations. No labels.
Stories are real. No AI-generated content in the Field Guide. Real people, real experiences, real lessons. Zero trash talk about individuals.
Pantheon-powered security. Sovereign security brand aligned with ai-pantheon.ai.
No existing chat repo found in ai-pantheon or a-d-d — building fresh on Nous primitives.

C Library Dependency Map

bahalaka (app)
├── SECURITY
│   ├── crypt.c/h ............. Ed25519 signatures (80KB)     ✅ EXISTS
│   ├── auth.c/h .............. Authentication (4,500 LOC)    ✅ EXISTS
│   ├── vault.c/h ............. Credential storage (3,800)    ✅ EXISTS
│   ├── policy.c/h ............ Rule enforcement (4,000)      ✅ EXISTS
│   └── noise.c/h ............. Noise XX handshake            🟡 NEW (compose)
│
├── CRYPTO
│   ├── aes_gcm.c/h .......... AES-256-GCM (17KB)            ✅ EXISTS
│   ├── aes_gcm_hw.c/h ....... HW-accelerated AES (14KB)     ✅ EXISTS
│   ├── sha256.c/h ........... SHA-256 software              ✅ EXISTS
│   └── sha256_hw.c/h ........ SHA-256 hardware              ✅ EXISTS
│
├── STORAGE
│   ├── store.c/h ............. Triple store (26KB)           ✅ EXISTS
│   ├── journal.c/h ........... Write-ahead log               ✅ EXISTS
│   ├── hash.c/h .............. Hash tables                   ✅ EXISTS
│   ├── index.c/h ............. Triple indexing                ✅ EXISTS
│   ├── mmap.c/h .............. Memory-mapped I/O             ✅ EXISTS
│   └── pack.c/h .............. Serialization                 ✅ EXISTS
│
├── COMMS
│   ├── relay_server.c ........ Authenticated relay (73KB)    ✅ EXISTS
│   ├── wire.c/h .............. Binary framing                ✅ EXISTS
│   ├── mesh.c/h .............. P2P mesh (28KB, 46 tests)     ✅ EXISTS (Phase 5)
│   └── http.c/h .............. HTTP server (10KB)            ✅ EXISTS
│
├── AUDIT
│   ├── audit_engine.c/h ...... Audit trail (7,200 LOC)       ✅ EXISTS
│   └── gate_engine.c/h ....... Access control (8,800 LOC)    ✅ EXISTS
│
├── AUTH
│   ├── totp.c ................ Time-based OTP (2,900 LOC)    ✅ EXISTS
│   └── qr.c .................. QR generation (20KB)          ✅ EXISTS
│
└── APP
    ├── Flutter / Dart UI ..... Mobile UI layer               🟡 NEW
    ├── dart:ffi bindings ..... FFI bridge                    🟡 NEW
    ├── ledger.c/h ............ Financial engine               🟡 NEW (compose)
    ├── schedule.c/h .......... Schedule engine                🟡 NEW (compose)
    ├── declare.c/h ........... Intentions/promises engine     🟡 NEW (compose)
    ├── agreement.c/h ......... Agreement templates + signing  🟡 NEW (compose)
    └── concern.c/h ........... Pattern detection engine       🟡 NEW (compose)

SCORE: 22 existing modules | 8 new (6 composed from existing, 2 fresh)