First time sideloading one of my apps on the new beta!

Developers
1

Just got my first self-built app onto the Passport Prime running the new beta (1.4.0-beta1) — and the whole flow worked great. Developer mode → Allowed Publishers → add my publisher cert → Install App → app launches. Huge improvement, the sideload pipeline is solid.

Now I’m hitting the wall I expected, and I’d love the devs’ input on the intended path forward.

The setup: my app is a self-hosted Bitcoin cold-storage app (QXXX). It talks to my own relay server for balance/sync/broadcast. The relay protocol is already fully implemented on-device (auth handshake + ChaCha20-Poly1305 envelopes) — the only missing piece is the data pipe to the host.

The problem: I request os/bt SendBle / SubscribeBle (and EnableBle / GetBtAddr ) in my app manifest. foundation pack accepts them, the app builds and signs fine, the signed manifest includes them — but on-device the kernel returns AccessDenied because those messages have no permissionGroup (they’re ungrouped, so no Settings → Apps → Permissions entry is generated for third-party apps).

The precedent: I noticed the recently published passport-nostr-signer POC uses exactly this companion-channel pattern — a third-party app getting a wired data channel via os/usbdev ( RegisterInterface / ReadEndpoint / WriteEndpoint ) + WebUSB. So the mechanism already exists in the OS for third-party apps; it’s just exposed per-app.

Two possible ways to open this up for sideloaded apps — either would unblock us:

1. BLE: add a permissionGroup (e.g. device-connectivity.bluetooth-data , grantOnFirstUse ) to SendBle / SubscribeBle / EnableBle / GetBtAddr in the bt-server manifest → the Settings → Apps → Permissions toggle appears for users.

2. WebUSB: add a permissionGroup to the os/usbdev data messages ( RegisterInterface , ReadEndpoint , WriteEndpoint , WaitForConnection ) — same channel the nostr signer uses. (Also: the two PIO endpoint fixes the nostr signer documented look like they’re already in mainline — pending_rx queue + RxCompleteInterrupt — so no kernel changes needed there.)

Both are one-line-ish manifest edits and I’m happy to test whichever the team prefers (dev-unit firmware or the next beta). Is the permissionGroup mechanism the intended way for third-party apps to get a data channel, or is there a different recommended path?

Thanks for the great work on the beta — this sideload experience is the best it’s ever been.

image
image1920×2560 964 KB

2

Moved to the developer section @MikeGotBtc.

LOVE the enthusiasm and will have a member of the engineering team comment on the technicals here next week

3

Love the enthusiasm too !!! I will help you with your technical difficulties, give me some time to fully undertand your problem, I will be back soon, you are on my todo list :wink:

4

Hi Mike,

Thanks for the detailed write-up, and glad the sideload flow worked well for you.

I can’t offer you an immediate solution: the SDK is in its very first public release and it does not yet allow what you need. To answer your question directly, adding a permissionGroup to those messages is not the intended path for third-party apps to obtain a data channel. Here is what we do plan for the coming releases.

Bluetooth. On Prime, BLE is and will remain QuantumLink only. That is a firm assumption in our security model, so no other BLE communication will ever be possible. Today QuantumLink is limited to the Bitcoin and onboarding apps talking to Envoy, but we are actively working on extending it to other KeyOS apps and to other online services, including a relay server such as yours. That will land in a future KeyOS/SDK release and we will announce it.

USB. I am currently working on a vendor-specific interface designed to serve several applications at once. Third-party apps will be able to register a handler on it and use it too. We will announce that one as well.

This SDK release is a large feature and it will take time to mature and to accommodate many different needs without weakening the overall security of the device. As of today, I am sorry to say that the only way for a third-party KeyOS app to communicate with the outside world is QR code scanning. We know that is very limiting, and we have no intention of leaving it as the only option: as explained above, the other channels are in the works.

Thanks again for the thorough report and for the offer to test. We will get back to you when there is something to try.

5

Thanks for the detailed answer — that’s exactly what I needed to know. QR-only for now makes sense given the SDK maturity. Looking forward to both the QuantumLink extension and the USB vendor interface. Happy to test either when they’re ready.