**Note** from Bead: Wireless Adb · [canonical source](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/03-self-interest-bridges.md) · session 2026-06-24 · discussion: Talk: Wireless Adb
## The thesis (Stephen's aside, expanded) Platform vendors run walled gardens by default. They also, periodically, build genuine interoperability bridges that make our devices actually work together. The reliable predictor of when they do this is **their own commercial interest**. When a vendor needs adoption of something it is selling, it opens a real door, and that door tends to stay open because the vendor now depends on it. Two clean examples Stephen named: - **WebRTC.** Google acquired GIPS (2010) and On2, then open-sourced the stack and drove it into a W3C/IETF standard. The motive was commercial: kill the plugin era (Flash), make the browser a real-time platform, and make **Chromebooks, Hangouts, and later Meet** viable without native apps. The byproduct is the universal, royalty-free, peer-to-peer media stack the whole industry now uses, including our planned observer network. - **ADB.** Google opened a full device-control bridge to **promote app development** and keep the **Play Store** stocked. Developers needed to install, debug, shell into, and instrument their phones, so Google shipped a documented, scriptable bridge into the device. The byproduct is the general-purpose route into Android that this entire bead is built on. The shape is the same: a tool built to serve the vendor's funnel (sell Chromebooks, fill the store) turns out to be a durable public good the vendor cannot easily take back.
## Why the bridges are durable (and therefore worth building on) A bridge built for the vendor's own funnel has three properties the acequia should value: 1. **The vendor has a stake in keeping it open.** Closing ADB would break every Android developer; dropping WebRTC would break Meet. The vendor's self-interest is now load-bearing on the bridge's survival. That is a stronger guarantee than goodwill. 2. **It is documented and widely reimplemented.** Because the bridge exists to be *used by outsiders*, it gets specs, multiple client libraries, and tooling. ADB's wire protocol is reimplemented in pure JS (WebADB); WebRTC has many independent stacks. That breadth is what lets the acequia speak the protocol without the vendor's blessing or binary. 3. **It is keyless and deterministic at the wire.** These are mechanical protocols, not gated APIs requiring a per-call vendor token. That matches the anti-reification rule: prefer the keyless deterministic path the vendor already paved over a new component you have to build and govern.
## The acequia move: harvest the bridges, do not depend on the vendor's intent The strategy is to **route through the self-interest bridges while they are open, and keep the routes vendor-replaceable.** Concretely: - **Treat each bridge as a desire line the vendor paved for us.** Use ADB, WebRTC, WebUSB, mDNS discovery, Cast, intents as ready-made last-mile and long-haul links (note `02`). Do not reinvent them. - **Compose bridges across vendors.** WebUSB carrying ADB (Recipe D), or ADB bootstrapping WebRTC (Recipe G), stacks two openings into one route. The more the route is assembled from independent open bridges, the less any single vendor can sever it. - **Keep the acequia value at the membrane, not in the vendor.** Auth, scoping, and the namespace live at our Caddy/Cloudflare/nephele hop (goes-inta / goes-outa). The vendor bridge is only the carrier. If a bridge closes, the membrane and namespace are unaffected and the carrier is swapped. - **Watch for the next opening.** The thesis predicts where to look: whenever a vendor is pushing a new device or platform that needs outside adoption, expect a fresh bridge. Recent candidates worth tracking are WebUSB/WebSerial/WebHID (web-as-platform), Quick Share / Nearby (cross-device transfer), Matter/Thread (smart-home interop the big vendors co-opened to grow the category), and the Cast SDK (displays).
## The catalog of openings (running list) | Bridge | Vendor motive (the funnel) | Acequia use | |---|---|---| | **ADB** | Fill the Play Store; serve app developers | Last-mile route into any Android device (this bead) | | **WebRTC** | Sell Chromebooks / Meet; kill plugins | P2P media for the observer network | | **WebUSB / WebSerial / WebHID** | Make the web a native-app replacement | Browser-as-node drives peripherals; carries WebADB | | **mDNS / Wireless Debugging discovery** | Frictionless dev setup | LAN peer discovery for acequia nodes | | **Cast SDK / Chromecast** | Sell dongles; own the TV | Display surfaces as resources | | **Android Intents / SAF** | App ecosystem glue | Cross-app data routes on-device | | **Matter / Thread** | Grow smart-home category | Device interop the acequia can mesh |
## The caution These bridges are vendor-controlled carriers, so the same self-interest that opens them can narrow them (tighter WebUSB gestures, stricter `adb` defaults, deprecations). That is exactly why the membrane-and-namespace value stays on our side and the carrier stays swappable. Build on the bridges; depend on the mesh. Every constraint is soft, and a vendor opening is one of the softer ones, so keep the route portable. </content>