Library name
@ledgerhq/wallet-cli
Describe your feature request
@ledgerhq/wallet-cli 1.0.2 registers the DMK transport over USB only (apps/wallet-cli/src/device/node-webusb, register-dmk-transport.ts). Flex and Stax are BLE first devices, and the main audience for a wallet CLI right now is agent and automation setups, where the host running the CLI usually does not have the device on a cable. The device stays next to the human, the agent runs on a server or a machine across the room.
I build an agent marketplace on Solana (AgenC) where agents settle real payments and the signer is a Flex over BLE on the DMK, so this exact flow runs in production for us, just not through wallet-cli yet. Things we hit in production that the BLE path needs to handle:
- one device session for the whole flow. Opening a second BLE session mid flow (one for app open, another for signing) leaves the channel busy and everything hangs after that
- auto open the target app from the dashboard through DMK, so the human only unlocks the device and never navigates menus
- machine readable error codes that distinguish device locked, app not open and BLE channel busy. An automation needs to decide between "ask the human to unlock" and "just retry", and today those cases look the same from the outside
Proposal: a --transport usb|ble flag, default usb so nothing changes for current users. The DMK already ships a BLE transport, so the bulk of the work is registering it plus the session handling above.
Happy to send the PR if there is interest. We already run this combination (DMK + BLE + Solana app auto open) in production and I would rather upstream it than keep it in our own stack.
Library name
@ledgerhq/wallet-cli
Describe your feature request
@ledgerhq/wallet-cli1.0.2 registers the DMK transport over USB only (apps/wallet-cli/src/device/node-webusb,register-dmk-transport.ts). Flex and Stax are BLE first devices, and the main audience for a wallet CLI right now is agent and automation setups, where the host running the CLI usually does not have the device on a cable. The device stays next to the human, the agent runs on a server or a machine across the room.I build an agent marketplace on Solana (AgenC) where agents settle real payments and the signer is a Flex over BLE on the DMK, so this exact flow runs in production for us, just not through wallet-cli yet. Things we hit in production that the BLE path needs to handle:
Proposal: a
--transport usb|bleflag, default usb so nothing changes for current users. The DMK already ships a BLE transport, so the bulk of the work is registering it plus the session handling above.Happy to send the PR if there is interest. We already run this combination (DMK + BLE + Solana app auto open) in production and I would rather upstream it than keep it in our own stack.