add onekey device support #709
Conversation
|
A GHA run in my repo: https://github.com/OneKeyHQ/HWI/actions/runs/6212074159 |
|
@achow101 Please take care of this. Thxs |
somebodyLi
force-pushed
the
gha
branch
4 times, most recently
from
4cf3346 to
d7df45f
Compare
|
the newest passed GHA https://github.com/OneKeyHQ/HWI/actions/runs/7110790185 |
|
Hello @achow101, we are still waiting to merge this PR, we have already rebased to latest commit and addressed questions and issues above. Could you kindly reveiw again base on our latest commit? |
|
Can you please rebase it? |
somebodyLi
force-pushed
the
gha
branch
2 times, most recently
from
cdf99d9 to
e4ac963
Compare
Of course, But there seems to be a problem with the simulator's compilation dependency installation |
|
Please squash your commits. |
|
Looking at the code, it seems this PR is not adding anything substantial. The Onekey devices are just clones of Trezor One and Trezor Model T. They even copied the internal names (T1B1 and T2T1). I am not sure it is really worth complicating the codebase and risking rendering of Trezor (and all its clones) support unusable (this PR modifies trezorlib too). Since Onekey tries to be compatible with Trezor (their FAQ mentions "support all third-party clients supported by Trezor"), maybe we should not change HWI at all and let Onekey be detected as Trezor via HWI? |
somebodyLi
force-pushed
the
gha
branch
2 times, most recently
from
b6978af to
6847858
Compare
Done! |
OneKey Touch/Pro are using different MCU and SE than Trezor T/One, which means hardware and low-level codes are totally different. We also designed and built our own GUI since the screen resolution is different, and we have no interest to have GUI looks the same. OneKey firmware was forked from Trezor, but I don't think building on top of a fork should count as a counterfeit, that's not how open-source projects work. Many great projects were based on a fork.
Due to the nature of initially forked from Trezor, our protocol is compatible with Trezor. However, it does not work the other way around, since OneKey has many things Trezor does not support. This is why we need a separate implementation to fully support our device, and adding OneKey support to HWI is the first step.
Introducing fewer changes possible was suggested by @achow101. Ideally, we want a separate library path. |
Hi @prusnak I totally understand your worries. I'm a big fan of Trezor—my very first hardware wallet was a Trezor back in 2014. Yes, a lot of OneKey's firmware was indeed developed on the shoulders of Trezor. We strictly followed Trezor's open-source license and had no intentions beyond that. It’s worth mentioning that all of OneKey’s app code is completely open-source. We do have plans to fully rebuild our firmware using the RTOS architecture, but that's going to take some time. To draw an analogy, if Trezor is like Google, then OneKey would be like Xiaomi. Sundar Pichai doesn't mind other manufacturers using Android's code in an open-source manner, because it actually helps Google solidify its position and market share in mobile operating systems. Similarly, I believe OneKey genuinely helps promote Trezor’s communication standards, which is beneficial for Trezor. And let’s be honest—there's a big, annoying elephant in the room. That’s the one we really need to aim to surpass, right? |
No description provided.