Skip to content

docs: the phone app, before the first line of it - #107

Draft
pierre-rouanet wants to merge 1 commit into
mainfrom
docs-mobile-app-approach
Draft

docs: the phone app, before the first line of it#107
pierre-rouanet wants to merge 1 commit into
mainfrom
docs-mobile-app-approach

Conversation

@pierre-rouanet

Copy link
Copy Markdown
Member

app-path-design.md covers the robot half of the app path and says almost nothing about the client. This adds docs/design/mobile-app.md for the other half, and links the two.

It settles three things.

The protocol belongs in Rust. tauri-plugin-blec exposes the same handler to Rust as to JS, so the app can depend on duck-ipc-proto and btd::framing and drive the radio from the Rust side — which makes it unable to drift from the daemon, the property duck-btctl already has. That is the argument for Tauri here, and it is not the usual one: every cross-platform toolkit gives you one codebase, only this one lets the client speak the server's own types.

Bluetooth is the permanent channel, not a setup step. Reachy Mini's BLE code runs once and hands over to the LAN; ours is where the settings live, because settings that work with no network is what §2.2 exists for. So the app needs a session layer that reconnects and re-authenticates silently — §3.2 discards the session with the peer — and that layer has no counterpart to copy.

A phone spike comes before any screen. §5.5 is the blocker and it is currently a fact about CoreBluetooth on a laptop. Scan, connect, hello, authenticate, system.info, with --require-pairing on, on a real iPhone and a real Android, answers that plus the one-characteristic question, the MTU, and the stored-identifier fast path.

The Reachy Mini app is treated as a reference rather than a base: its plumbing is worth taking — blec wiring, Android permissions, safe-area work, the release workflow, the store compliance notes — and its BLE dialect and HF-terminated wizard are not.

Also a table of what the robot still owes the app, each row pointing at the section of app-path-design.md that owns it, and two open decisions: whether v1 shows a PIN screen for a PIN that is 000000, and whether one app ever serves both robots.

Nothing is built.

`app-path-design.md` describes the robot half of the app path in detail and
says almost nothing about the client, beyond two warnings aimed at whoever
writes it. This is the other half: what the app is built from, what it takes
from the Reachy Mini app and what it deliberately does not, and the list of
robot-side gaps that are app-facing.

Three things it settles. The protocol belongs in Rust, because
`tauri-plugin-blec` exposes the same handler to Rust as to JS, so the app can
depend on `duck-ipc-proto` and `btd::framing` and be unable to drift from the
daemon — the property `duck-btctl` already has. Bluetooth is the permanent
channel here rather than a setup step, which is the one structural difference
from the app we already ship and the reason its wizard cannot be inherited.
And a phone spike with `--require-pairing` on comes before any screen, because
§5.5 is a fact about CoreBluetooth on a laptop and the blocker is about a
phone.

Nothing is built. Written now so the decisions are arguable rather than
implied by a repo, and so the open ones — the PIN screen, one app or two —
are recorded as open.

Assisted-by: Claude:claude-opus-5[1m]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant