The new update to nostr-signing-device has support for multiple nsecs and a bunch of other cool stuff
PR https://github.com/lnbits/nostr-signing-device/pull/19 by nostr:npub1794vv7hl7y6q2qw0y7m7h60rpphmvt5h7pzt5sr78z6assj6w0eqagwjhd
-- This note was signed using nostr-signing-device
Isn’t this the same what nostr:npub1tv8gmfhalwnxxquxjzeh6gtdsdz6vg7vx0s3rt7s7uuw6aujh32qn77wn2 proposed back in the days ?
also added a "migrate to device" option under the account settings in noStrudel... because why not?
Nice, are you using the new /add-key endpoint which supports hex and bech32 or the legacy /restore ?
Command, not endpoint. You know what I mean.
using the /restore command, I didn't know there where new commands
could there be one to ask the device to switch pubkeys?
Oh there’s a few 😄 if you’ve git cloned from the PR, there should be a folder called configure with a config html file. Ignore the pin section because I forgot to remove that (pin is now on device only), but it has all the endpoints and a brief description.
Dang this looks awesome
I need to update it to be honest, it was one I flung together for testing. Forgot to remove it from my project before raising the PR, left it since it might be useful to someone.
Some feedback though. pubkey and secret keys should always be in hex format, there isn't really a point in using npub / nsec since it just increases the overhead (complexity) for parsing and serializing
If we want other apps to use the commands then it will be twice as hard if they need to test every key to see what format its in
It supports both, it first checks if it’s a valid hex char set and length, if it’s not it tries to parse the bech32 if it’s a valid nsec. Or do you mean on the list-keys ?
mainly the /list-keys but IMO a signing device should be even know about bech32 encoding
I was thinking mainly from a user experience point of view as most clients use npub etc, knowing which key is which hex could become a bit of a faff so switching keys in the format they’re used to would make sense. Easy tweak though 👍
If the client is built correctly the user will never see the hex format. The device should still show the bech32 npub on the screen though. since that's a lot more use-friendly
I'm sorry to keep talking about this, but its not good to mix hex / bech32. hex should be used for all internal values and bech32 for all user-facing display values. mixing the two in either the internal or UI layer just creates more complexity
All internal on the device just works with hex, ui uses a format function to present in bech32 on the screen. I’ll amend the commands to use hex only.
nostr:npub1dqepr0g4t3ahvnjtnxazvws4rkqjpxl854n29wcew8wph0fmw90qlsmmgt do you want me to wait until the existing PR is reviewed or raise a commit on the current to tweak this?
Amended the code to only use hex on commands (list key, encrypt, decrypt etc), also updated the config tool to include all new commands and parameters.
Will commit once nostr:npub1dqepr0g4t3ahvnjtnxazvws4rkqjpxl854n29wcew8wph0fmw90qlsmmgt lets me know how I should manage it with the existing PR 👍
Thanks for the feedback, appreciated.
my relay uses a SIMD accelerated hex codec as well called xxhex, but i'm not sure checking for npub/nsec at the front is that much overhead, maybe for slow things like javascript and python tho
Is this something you put together yourself or are these commercially available?
Um… no.
They’re available commercially on LNbits, I just upgraded the firmware 😁
