__  __ _   _ ____  __  __ _   _ ____
|  \/  | | | |  _ \|  \/  | | | |  _ \
| |\/| | | | | |_) | |\/| | | | | |_) |
| |  | | |_| |  _ <| |  | | |_| |  _ <
|_|  |_|\___/|_| \_\_|  |_|\___/|_| \_\

Murmur

Your wearable. Your models. Your memory.

Murmur is an open-source mobile app for connecting AI wearables to the services you already pay for. Pair a device, add your own provider keys, and turn captured audio into transcripts, summaries, memories, and actions—without being locked into an expensive subscription.

The first target is the Omi wearable. The longer-term goal is a small, device-agnostic foundation that can support other Bluetooth voice wearables through adapters.

Note

Murmur can now discover nearby Omi wearables, connect or disconnect over Bluetooth Low Energy, and show the live connection state. Audio capture and AI features are not implemented yet.

Why this project

AI wearables are useful, but their companion apps often tie the hardware to one cloud, one model, and one recurring plan. Hardware owners should be able to choose how their audio is processed and where their data lives.

Murmur aims to provide:

• Bring your own keys — connect transcription and AI providers you choose.
• Hardware choice — start with Omi and add devices behind a common interface.
• Provider choice — avoid coupling the experience to a single model vendor.
• Remote control — securely send approved voice commands to your computers, servers, and automations from wherever you are.
• Privacy by design — make capture visible, obtain consent, minimize retention, and keep secrets in platform-secure storage.
• Open source — make the client and device integrations inspectable and community-driven.
• Useful basics — live transcription, summaries, searchable conversations, notes, and action items without unnecessary complexity.

Product direction

The initial experience should be deliberately small:

1. Pair an Omi device over Bluetooth Low Energy.
2. Configure a speech-to-text provider and an LLM using your own API keys.
3. Start and stop capture with an unmistakable in-app state.
4. Stream or upload audio for transcription.
5. Generate a summary, notes, and action items.
6. Search or export your own conversation history.

Omi support is the first milestone. Support for additional wearables should arrive through device adapters only after the core flow is reliable.

Architecture

Wearable
   │ Bluetooth LE
   ▼
Device adapter ──► audio pipeline ──► transcription provider
                                           │
                                           ▼
Local conversation store ◄──────────── AI provider
          │
          └──► summaries, notes, actions, and export

Current technical direction:

• A Flutter and Dart mobile client for iOS and Android.
• Omi-compatible BLE audio as the first device adapter.
• Direct provider calls where practical, with an optional self-hosted gateway only where mobile limitations require one.
• API keys stored using iOS Keychain / Android Keystore-backed secure storage and never committed or synced by default.
• A local-first data model with explicit opt-in for any cloud synchronization.

Stack

Area	Choice
UI	Flutter
State	Riverpod
Navigation	go_router
Bluetooth LE	flutter_reactive_ble behind wearable adapters
Local data	Drift and SQLite
Secrets	flutter_secure_storage
Provider APIs	Dart HTTP and WebSockets
Remote control	Authenticated agents with an optional relay
Backend	None required for the initial app

Development

Murmur currently targets iOS and Android and uses the application ID dev.october.murmur.

Prerequisites:

• Flutter 3.35 or newer
• the iOS or Android toolchain for the platform you want to run

flutter pub get
flutter run

Run Murmur on a physical iOS or Android device: Bluetooth discovery is not available in the standard mobile simulators. Wake the Omi, keep it nearby, allow Bluetooth/Nearby devices access when prompted, and tap Scan for Omi. The app only shows devices advertising Omi's BLE service.

The current milestone deliberately stops at a verified BLE connection. It does not subscribe to the microphone characteristic, record audio, or send data to a provider.

Before submitting changes:

flutter analyze
flutter test

Possible provider support

Provider support will be decided during implementation. Likely categories include:

• Speech-to-text services
• Hosted or local language models
• Embedding and search providers
• Optional user-owned storage or sync backends

The provider layer should use small adapters so users are not forced into one vendor.

Remote manager

Murmur should turn a wearable into a secure remote manager. You could speak into your Omi while away from your desk and ask a paired computer or server to check a deployment, start a backup, run an approved automation, or report its status. The result should return to Murmur as a readable response and, where the device permits it, a spoken response.

Omi → Murmur → transcription and intent → permission check
                                                │
                                                ▼
                                      encrypted relay or tunnel
                                                │
                              ┌─────────────────┴─────────────────┐
                              ▼                                   ▼
                    agent on your computer              agent on your server
                              │                                   │
                              └────────── result and audit ───────┘

Remote control will be opt-in and is not implemented yet. Its design must treat model output as untrusted input rather than executing generated shell commands directly. The first version should require:

• explicitly paired and revocable devices
• encrypted, authenticated communication
• allowlisted tools and structured commands
• confirmation for destructive or sensitive actions
• least-privilege agents on every target machine
• a durable audit log of requests, approvals, results, and failures

Users should be able to self-host the remote agent and relay. A managed relay may be considered later, but it must not be required for local wearable features.

Privacy and responsible recording

A wearable microphone can capture sensitive conversations. The app must make recording status obvious and give people control over collection, retention, deletion, and export. Users are responsible for obtaining consent and following the recording and privacy laws that apply where they live and record.

Before a production release, the project should document its threat model, key storage, data flows, retention defaults, deletion behavior, telemetry, and provider-specific privacy implications.

Roadmap

• Choose Flutter for the cross-platform mobile client
• Scaffold the iOS and Android app
• Discover Omi hardware and show its live BLE connection state
• Validate Omi BLE audio streaming
• Define device, transcription, and AI provider interfaces
• Build secure bring-your-own-key configuration
• Ship the basic capture → transcript → summary flow
• Add local history, search, export, and deletion
• Design and implement the authenticated remote-agent protocol
• Document a process for adding more wearable adapters
• Identify reusable fixes and contribute them upstream to Omi

Relationship to Omi

BasedHardware/omi is the primary reference for the first device integration. Its open-source Flutter app, firmware, SDKs, and device protocol provide valuable prior art for understanding Omi hardware and BLE audio.

Murmur is an independent community project and is not affiliated with or endorsed by Based Hardware or Omi. We intend to respect upstream licensing, clearly attribute reused work, report relevant findings, and contribute generally useful fixes or documentation back to Omi whenever possible.

The initial device detection follows Omi's advertised BLE service and is attributed in THIRD_PARTY_NOTICES.md.

Contributing

The project is at an early device-connectivity stage. Contributions are especially useful around:

• Omi protocol and BLE behavior
• reliable background audio and Bluetooth behavior on iOS and Android
• secure on-device key and conversation storage
• provider-neutral interfaces
• secure remote agents, permissions, and command auditing
• privacy, consent, and data-retention design
• accessibility and low-friction mobile UX

Open an issue with a focused proposal before starting a large implementation.

License

Licensed under the Apache License 2.0.