[P1] Crate is fully synchronous, violating §18.3's async-primary model requirement

[SoundMatt]

What's wrong

RELAY spec §18.3 ("Async-primary model") states: "All blocking operations MUST be async fn. Required runtime: tokio or compatible. If sync wrappers are provided, they MUST be in a blocking sub-module and MUST NOT be re-exported from the crate root."

rust-RCP is the opposite: Controller::send/subscribe/close and Registry::register/lookup/deregister/close (src/lib.rs) are plain blocking functions exported directly from the crate root, there is no tokio or async-trait dependency in Cargo.toml, and the README advertises this as an intentional design choice:

"Blocking synchronous API (no_std-compatible core, no tokio required)" — README.md:17

Compare with sibling rust-CAN, which pulls in tokio = { version = "1", features = ["full"] } and async-trait = "0.1" (verified via gh api repos/SoundMatt/rust-CAN/contents/Cargo.toml) and follows the async-primary model the spec requires — so this is achievable within the same org and is a real divergence, not an ecosystem-wide unmet requirement.

Expected per spec

Blocking operations MUST be async fn; any sync convenience API MUST live in a non-root blocking module.

Suggested fix

Either: (a) restructure the public API to async fn over tokio per §18.3, moving the current synchronous implementation into a rcp::blocking sub-module, or (b) if a sync, no_std-friendly API is a deliberate design goal for this safety-critical crate, raise it as spec feedback (an exception/profile for no_std targets) rather than silently diverging — as-is this is a documented, non-conformant divergence from a spec MUST.

---

Filed from the RELAY ecosystem audit (2026-07-27), category: spec-conformance, severity: P1.

[SoundMatt]

Leaving this open rather than closing it, per the PR that addresses the rest of the July 2026 audit findings (#11).

What #11 does fix: the RELAY-facing boundary is now genuinely async. The new relay::Node/Caller Adapt() (rcp::adapt(ctrl), per §10.3) is async fn throughout — send/subscribe/close/call all dispatch the blocking Controller calls via tokio::task::spawn_blocking, and subscribe() follows the §10.5 goroutine/task model with a real back-pressure-aware forwarding task. This is the surface that relay interop/relay crossbar/other RELAY tooling actually talks to, so it's not just a facade.

What #11 does not do: convert the core Controller/Registry traits themselves (and the ~40 sibling modules built on them — bridges, safety controllers, etc., roughly 11k lines) to async fn. That's a much larger and riskier rewrite than anything else in this pass, and the crate's synchronous core is plausibly a deliberate design choice for no_std/embedded zone-controller targets, not an oversight — the README has described it that way since v0.1, before this audit. Converting a safety-critical crate's foundational API on the strength of a single spec clause, without confirming the spec intends that MUST to bind uniformly on no_std/embedded implementations too, felt like the wrong call to make unilaterally in a fix-everything pass.

Concretely, what would need to happen to actually close this:

1. A decision (ideally from the RELAY spec maintainers, since this is an interpretation of §18.3, not a rust-RCP-specific question) on whether §18.3's "all blocking operations MUST be async fn" is meant to apply to every implementation including safety-critical no_std/embedded targets, or whether a profile/exception is warranted there (the issue's own suggested-fix option (b) raises exactly this).
2. If the answer is "yes, no exception" — a scoped rewrite of Controller/Registry to async fn, with the current synchronous implementation moved into a rcp::blocking sub-module per §18.3's fallback clause, touching every module that implements or consumes those traits.

This is out of scope for a single code-conformance fix pass; it needs the spec-level call in (1) first.