-
Notifications
You must be signed in to change notification settings - Fork 9
Comparing trezor.js and trezor connect
None of these libraries use node-hid (or any dependency whose name contain 'hid'). I can be sure of that because I just grep occurencies of 'hid' in package.json file and don't find any.
In short it means they don't natively support talking to a usb device, they need to talk a daemon that do the low level work for them.
They both have a dependancy to trezor-link.
trezor-link implements functions to create a trezor message from a google protobuf javascript structure. It is able to call a "sender" to send the buffer to the device. But apparently it does not use any usb library to send the buffer to the device.
Neither do connect and trezor.js.
These three libraries are designed as a tool to build webapps connecting trezor devices, they all assume they are being run in a web browser (especially trezor-connect) and try to use the browser's WebUsb plugin.
For more information about WebUsb check here: https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
See also : https://wicg.github.io/webusb/#introduction
Historically trezor.js was a node-hid based API but they switched to that daemon based architecture because they met issues with node-hid on windows.
The trezor.js README.md file says: "Trezor used to work with node HID API directly, but the binary API and the various node versions got too hard to manage, so we removed them."
Now trezor.js expects a trezord daemon to be running: "Trezor.js should be possible to use from node.js if the user has Trezor Bridge installed".
Trezor bridge is a golang daemon in charge of the interface with the device.
Trezor project used to function with trezor.js repository until they deprecated it for trezor-connect.
It is possible to run example.js with node.js. It works only if trezord is running on the machine otherwise it complains it cannot connect to "https://localback.net:21324".
If the daemon is running it is a sort of application able to react on device connecting and disconnecting and run a few tests.
Trezor.js gave up on using node-hid as mentioned in this thread.
They also try to move towards more "WebUsb" and remove the need for "Trezor Bridge" for the reasons mentioned there: https://github.com/trezor/trezor-mcu/pull/260
It does not run on a node.js application because it is looking for a 'navigator'. Here is the error you get when you try:
supportedBrowser: !/Trident|MSIE/.test(navigator.userAgent),
Trezor connect is meant to be a piece of code that any website can plug into their source code so they connect to a trezor device. You can see a presentation of trezor connect there: https://doc.satoshilabs.com/trezor-tech/api-connect.html
As a result it takes a bit more work to use Connect.
- First step is to run trezord Daemon
- We need to serve a html file which includes this statement:
<script src="https://connect.trezor.io/5/trezor-connect.js"></script>
For our concern the github main repository is here.
And more specifically the repository for the javascript API is hw-transport-node-hid.
Good news is it is very simple and has just one dependancy: hw-transport which is also very small.
The trezor equivalent for these two repositories may be trezor-link, they have in common that they are very low level. But ledger's hw-transport repository implements a node-hid interface and it looks like they cared about windows compatibility.
It is also interesting to have a look at how did they articulate it with a javascript command line interface (cli) on hw-hid-cli repository.
For skycoin needs the repo we are going to fork to create our javascript application depend what we want to do.
If we need to create a "full stack" webapp with GUI, trezor connect would be a start. The work will then consist in changing the html files. Understanding how the low level functions from trezor-link are used and plug in our messages.
This however requires we make a choice about how are we going to access our usb device. For a "straight" usb talk we could use node-hid but apparently there may be issues for windows users.
We can also consider using google chrome's WebUsb pluging like trezor does, but for now it may not be supported on other web browsers, moreover WebUsb can also be disabled on chrome browser. Trezor address this issue by asking users to install "Trezor bridge" which is the official name for "trezord daemon".
There is a dialog between "Trezor bridge" and "Trezor connect" webapp that can trigger events on webapp side (example of event: device connected).
Trezor.js appears to be more handy to hack than trezor-connect, it does not have a "native dependancy to node-hid" which means it still requires a running Trezor Bridge to talk to the device.
If we check on repository's history though we migth find a point in time were they used to use node-hid to dialog with the device without depending on trezor bridge for that. However I did not test that, this is not certain.
Trezor.js implements the "code examples" necessary to use the lower level trezor-link. It is event driven programming, it can wake up when a device is connected and can manage many connected devices.
Trezor-link deals with low level interaction with the device using the interface LowlevelTransportPlugin. If we are able to pass a class implementing this interface to trezor-link we may be able to access the usb device without too much hacking.
I did not test it but it has also the necessary code to dialog with WebUsb.
Hardware-wallet-js went "straight to the point" to dialog with a skycoin device. It was tested and works on linux ubuntu at least. It is small and we master fully this code.
Main problem is it do not manage "multi connected devices", but it could be improved by picking up the code we need from trezor.js.
It strongly depends on node-hid, so we need to check node-hid can work everywhere we need it.
The code they wrote there looks easy and we could get inspiration from it. We made our messasing system using google protobuf like trezor did. Which means there is a bit of work to "hack this code" in order to make it work for our need. But given how simple the code base is that is "affordable".
My opinion there is that we can copy paste some code from there to improve our low level interface without explicitely forking the repository.
- Manual
- How to check whether device is genuine
- Initialize the wallet setting up
- Getting to know the wallet
- Update firmware
- Restore configuration
- Backup your seed
- Test your seed (Dry run)
- Optimize account security
- Send and receive crypto assets
- Wiping a Skywallet
- Remove Skywallet from wallet list
- Rename a Skywallet
- If transaction is too large
- Check the firmware version
- Manage the PIN code
- Troubleshooting
- Not yet implemented future features