Local Connect — offline-first social radar

Meet people actually around you. Phones discover each other via BLE + Wi-Fi Direct — no servers, no accounts. Optional GPT-5.6 writes your profile, and breaks the ice. Data stays on-device.

Comment

Inspiration

Every app that helps you meet the person standing next to you routes that moment through a datacenter. We wanted the opposite: phones that discover each other directly, exchange profiles directly, and chat directly — no account, no server, no signal required. AI joins only when needed, where it genuinely helps: presenting yourself and breaking the ice.

What it does

Local Connect is an offline-first Android proximity app. Your phone advertises presence over BLE while scanning for others; nearby people appear on a radar with lightweight profile previews. When you "say hi" and the other side explicitly accepts, the phones negotiate an on-demand Wi-Fi Direct group and open a TCP session carrying our V4 protocol: rich profiles (photos, videos, voice prompts), chat with images and voice notes (with real recorded-amplitude waveforms), and resumable chunked file transfer with SHA-256 verification and end-to-end delivery receipts. The connection never touches a cloud.

The new AI Profile Studio is the first of our GPT-5.6 features: you type rough notes ("29, engineer, rock climbing, new in town…"), pick a tone, and GPT-5.6 polish your bio, interests, and profile prompts — returned as per-field suggestions you edit and accept. It is strictly optional, consent-gated, and quota-metered; the app works fully offline without it.

How we built it

The P2P core is Kotlin/Android: a foreground presence service, a single-lease BLE scan coordinator, ECDH + AES-GCM credential exchange over BLE, and a length-prefixed frame protocol where every frame type has explicit size bounds and JSON schema validation on both ends.

For Build Week we built the AI layer the way we'd want to be reviewed: the APK contains no API key. Android talks to an app-owned gateway which calls the OpenAI Responses API with Structured Outputs ; during development the gateway runs on a Mac behind adb reverse, loopback-only. Both the gateway and the Android client validate the exact response schema — fields, types, prompt keys, counts, byte caps — before any suggestion reaches UI state. A one-time consent sheet, a revocation switch in Settings, a daily on-device quota ledger, and a daily-rotating random rate-limit ID (never the P2P identity) round out the privacy boundary.

Codex built most of this with us: the gateway and its tests, the Android AI package (endpoint policy, usage ledger, JSON validator, Profile Studio UI), plus this week's connection-latency cuts and delivery-receipt work — with dated commits and session logs as evidence.

Challenges

  • Wi-Fi Direct's owner/client mutex: pre-creating groups on both phones makes them invisible to each other. The fix became the architecture: BLE for presence, groups only on demand after consent.
  • OEM BLE reality: MIUI throttles frequent scans and some chips silently stop advertising after a GATT read — solved with a process-wide scan lease and health-based advertiser recovery instead of blind timers.
  • Trusting model output: structured outputs still get schema-validated twice (gateway and device), because a profile field is untrusted input like any other.

What we learned

Protocol bounds come before features; honesty in docs is a feature (we never claim AI where there isn't any); and an AI coding agent is most effective when the spec it follows is written like a contract — ours lives in the repo as AI_FEATURES_SPEC.md.

What's next

Icebreakers generated from P2P-exchanged profiles, an AI-drafted encounter diary with per-peer sharing windows, GPT-5.6-judged harassment reports, session authentication and channel encryption, and an on-device model option behind the same AiGateway seam.

Built With

Share this project:

Updates