Publish Index 01 BLE collection-transfer protocol or macOS-compatible Haversine transport

Use case

I maintain VoxHearth, an open-source, privacy-focused macOS dictation app. We would like to support Index 01 directly from a Mac:

Index 01 microphone → Bluetooth LE → memory-only PCM
→ bundled on-device speech model → text insertion

The intended runtime has no phone companion, account, webhook, MCP bridge, loopback server, cloud transcription, telemetry, firmware updater, or other network path. The ring would pair directly through Apple's CoreBluetooth framework, and transferred audio would be transcribed locally and discarded from Mac memory after use.

What we found

The public mobile app provides enough information to understand discovery and pairing:

• RealScanning.kt scans service 607B5C9B-3700-4E94-F44A-2DF900BCB0C3.
• IndexPairing.ios.kt triggers bonding by writing 00, with response, to DAAD3D52-237C-90A7-B54B-8854A134D801.
• RingSync.kt shows the useful completed-transfer contract: signed 16-bit PCM, sample rate, collection indexes, button sequence, timestamps, and contiguity information.

The remaining collection-transfer implementation appears to live in io.github.coredevices.haversine:haversine (currently f801265). The published source archives appear to contain only a manifest, the advertised coredevices/haversine-kmp repository is not publicly accessible, and the published native targets do not include macOS. Importing the complete artifact would also bring networking/update dependencies that this use case deliberately excludes.

Request

Would Core Devices be willing to publish one of the following, in order of preference?

1. The Haversine/Telesto source under its advertised open-source license, with a macOS target.
2. A protocol specification sufficient to implement a small native CoreBluetooth client.
3. A minimal, network-free macOS transport library that performs only discovery, bonding, and collection transfer.

For a compatible independent implementation, the minimum useful specification would cover:

• GATT service and characteristic roles and required properties;
• manufacturer-advertisement layout and wake/sync behavior;
• Telesto framing and the commands required to enumerate and transfer collections;
• collection metadata, multipart audio encoding, endianness, sample-rate representation, and button-sequence encoding;
• MTU/flow-control, ordering, rollover, retry, timeout, and integrity rules;
• acknowledgement/deletion behavior, especially when a transfer or transcription fails; and
• bonding, link-encryption, authentication, and reconnect assumptions.

We do not need firmware-update support, cloud integration, analytics, or agent/webhook features. We are also happy to consume a narrower supported API rather than depend on protocol internals, provided it can be shipped in a native macOS GPL application without adding runtime networking.

Work already done

VoxHearth already has a bounded external-audio ingress that rejects invalid or concurrent submissions and sends accepted PCM through the same memory-only local transcription path as microphone dictation. We have deliberately not guessed at packet commands or shipped an opaque iOS binary as a workaround.

If useful, I am happy to test a draft specification or macOS transport against a retail Index 01 and contribute interoperability findings or a narrowly scoped integration back upstream.

Thank you for considering this. Direct desktop support would make Index 01 useful as a genuinely local capture device without requiring a phone or online bridge.