Expose host capability flags (and version) to products

[shawntabrizi]

Follow-up to paritytech/polkadot-app-android-v2#861, closed with a redirect here.

Problem

Products cannot detect what the host they are running in actually supports. Concrete cases from shipping playground.dot's site builder across all four hosts:

• Navigation: Android builds before polkadot-app-android-v2#864 accepted host_navigate_to and reported success while silently discarding the navigation outcome. Undetectable from the product — the only workaround was UA-sniffing the platform, which now mispunishes fixed builds because there is still no way to tell them apart.
• Window opening / dialogs: neither mobile host wires window.open / target="_blank" or JS dialogs; products that know this can render alternative UX instead of dead controls.
• iframes: both mobile container scripts block iframe creation unconditionally (polkadot-app-android-v2#857, polkadot-app-ios-v2#1116); products currently discover this by runtime probe + caught exception.
• Relay limits: the Android statement relay caps messages at 256 KB, so remote-signing a large payload fails with a generic error; a product that could read the cap would size payloads to fit or route differently.
• Allowance/feature availability: AutoSigning is accepted in allocation requests but unimplemented on every host; PreimageSubmit exists everywhere today but products had no way to know that before probing.

In every case the product's choices are: probe-and-catch (when a failure signal exists), UA-sniff (fragile, punishes fixed builds), or hardcode per-host assumptions (stale the day a host updates).

Design constraints from existing issues

• truapi-server: actually drop the feature_supported host callback #105 plans to drop feature_supported because its current tag (chain catalog) is answerable by the Rust core itself. Host implementation capabilities are exactly the class that is NOT core-answerable — they differ per host shell and per host version. So either feature_supported survives for that narrower purpose, or capabilities need a new home.
• Expose the deployed product dotNS identifier to products #112 proposes returning product identity from the handshake. The same envelope is a natural fit: a handshake response carrying { hostVersion, capabilities: [...] } gives products one round-trip for everything, and absent fields on older hosts degrade to "unknown → assume false" — the same backwards-compatible semantics Desktop's current feature_supported default already has.

Ask

A product-readable surface (handshake response field, or a retained host-capability call) enumerating host-implementation facts products branch on: navigation-with-outcomes, window opening, JS dialogs, iframe support, preimage submit, auto-signing, relay payload limits — plus a host version string as the escape hatch for anything not yet enumerated.

🤖 Generated with Claude Code