Nostr

[ghost]

Should a hardware device support signing Nostr events? Definitely.

Should Krux? I think it could make sense (if you view Krux as firmware for hardware signing in general), but not in its current form due to all the Bitcoin-specific assumptions being made about wallets, receive addresses, PSBTs, etc.

The way I see it, there are 3 options:

1. Add support for Nostr in the existing UI, but wrap a bunch of places in if is_nostr() style checks to hide or show certain UI elements (e.g., Scan Address, Wallet, Sign PSBT, etc. don't make sense to show if using a Nostr key, and Show Nostr public key, Sign Nostr event don't make sense if using a Bitcoin key)
2. Fork Krux, rip out the Bitcoin stuff entirely, and focus the fork on being exclusively a Nostr signer
3. Don't fork Krux, but redesign it such that it can support different use cases or cryptocurrencies / elliptic curves.

Option 1, while it could work and is the "easiest" to do, would make the code harder to follow and maintain and begin to split Krux's focus. Not a fan of shoehorning it in like this.

Option 2 is a good short-term solution if people want something that works right now @odudex. Since my activity has dropped off the past few months, option 3 (my preference, see below) may take longer than desired to come to fruition; so I would be fine with a dedicated fork of Krux that focuses exclusively on Nostr if you want to take that up. (Of course, it's FOSS, so you can do what you want. Just giving my blessing :))

Option 3 is my long-term preference. I think there is a way we could eventually redesign Krux so that other users could write plugins for their preferred "crypto" (crypto in quotes since it could be a currency or something else entirely like Nostr) to customize the experience as needed for each one. The way I'm thinking it could be done would be similar to Ledger where the community can create their own "apps," only in this case the app would be in its own repo and would be selected + built into the firmware by the user. The existing Bitcoin "app" would be the default and is what I would continue to publish and sign as the official Krux release, but others could publish and sign the versions of Krux where the app is something else like Nostr, Ethereum, etc.

What do others think?

[ghost]

An assumption I realized I was making while typing that all up is that a user would EITHER be using their mnemonic for Bitcoin OR for Nostr, but not BOTH at the same time. If the latter is possible and something people do / are doing / want to do, then that makes a stronger case for option 1 since we wouldn't need to hide UI elements depending on the use case; it would just be yet another thing you can do with your Bitcoin mnemonic.

Is there any sort of emerging standard(s) here @odudex? I will admit I'm hesitant to dive into something so new and set a bad precedent for other, future hardware signer developers to have to follow. 💦

I did find this article after a cursory search: https://orangepill.dev/nostr-guides/guide-nostr-key-generation-and-management/

It seemed to suggest using BIP-85 to derive hardened child keys to use for signing. (BIP-85 might be good to implement in general)

[odudex]

I added the Nostr features in my tests binaries just for reckless testing, super early experimenting. It was not my intention to make it to the official release. I just did an air-gapped post and told others it was possible with krux. Later it was donne differently by others, but I'm not involved neither studied these NIPs standards, still being created.
Since major nostr clients still don't offer air gapped signing, I think there's no reason to add it now on a official release. Specially the lazy way I did.
I let it in last PR because I didn't have time to separate it from other things, and I didn't want to miss the opportunity of having you active on the project.
To be honest, I don't know anyone but me that used it.
If we were selling something or asking for donations, it could be profitable hype, but it's not the case😁
So for now I would let my nostr tests just as an early brainstorm idea, that can go on and be tested on separated branches and forks. Would still focus on Bitcoin only for next official releases.