📅 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
Thomas Daede [ARCHIVE] /
npub1vj…3qpuy
2023-06-07 17:52:53
in reply to nevent1q…nwzf
Author Public Key
npub1vjlv5yhutdz826l4nqyrc9v72wjzp0d3j48y7d429fkh9xquew4sx3qpuyPublished at
2023-06-07 17:52:53Event JSON
{
"id": "6bfabb2af6666f2d7bb2235914cd8aff56a10596df219e7567ea73beb4858a73",
"pubkey": "64beca12fc5b44756bf598083c159e53a420bdb1954e4f36aa2a6d72981ccbab",
"created_at": 1686160373,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"a763067d031fa39ca8f7a3c1c5293e3b4f206caa1398de88916a3e73907d5ee5",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-08-16\n📝 Original message:On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote:\n\u003e It would be best if the hardware protocol were standardised, so the user \n\u003e doesn't need a plugin of *any* sort... I notice some hardware wallets have \n\u003e begun to implement (or reuse) Trezor's interface, so that would seem a good \n\u003e place to start?\n\nI also agree with this - the user experience would be a lot better\nwithout the need to install custom adapter software, especially for the\ndesktop case.\n\nThere could be two layers to the specification - the raw messages that\nneed to be passed, and the transport mechanism to pass them (USB HID, QR\ncode, audio...). For the most common case (USB), both layers could be\ndefined, and other transports could be added later. This split already\nexists in the draft specification, though it's not very clear (URIs\ninclude return URIs that don't make sense for a pipe, for example).\n\nThe existing URI scheme, while allowing disambiguate by manufacturer,\nprovides no way to to enumerate available manufacturers or enabled\nwallets. This means that the \"driver\" would have to include a GUI to\nselect this. Also, passing return URIs seems rather fragile - are there\nany other examples of protocols that use URIs for bidirectional IPC?\n\nThomas",
"sig": "09cfaed193f8b75ad3916d37b575591b7f85d293e69133fd80d91ec9480977b342aa302fdbac87712b910e376344760b7a231ca29c45e7ac77d9cad67aa3cd6e"
}