Feature Request: A2A Mesh on Mobile (iOS and Android) #91

Activity

1. openamer

   added

   a2a

   feature-request

   mobile

   on Sep 25, 2026
2. openamer commented on Sep 25, 2026

   

   openamer

   on Sep 25, 2026

   OwnerAuthor

   More actions

   Thanks for the feedback! Mobile support is on the roadmap.

   Current State: Desktop/Windows only. No mobile support.

   Planned for v2.0:

   1. Mobile SDK - iOS and Android
   2. Background operation - agents run in background
   3. Battery optimization - minimal battery drain
   4. Push notifications - alert when tasks arrive
   5. Offline mode - queue messages when offline
   6. Mobile-specific features - camera, GPS, sensors

   Priority: We're prioritizing desktop first. Mobile is v2.0. The A2A Mesh protocol is being designed with mobile in mind, so the SDK will be portable.

   Battery Optimization: We're studying how to minimize battery drain. The heartbeat can be throttled, and messages can be batched.

   Would love to hear if mobile is important to you!
3. openamer commented on Oct 11, 2026

   

   openamer

   on Oct 11, 2026

   OwnerAuthor

   More actions

   Thanks for filing this — the questions at the bottom are the right ones, and they're worth an honest answer rather than a roadmap. Checked against main today (HEAD 06ff4c5690), so what's below is what actually exists, not what's planned.

   Honest status: there is no mobile SDK today. The A2A layer is Python and desktop-oriented, and nothing in the tree ships for iOS/Android. But the protocol was deliberately kept transport-agnostic, which changes the answer to "how do we do mobile?" in a useful way.

   The recommendation: don't port the agent to the phone — let the phone be a thin A2A peer.

   The heavy cognition (the 2B brain, skills, vectors) stays on the desktop/relay; the phone joins the mesh as a small client. Concretely, three pieces already in the tree make this feasible with no server change:

   1. Wire format is signed JSON, not a custom RPC. core.py::Envelope is canonical JSON (sort_keys=True, compact separators) with an Ed25519 signature over the body and a 5-minute replay window. Any mobile crypto stack (iOS CryptoKit, Android java.security) can sign/verify it.
   2. Transport is plain stdlib HTTP. transport.py implements exactly two endpoints — GET /card (identity/capabilities) and POST /message (receive + verify a signed Envelope). No WebSocket handshake, no extra runtime dep — so a Kotlin/Swift HTTP client speaks the mesh as-is.
   3. Discovery needs no GitHub token. beacon.py::NodeBeacon publishes a small signed beacon (fingerprint + pubkey + optional endpoint + caps) over an optional MQTT rendezvous, lazily imported. That's the battery-friendly discovery path: one ~hundreds-of-bytes ping per interval.

   Answering your three questions directly:

   • Background operation? On mobile, no — iOS/Android aggressively kill background execution, and running the full agent there would fight the OS. Keep the agent on the desktop; the phone runs a client that receives tasks and surfaces results. Deliberate: the phone is a node, not a compute node.
   • Battery? One signed beacon per interval (adjustable) + push/poll for task arrivals. Discovery is O(one small ping), not a persistent socket. The MQTT broker does the fan-out so the phone isn't holding connections open.
   • Offline mode? Outbound envelopes are just JSON — queue them and flush on reconnect. One caveat that falls out of the replay window: queued messages need fresh timestamps on flush, not the timestamp from when they were queued, or the 5-min window rejects them.

   Trust still gates execution. Per trust.py, an inbound message only runs if the peer is trust added and granted a capability — so a mobile client can be added as a discoverable-but-not-executable peer until the operator opts in. Good default for a device you carry around.

   Smallest real first step: a minimal Kotlin/Swift client that does POST /message + Ed25519 verify+sign against the node's /card. That's the whole protocol surface for a first cut and it needs zero backend changes. Architecture overview: docs/asi-core.md; the security/trust model is scoped in docs/engineering/a2a-guardian-pipeline.md.

   If there's appetite, I'm happy to write a short docs/a2a-mobile-client.md spec (the 2-endpoint contract + the fresh-timestamp-on-flush rule) so the first mobile implementer has a target to build against.