Thomas Daede [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-16 📝 Original message:On 08/16/2016 12:22 PM, ...
📅 Original date posted:2016-08-16
📝 Original message:On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote:
> It would be best if the hardware protocol were standardised, so the user
> doesn't need a plugin of *any* sort... I notice some hardware wallets have
> begun to implement (or reuse) Trezor's interface, so that would seem a good
> place to start?
I also agree with this - the user experience would be a lot better
without the need to install custom adapter software, especially for the
desktop case.
There could be two layers to the specification - the raw messages that
need to be passed, and the transport mechanism to pass them (USB HID, QR
code, audio...). For the most common case (USB), both layers could be
defined, and other transports could be added later. This split already
exists in the draft specification, though it's not very clear (URIs
include return URIs that don't make sense for a pipe, for example).
The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets. This means that the "driver" would have to include a GUI to
select this. Also, passing return URIs seems rather fragile - are there
any other examples of protocols that use URIs for bidirectional IPC?
Thomas
📝 Original message:On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote:
> It would be best if the hardware protocol were standardised, so the user
> doesn't need a plugin of *any* sort... I notice some hardware wallets have
> begun to implement (or reuse) Trezor's interface, so that would seem a good
> place to start?
I also agree with this - the user experience would be a lot better
without the need to install custom adapter software, especially for the
desktop case.
There could be two layers to the specification - the raw messages that
need to be passed, and the transport mechanism to pass them (USB HID, QR
code, audio...). For the most common case (USB), both layers could be
defined, and other transports could be added later. This split already
exists in the draft specification, though it's not very clear (URIs
include return URIs that don't make sense for a pipe, for example).
The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets. This means that the "driver" would have to include a GUI to
select this. Also, passing return URIs seems rather fragile - are there
any other examples of protocols that use URIs for bidirectional IPC?
Thomas