Environment: Foundation SDK 1.0.0 (foundation 1.0.0 (039881500da0)), KeyOS 1.4.0-beta3, retail Passport Prime, third-party publisher.
Summary
Third-party apps have no way to retrieve data from the internet. I'm not asking for a network stack on the device — I'm asking whether the Envoy relay pattern you already ship, and already expose to third-party apps, could be generalised to a consented, allowlisted request/response.
The pattern already exists and is already third-party-grantable
There is no net/http API in the SDK (13 API crates: app-manager, backup, bt, camera, crypto, fs, gui-server, haptics, nfc, quantum-link, rgb-led, security, settings), and os/quantum-link's data messages are Foundation-only — PublishPsbt, SendAccountUpdate, SubscribeAccountUpdate, SendApplyPassphrase all carry requiredSignature = "foundation", and the rest are ungrouped.
But not all of them:
| message |
gating |
third-party |
SubscribeExchangeRate (id 10) |
network-and-pairing.status-and-rates, autoAllow |
✅ |
SubscribeExchangeRateHistory (id 29) |
network-and-pairing.status-and-rates, autoAllow |
✅ |
SubscribeEnvoyStatus (id 12), SubscribeConnectionStatus (id 43) |
same group |
✅ |
EnvoyTimezone (id 44) |
same group |
✅ |
Exchange rates and timezone are internet-sourced data, fetched by Envoy, relayed over the pairing, and handed to third-party apps today. So the architecture — phone has connectivity, device consumes relayed data, third parties are allowed to receive some of it — is built, shipped, and already crosses the third-party boundary. What's missing is only that the set of retrievable things is a fixed list decided at firmware build time.
What I'd like
A relay message where the app names what it wants, within limits it declared up front:
- The app declares an allowlist in its manifest — hosts or URL prefixes, fixed at build time and therefore visible to whoever reviews or signs the app.
- A
permissionGroup + grantOnFirstUse consent prompt naming the destinations, the same machinery as any other sensitive grant.
- Envoy performs the request and relays the response. Nothing on the device gains a socket, a DNS resolver, or a TLS stack.
- Response size cap and rate limit set by you; my payloads are tens of KB.
Read-only (GET-shaped) would cover every use case I have, if that narrows the surface usefully.
Why it's worth the trouble
Today the only path for app data is a host CLI writing files to a USB drive or Airlock. For passport-nft-viewer that means a laptop runs passport-nft-cli fetch --owner 0x… --out <drive> (Blockscout for the token list, IPFS/Arweave for images, resize, convert to .raw), then the drive is physically moved to the Passport. It works — that's the shipped design and I'm not blocked — but every refresh needs a computer and a cable, which puts a hard ceiling on what a third-party app can be.
I'd also note this compounds with #15: with Airlock exclusivity, staging a bundle currently costs three physical interactions and two cable moves per iteration.
The obvious objection
A relay is a data channel out of the device, so it's a privacy and exfiltration surface — that's presumably why the current list is fixed. The mitigations I'd propose are the manifest allowlist (declared, reviewable, immutable after signing), an explicit consent prompt naming the hosts, and Envoy-mediation, since the phone already has connectivity and the pairing is already trusted for wallet data. But you own that trade-off, and if the answer is that the relay stays a curated list, a useful smaller version is simply letting third-party apps petition for additions to that list — a documented process beats guessing.
What I'm explicitly not asking for
Not sockets, not an on-device HTTP client, not a general network stack, and not access to the wallet-sync messages. Just the question of whether the existing relay can carry app-declared, user-consented requests as well as firmware-declared ones.
Environment: Foundation SDK 1.0.0 (
foundation 1.0.0 (039881500da0)), KeyOS 1.4.0-beta3, retail Passport Prime, third-party publisher.Summary
Third-party apps have no way to retrieve data from the internet. I'm not asking for a network stack on the device — I'm asking whether the Envoy relay pattern you already ship, and already expose to third-party apps, could be generalised to a consented, allowlisted request/response.
The pattern already exists and is already third-party-grantable
There is no
net/httpAPI in the SDK (13 API crates:app-manager, backup, bt, camera, crypto, fs, gui-server, haptics, nfc, quantum-link, rgb-led, security, settings), andos/quantum-link's data messages are Foundation-only —PublishPsbt,SendAccountUpdate,SubscribeAccountUpdate,SendApplyPassphraseall carryrequiredSignature = "foundation", and the rest are ungrouped.But not all of them:
SubscribeExchangeRate(id 10)network-and-pairing.status-and-rates,autoAllowSubscribeExchangeRateHistory(id 29)network-and-pairing.status-and-rates,autoAllowSubscribeEnvoyStatus(id 12),SubscribeConnectionStatus(id 43)EnvoyTimezone(id 44)Exchange rates and timezone are internet-sourced data, fetched by Envoy, relayed over the pairing, and handed to third-party apps today. So the architecture — phone has connectivity, device consumes relayed data, third parties are allowed to receive some of it — is built, shipped, and already crosses the third-party boundary. What's missing is only that the set of retrievable things is a fixed list decided at firmware build time.
What I'd like
A relay message where the app names what it wants, within limits it declared up front:
permissionGroup+grantOnFirstUseconsent prompt naming the destinations, the same machinery as any other sensitive grant.Read-only (GET-shaped) would cover every use case I have, if that narrows the surface usefully.
Why it's worth the trouble
Today the only path for app data is a host CLI writing files to a USB drive or Airlock. For passport-nft-viewer that means a laptop runs
passport-nft-cli fetch --owner 0x… --out <drive>(Blockscout for the token list, IPFS/Arweave for images, resize, convert to.raw), then the drive is physically moved to the Passport. It works — that's the shipped design and I'm not blocked — but every refresh needs a computer and a cable, which puts a hard ceiling on what a third-party app can be.I'd also note this compounds with #15: with Airlock exclusivity, staging a bundle currently costs three physical interactions and two cable moves per iteration.
The obvious objection
A relay is a data channel out of the device, so it's a privacy and exfiltration surface — that's presumably why the current list is fixed. The mitigations I'd propose are the manifest allowlist (declared, reviewable, immutable after signing), an explicit consent prompt naming the hosts, and Envoy-mediation, since the phone already has connectivity and the pairing is already trusted for wallet data. But you own that trade-off, and if the answer is that the relay stays a curated list, a useful smaller version is simply letting third-party apps petition for additions to that list — a documented process beats guessing.
What I'm explicitly not asking for
Not sockets, not an on-device HTTP client, not a general network stack, and not access to the wallet-sync messages. Just the question of whether the existing relay can carry app-declared, user-consented requests as well as firmware-declared ones.