The Bridge exposes a minimal RPC-like surface that developers can use to enumerate devices, request public keys, and forward signing requests to a connected Trezor device. The design emphasis is on clarity, small attack surface, and explicit user confirmation for every sensitive operation.
listDevices() -> [{id, vendorId, productId, path}]
getPublicKey(deviceId, path) -> {xpub, path}
signTransaction(deviceId, tx) -> {signatures}
verifyFirmwareSignature(image, signature) -> {valid: true/false}
Always present human readable transaction summaries to users. Never assume the browser will render the full content the device shows. Minimize the data you log and never include raw private data in logs or error reports. Provide clear UX fallbacks when devices are disconnected mid-flow.
Use signed installers and code signing for the bridge distribution channel. When designing integrations, version your API calls so that deprecated calls are easy to retire without breaking client apps. Encourage users to update device firmware before attempting sensitive operations.
For test harnesses, mock the bridge endpoints with deterministic responses and emulate the device confirmations in your QA flow. This reduces flakiness and makes automated pipelines easier to reason about.
1. App calls listDevices()
2. App shows a device list to user
3. App calls getPublicKey(selectedDevice, path)
4. App constructs a transaction and calls signTransaction(device, tx)
5. Device prompts user to verify details and confirm
6. App receives signatures and broadcasts transaction
Bridge implementations may differ slightly across OSes due to HID/USB stack differences. Keep cross-platform shims in your integration layer and test on each target platform. If you want a web-only experience, explore modern WebHID / WebUSB APIs where supported; otherwise rely on the bridge for consistent behavior.