actually I don't remember.
does the raw string normally make sense for a human?
Question nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcppemhxue69uhkummn9ekx7mp0qqsyv47lazt9h6ycp2fsw270khje5egjgsrdkrupjg27u796g7f5k0s0pfy4z - why does your signer take the sha256 hash as the input (sigHash), rather than the raw string to sign?
It would be better for people to SEE what they are signing for, instead of just a random hash string... the method could then hash for signing.
Discussion
Nostr events are always presented in raw form for signing, and I believe it is probably safer to present the raw string for signing too so user can be sure they are not signing something unintended or malicious that might lose them money (eg a bitcoin transaction)
eg, for a Cashu P2PK token, the raw string would be something like:
[\"P2PK\",{\"nonce\":\"859d4935c4907062a6297cf4e663e2835d90d97ecdd510745d32f6816323a41f\",\"data\":\"0249098aa8b9d2fbec49ff8598feb17b592b986e62319a4fa488a3dc36387157a7\",\"tags\":[[\"sigflag\",\"SIG_INPUTS\"]]}]
If I was drafting the method from scratch for NIP07/46, it would return all the data needed to do checks and verification on what was signed and who by eg:
async function signString(message: string) : {hash, sig, pubkey} // sha256 hash of message, Schnorr sig of hash, pubkey of signer
nostr:npub1xv8mzscll8vvy5rsdw7dcqtd2j268a6yupr6gzqh86f2ulhy9kkqmclk3x As you guys are leading the way on supporting Schnorr signing outside of the structure of Nostr events, I’d appreciate your thoughts on a “standard” method signature that is future proof which all signers could adopt… if we can convince fiatjaf to include as optional in NIP07/46… or adopt informally if not. As above, it might be better renamed to avoid issues with your established method.
The current iteration is mostly aligned with Alby existing except expects a raw message string.