A2A bridge: community interoperability and production validation track

[anulum]

The local A2A bridge is now implemented and documented as a local-first HTTP+JSON edge for SYNAPSE CHANNEL. This is not a bug report. This is an open community validation track for people who want to test interoperability and production-facing behavior outside my local environment.

Current local status

Implemented locally in the bridge:

• A2A Agent Card projection from the live SYNAPSE capability manifest.
• HTTP+JSON bridge routes for discovery, message send/stream, task list/get/cancel/subscribe, push-notification config, and JSON-RPC dispatch.
• Optional Bearer auth for protected routes.
• Local state-file persistence for tasks and push configs.
• Stale in-flight task recovery after restart.
• Bounded in-process subscription replay.
• Webhook URL validation for scheme, host, local-network targets, and embedded credentials.
• Focused local tests and repo preflight.

What still needs independent validation

These are not defects in the current implementation. They are the remaining validation tasks before anyone should call the A2A lane enterprise/production-grade in the broad sense:

• Run independent A2A interoperability/conformance checks against third-party A2A clients/SDKs.
• Exercise the bridge with a real webhook receiver, including success, timeout, retry/operator-observed failure behavior, and auth headers.
• Test the bridge through a deployed reverse proxy/TLS boundary, not only direct local HTTP.
• Review the deployment threat model: auth token handling, public discovery route, protected routes, SSRF boundaries, logs, and operational exposure.
• Validate subscription behavior against real client expectations, especially because replay is bounded process-local memory, not a durable distributed event log.
• Report any incompatibility with concrete request/response payloads, client version, bridge command, and expected behavior.

Good contributions here

Useful replies include:

• “I tested client X / SDK Y against commit or release Z, and this worked.”
• “This A2A client expects route or payload shape X; SYNAPSE currently returns Y.”
• “This webhook receiver test exposed an operational gap.”
• “This deployment pattern is safe/unsafe because...”
• “Here is a minimal reproduction or trace.”

Please avoid framing this as “A2A is broken” unless there is a concrete failing case. The accurate status is: the local bridge exists and passes local validation; broad ecosystem and production validation still needs independent evidence.

Local command surface

synapse a2a-card --endpoint-url https://agent.example.com/a2a/v1
synapse a2a-serve --endpoint-url http://127.0.0.1:8877
synapse a2a-serve --endpoint-url http://127.0.0.1:8877 --bearer-auth --a2a-token "$A2A_TOKEN" --state-file ./a2a-state.json
synapse a2a-serve --endpoint-url http://127.0.0.1:8877 --task-timeout 300 --subscribe-timeout 1

Why this is a Discussion

This is intentionally a Discussion rather than an Issue: it is a validation and ecosystem-engagement lane. Individual concrete failures found during this work can become Issues with reproduction steps.

[armorer-labs]

This is a good validation framing. I would treat “production-grade” here less as a single conformance pass/fail and more as a set of receipts that survive across the bridge boundary.

For an A2A bridge like this, the validation artifacts I would want from independent testers are:

• discovery receipt: agent card, capability manifest version, endpoint URL, auth mode, and client/SDK version
• task lifecycle receipt: submitted payload, task id, state transitions, cancel/timeout behavior, and final observed result
• webhook receipt: destination class, validation decision, auth header handling, delivery attempts, retry/backoff, and operator-visible failure mode
• proxy/TLS receipt: public origin, forwarded headers, auth termination point, and whether protected/public routes stayed separated
• replay/subscription receipt: what event window is replayable, what is lost on restart, and how clients detect the gap
• threat-model receipt: SSRF/local-network checks, token handling, log redaction, and what a compromised client can still ask the bridge to do

The interesting edge case is probably not the happy-path SDK call. It is restart + bounded replay + a real webhook receiver + a client that assumes durable event history. If that case has a crisp trace, people can reason about whether the bridge is an adapter, a local task runtime, or something that needs a stronger event log behind it.

I would also separate protocol compatibility from operational safety in the report. A bridge can be A2A-shaped and still not be safe to expose behind a reverse proxy without very explicit auth/logging/egress boundaries.

Disclosure: I work on Armorer Labs.

[anulum]

Thanks — this is exactly the right framing, and we've adopted it.

"Production-grade = a set of receipts that survive the bridge boundary" is much better than a single pass/fail, so we've turned this validation track into precisely that. Your six receipt types — discovery, task-lifecycle, webhook, proxy/TLS, replay/subscription, threat-model — are now a documented template in the repo: A2A validation receipts, with the protocol-compatibility-vs-operational-safety split, and the restart + bounded-replay + real-webhook + durable-history-client case called out as the one that matters most.

Where we're at, on your specific points:

• Replay/subscription is the honest gap. The bridge emits subscription replay only from the current process and bounds stored history with terminal-task retention GC. So on restart, in-flight tasks are recovered, but the in-process subscription window is exactly the gap a durable-history-assuming client must detect — that's the receipt we most want traced.
• Operational safety vs protocol — kept separate, as you say. Webhook validation already refuses local-network / credential-embedded / redirect-to-local targets, and protected routes require Bearer; but none of that substitutes for a real reverse-proxy/TLS receipt, which we don't have yet.

Project status for context: the local bridge is unchanged and still makes no external conformance claim until independent validation runs; recent releases have been on the coordination core, the declarative workflow layer, and the dashboard. The bridge lane is deliberately waiting on receipts like these rather than self-certifying.

If you (or anyone) run any of these against a real client/SDK + webhook receiver + proxy, please drop the receipt here — the gaps a receipt exposes become tracked work. Much appreciated, and credited in the doc.