Native Voice and device actions in Ovis

[odfalik]

Hi Hako. After the queue PRs, I've also been experimenting with a native iPhone Voice path for Ovis. The prototype can start a call to a specific Pi agent through Siri and CallKit. The call stays attached while the app moves between panes, and the agent can request authenticated actions on the phone. I want to start with Maps: an agent proposes a destination, and the phone opens it only after an explicit user action.

This is not ready for an upstream PR. It currently depends on pi-intercom for agent discovery, a separate Voice runtime and Swift package, and device-bound authentication and provisioning. I don't want to drop that whole stack onto main or ask Ovis to add a broad provider abstraction.

Would you be open to treating this as an experimental public fork or branch first? I can document the user flow and the coupling boundaries, then send only small generic pieces that belong in Ovis. If the direction is interesting, should Ovis own authenticated device actions or the native call lifecycle? It may also be better to keep both outside Ovis for now.

[devswha]

Hi @odfalik, this sounds great, and fork-first is the right call. Please keep the Voice runtime, CallKit and device provisioning in your fork while it settles, and send the small generic pieces that belong in Ovis on their own. #2400 is a good first one.

On ownership: for now I'd keep the native call lifecycle outside Ovis. Authenticated device actions that always need an explicit tap on the phone (like your Maps example) fit Ovis well, so a small, generic proposal for those is welcome once the flow is documented.

If there's more you'd like Ovis to support for this, let us know here.

[odfalik]

Thanks @devswha, that split makes sense. Voice, CallKit and device provisioning stay in my fork.

#2400 is ready for review now. It's rebased on current main, and everything lives under experiments/pi-voice-routing/ with its own README and dependency notes, so it touches nothing in the app. Its CI is waiting on maintainer approval to run, since it comes from a fork.

Next I'll write up the tap-to-confirm device action flow (Maps first) and post a small, generic proposal here.