**Note** from Bead: Wireless Adb · [canonical source](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/02-combinations-and-leverage.md) · session 2026-06-24 · discussion: Talk: Wireless Adb
ADB on its own gets you a shell and a file channel. The leverage comes from **composing it with tools that already mesh into the acequia.** Each recipe below turns the phone into a different kind of parciante node. They are sketches and open questions, in keeping with the exploratory posture; commands are illustrative and should be verified against the device in hand. The organizing idea: ADB supplies the **short, trusted, local link** (USB or LAN) into the walled device. Another tool supplies the **long-haul mesh route**. Chain the two and the phone joins the commons.
## Recipe A — `adb reverse` + a local origin = phone consumes the commons with zero inbound route The phone has no public address and sits behind carrier NAT. Instead of trying to reach *in* to the phone, give the phone a `localhost` that is really your origin. ``` # On the host, an acequia origin is running (Caddy / node / nephele) on :8080 adb reverse tcp:8080 tcp:8080 # Now, in any app or browser ON THE PHONE, http://localhost:8080/ resolves to the host origin. ``` The phone's traffic never touches the public internet; it rides the USB/Wi-Fi ADB link to the host, which is itself already meshed. This is the cleanest answer to "routes need to be found": one reverse forward plus one already-meshed origin. Pair it with [C:/caddy/](c:/caddy/) serving the local origins, or with the [`82bd6fa4` stephenguerin.live runtime](https://redfish.acequia.io/guerin/.agents/82bd6fa4-4d5a-435b-9deb-ca930a82aa89/about.md).
## Recipe B — `adb forward` + Caddy / Cloudflare tunnel = phone-hosted service becomes an acequia origin Run a server on the phone (a static file server, a camera streamer, a Termux node app), then expose it. ``` # A server is listening on the phone at :8000 adb forward tcp:9000 tcp:8000 # host:9000 -> phone:8000 # Point Caddy (reverse_proxy localhost:9000) or a Cloudflare tunnel at host:9000. ``` Now the phone is serving real URIs into the mesh, fronted by a public origin that handles TLS and auth. This is the **distributed-origin-architecture** made concrete: many local nodes serve the same logical paths, and one of them is a phone in your pocket. The phone is the origin; Caddy/Cloudflare is the membrane.
## Recipe C — ADB + Termux + node = the phone runs a real acequia node [Termux](https://termux.dev/) is a full Linux userland on Android (no root). Side-load it with `adb install`, then over `adb shell` (or Termux directly) install Node and run the actual nephele/WebDAV server or a static origin on the device. Combined with Recipe B, the phone is not just forwarding a port; it is a genuine origin host running the same server software as the rest of the mesh. The phone's own storage (and OPFS/IndexedDB in its browser, per [browser-hosting](c:/Users/steph/Documents/sites/.ai/browser-hosting.md)) becomes commons storage.
## Recipe D — WebADB (WebUSB) = a browser drives the phone, no host daemon at all The ADB host protocol (note `01` §2) is simple enough to reimplement. [ya-webadb](https://github.com/yume-chan/ya-webadb) speaks ADB **from a web page over WebUSB**, no installed `adb` binary, no server on `:5037`. This is the tightest tie to the ecology: - It makes the **browser a first-class parciante node** (memory: browser-is-a-parciante-node) that can shell into, push to, and screen-mirror a phone directly. - It rides **WebUSB**, itself a vendor self-interest bridge (Google pushing the web-as-platform). So the recipe composes two Google bridges: WebUSB carries ADB. See note `03`. - A CE body (in-browser agent, ambient-cookie auth) could drive a phone with no extra tooling, then PUT the results straight into a bead. Open question: WebUSB needs a user gesture and Chromium; Wireless ADB over the network from a pure browser is harder (no raw TCP in the browser). A small local helper, or WebTransport/WebSocket bridge, may be needed for the wireless case.
## Recipe E — ADB + scrcpy = the phone screen as a controllable surface [scrcpy](https://github.com/Genymobile/scrcpy) uses ADB to push a small server to the device, then streams H.264 screen frames back over the ADB tunnel and injects input events. The result is a live, low-latency mirror you (or an agent) can see and control. Combined with `adb shell input` and the activity manager, this gives an agent a **DOM-like control surface on a phone** (an analogue of the CE body's live DOM), useful for driving apps that have no API. Pairs with the "agent-as-file-ducktyping" idea: the phone screen is just another resource an agent negotiates verbs against.
## Recipe F — ADB + geo.camera capture = the phone as a calibrated camera node A phone is a camera with GPS, IMU (alt/az), and a good lens. ADB makes it a **camera parciante**: - `adb exec-out screencap` or a capture app writing to `/sdcard`, pulled with `adb pull`, or streamed live via Recipe B. - Telemetry sidecars (GPS, orientation) read over `adb shell dumpsys sensorservice` / `location`, named per the camera-telemetry convention (`cameraname-<unixUTC>`). - The frames feed the celestial / terrain tie-point calibration in [`9943ac1c` astronomical-pano](https://redfish.acequia.io/guerin/.agents/9943ac1c-caa1-479d-b17e-89ef7ca326b6/about.md) and the camera isomorphism in [`a55f5270` nuke-geo-camera](https://redfish.acequia.io/guerin/.agents/a55f5270-1767-475b-924a-1ef59ee09e90/about.md). The phone joins the camera network as one more (pose + intrinsics + distortion + time) tuple.
## Recipe G — ADB-bootstrapped WebRTC = phone joins the P2P observer network The aside's two bridges, composed. Use `adb reverse` (Recipe A) to give a phone app a reliable `localhost` signaling endpoint on the host, complete the WebRTC handshake through it, then let **WebRTC** carry the actual media P2P. This is precisely the Phase II WebRTC/Cloudflare observer-network plan in the object-tracker (astronomical-pano bead): ADB solves the bootstrap/discovery on the LAN; WebRTC solves the high-bandwidth media path once peers know each other. Two vendor self-interest bridges (ADB, WebRTC) doing exactly what the acequia needs.
## Recipe H — multi-hop: chaining tunnels through several walls The forwards compose. A phone app hitting `localhost:8080` (via `adb reverse`) lands on the host, where Caddy reverse-proxies to a Cloudflare-tunneled origin, which is itself one peer in the nephele mesh. That is three walls crossed (device sandbox, host firewall, NAT) with no inbound route opened anywhere. The acequia auth membrane (goes-inta / goes-outa, ingest read-scope / egress write-scope) sits at the Caddy/Cloudflare hop, not at the ADB hop, so scoping stays where it belongs.
## The pattern under all of them ADB is the **last-mile trusted link** into a device the public internet cannot reach. Everything else (Caddy, Cloudflare, WebRTC, the nephele mesh) is the **long-haul**. The acequia already owns the long-haul. ADB is the missing last mile to the phone. Find that one link and the most locked-down, most capable device a parciante owns becomes a peer. Generalization beyond Android: the same shape applies to any vendor-opened last-mile door, for example the iOS equivalents (`idevice*` / libimobiledevice over USB, Apple's much narrower opening), WebUSB/WebSerial/WebHID for arbitrary peripherals, and Chromecast/Cast for displays. ADB is the richest instance because Google opened it the widest (note `03`).
## Open questions to keep exploring - [ ] Wireless ADB from a pure browser (no installed daemon): is there a WebTransport/WebSocket-to-ADB bridge, or does the wireless case always need a small local helper while WebUSB stays cable-only? - [ ] Can `adb reverse` survive Wi-Fi roaming / doze, or does it need a keepalive and auto-reconnect wrapper to be a dependable origin link? - [ ] What is the minimal scoped, apoptotic skill for "phone joins the mesh for this session and cleanly leaves"? (pair → reverse/forward → serve → revoke trust → disable wireless debugging.) - [ ] Termux-hosted nephele vs phone-browser OPFS as commons storage: which is the better phone-as-origin substrate? - [ ] iOS parity: how far does libimobiledevice get us, and where does Apple's narrower door stop the same recipes? </content>
## References (bead cross-links) - Bead: Stephenguerin.live Router Bead · [canonical](https://redfish.acequia.io/guerin/.agents/82bd6fa4-4d5a-435b-9deb-ca930a82aa89/) - Bead: Astronomical Pano · [canonical](https://redfish.acequia.io/guerin/.agents/9943ac1c-caa1-479d-b17e-89ef7ca326b6/) - Bead: Nuke Geo Camera · [canonical](https://redfish.acequia.io/guerin/.agents/a55f5270-1767-475b-924a-1ef59ee09e90/)