Repository navigation
Proof-of-concept Android app + input interface extension (touch, mouse, hover) for relaying into live apps #1831
Description
Origin
Owner direction (Drew, 2026-10-28), added alongside the #795 phone-test plan (#1826): 'add another issue for designing and implementing a proof-of-concept Android app and extending the accepted interfaces.' The Android app is both a product-direction PoC and a native phone endpoint for the id connectivity stack — it relays the phone's input into one of the raw apps (e.g. a TUI app) running elsewhere, over a limited interface built from what the platforms can actually support.
Design: extend the accepted input interfaces to cover
Environments / devices:
- Multi-touch touchscreens (Android)
- Mice (desktop/native)
- Mouse over (hover) on web
- Mouse over (hover) on TUI
Events, as supported per environment:
- mouse enter / mouse leave
- click
- right click
- (Android) press and long press — the platform's native equivalents where right click does not exist
Platform realities the design must state plainly:
- Web has no real right click unless the app takes over the context menu — with a Wasm build we might do exactly that; in general, web = no right click.
- Android has press / long press instead of right click; how the other options map onto Android gestures is an open design question to answer here, not assume.
- The relayed interface is deliberately LIMITED to the subset we can support end to end: minimally the ability to click things, and ideally drag and scroll. Extend from there once the subset is proven.
Proof of concept
An Android app that connects (id connectivity) to a running app instance and relays its touch input — tap as click, plus drag/scroll if the subset allows — so the remote app is genuinely operable from the phone. This also gives the #795/#1826 line a native phone peer alongside the Wasm page.
Acceptance criteria
- A design (in
doc/or on this issue) defining the input event model: the common core (press/click, drag, scroll, long press) plus per-environment extras (hover enter/leave on web + TUI, right click where the platform allows it, incl. the web/Wasm context-menu question answered explicitly). - The accepted-interface definitions in the codebase are extended per that design (events named above), with unsupported-per-environment events refused explicitly rather than silently dropped.
- The PoC Android app builds, connects to a live app instance, and relays tap (+ drag/scroll if in the proven subset) well enough to click through a real screen — demonstrated and recorded (here or on id phase-3: P3.7 real-network holepunch and n0 QAD tests on two networks are owner-blocked with no tracking issue #795).
- Gaps found (events a platform cannot produce, latency limits) are recorded on this issue.
Activity
developing-today commentedon Oct 28, 2026
CODE-760
dezren39 commentedon Oct 28, 2026
Owner notes (Drew, 2026-10-28): transport, distribution, and a scope addition
Transport — no VPN privilege in the PoC. Iroh runs QUIC over UDP, and Android apps can use UDP/QUIC directly; Delta Chat ships iroh on Android without requiring a VPN, as far as the owner knows — the PoC follows that path. A mode using Android's VPN privilege (VpnService) is explicitly NOT a priority: if direct network control or a significant performance case ever justifies it, that is another time — a separate app, or an optional mode in this one. It must never be required just to open the app; those privileges can stop a user from installing it at all.
Distribution — Play Store is out of scope for this issue. Done for #1831 = a working APK exists that we can use (direct distribution). The owner has the business org and can get Google Play approval if it is ever wanted, but store listing, VPN-permission declarations, and Google approval are a separate effort that has nothing to do with this PoC.
Scope addition — the app is also an id node, not only an input relay. 'All the things' includes: the app can download and store id records itself, and serve them — while the app is open, if someone requests an ID record from it AND the app user has enabled responding, it answers. Serving is therefore opt-in on the device and only while the app is open (no background-service promise in the PoC).
Acceptance criteria updated by this comment: add (a) the app runs with no VPN permission requested; (b) an APK artifact is produced and installable; (c) the app stores id records locally and, with responding enabled, serves a stored record to a requesting peer while open.
dezren39 commentedon Oct 28, 2026
Owner bonus item (Drew, 2026-10-28): dynamic Roc apps — stretch, non-blocking
Drew: 'It would be very, very cool (bonus points) if you were able to allow Android apps to compile and run Roc apps dynamically.'
His reasoning, recorded: the Roc homepage's Wasm examples suggest Roc apps compile to Wasm and run in the browser. If that holds, it works at least in a Chrome web page we load — and if a Chrome page can do it, an Android app should be able to as well (WebView hosting the same page/runtime, or an embedded Wasm runtime), in theory.
Status: stretch goal. It does not gate this issue's PoC acceptance. If investigation shows it is impossible or highly difficult with the current Roc/Wasm tooling, it defers to a future day with the finding recorded here — what exactly blocked it — rather than silently dropped. Two routes to evaluate when picked up: (1) Chrome page route (also reusable by the #1826 Wasm test line); (2) in-app route (WebView or embedded Wasm runtime in the Android app).
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/none). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up
c29174f1Interfaces { cli, web }only (src/id/src/app_manifest.rs), so the input/hover/TUI extension does not exist yet; the repo has no Android build files at all; the host has Android SDK build-tools 35 + platform 35, no Gradle, no emulator/system image, no attached device, no Rust Android targets.dezren39 commentedon Nov 3, 2026
Triage verdict 2026-11-03 — live, entirely unstarted, and oversized; split into 3 slices + 1 stretch
1. Nothing has landed — every acceptance box is still open.
doc/(checked the index and the most recent design folders).Interfaces { cli, web }only —src/id/src/app_manifest.rsL55-71 (CliInterface,WebInterface); there is no TUI interface and no input-event declaration at all.src/id/contract/shell-contract.v1.jsoncontains 0 occurrences ofpointer/mouse/wheel/scroll/touch.build.gradle*,AndroidManifest.xml, orgradlewanywhere.2. What is repo-actionable now (and what is not).
AppManifestand every sub-struct carry#[serde(deny_unknown_fields)], so adding an[interfaces.tui]/ input section is a strict schema change — it needs a version/migration story. Low blast radius today: exactly oneapp.tomlexists (pkgs/id/apps/tic-tac-toe/app.toml).3. Build-host feasibility, verified on this laptop.
build-tools;35.0.0,platforms;android-35,platform-tools37.0.1,cmdline-tools;22.0,cmake;4.1.2(Nix-provided,ANDROID_HOMEset).rustup target list --installedhas none). No device is attached (adb devicesempty).3a02ea3to6b71c24#3 ("connects to a live app instance and relays tap/click through a real screen") cannot be demonstrated without either an installed emulator image (needs KVM; network + license acceptance) or a physical phone. That is the demo blocker to resolve before S3 is claimed — it is not a reason to block the design.4. Split and ordering (recommended, for the split into child issues).
Interfacesand the shell contract per S1, with the strict-schema version note and tests that an unsupported event is refused explicitly.5. Dependencies and ordering.
Verdict: keep open. Labels set (
kind/feature,app/id,effort/l,priority/normal). No design doc, branch, or PR was created by this triage — S1 is the next action, and it is a design issue, not an implementation task.