[Feature] Add optional signString() / sign_string method

[robwoodgate]

Feature description

Would be great if you would add support for PR: https://github.com/nostr-protocol/nips/pull/1842

The conversation contains a pseudo-code stub for the method and rationale for adding it.

Describe the solution

The PR above proposes a more Nostr-protective alternative to your signSchnorr method, which prevents events being signed 'via the back door', bypassing signer permissions.

As a leader in meeting the schnorr signing needs of Nostr users, would very much appreciate your support for this PR

Describe alternatives

No response

Additional context

No response

Are you working on this?

None

[reneaaron]

Thanks for your input!

The PR above proposes a more Nostr-protective alternative to your signSchnorr method, which prevents events being signed 'via the back door', bypassing signer permissions.

What do you mean exactly when you say "back door" and "bypassing signer permissions"? You will always be prompted for signSchnorr unless you gave the website permission to automatically sign in future.

I guess your concerns are more related to the fact that a user can't really judge WHAT exactly is being signed?

[robwoodgate]

I guess your concerns are more related to the fact that a user can't really judge WHAT exactly is being signed?

Yes, that's exactly it. The user sees only the hash to sign. Has no idea what is being hashed.

If the user has allowed permission for any message to be signed by the app/website, it could sign any Nostr event without asking user permission for that event.

For example, user might have request permissions for a NIP-98 (AUTH) event, but if they have allowed messages, the site could sign AUTH events as messages to avoid asking for that permission specifically.

[reneaaron]

If the user has allowed permission for any message to be signed by the app/website, it could sign any Nostr event without asking user permission for that event.

That would be the same with signString, wouldn't it? You would just need to pass an unsigned event, get the signature and add this signature to the event manually to build signed event. The only difference is that a user (if no auto-approve is set) could see content of the event being signed, right?

I agree that the API & displaying the hash is far from ideal, I can't comprehend yet why that has been implemented that way.

[robwoodgate]

That would be the same with signString, wouldn't it?

No. As specified, the signString method MUST NOT sign any message that is a valid stringified event.

The PR contains a stub method to show a possible implementation: https://github.com/nostr-protocol/nips/pull/1842#issuecomment-2738496549

Cheers Rob

[robwoodgate]

I agree that the API & displaying the hash is far from ideal, I can't comprehend yet why that has been implemented that way.

I suspect it was implemented that way to make it hash agnostic - eg: SHA256, SHA512, SHA1 etc

IMO, passing in a hash makes it potentially more dangerous: for example, could a user be fooled into signing a bitcoin transaction presented as an innocent Nostr event? Or perhaps a fat ZAP?

[reneaaron]

No. As specified, the signString method MUST NOT sign any message that is a valid stringified event.

Thanks for pointing that out, I must have missed that one.

IMO, passing in a hash makes it potentially more dangerous: for example, could a user be fooled into signing a bitcoin transaction presented as an innocent Nostr event? Or perhaps a fat ZAP?

It's impossible for a normal user to verify what is being signed, we defintely agree on that.

Two more questions:

1. What is the reason to include the pubkey & hash in the result compared to just returning the signature?

2. What are the use cases for this function currently? Nutzaps? Anything else that comes to mind?

[robwoodgate]

Two more questions:

1. What is the reason to include the pubkey & hash in the result compared to just returning the signature?
2. What are the use cases for this function currently? Nutzaps? Anything else that comes to mind?

1. For future flexibility, and to allow the receiving app to make any validation checks, eg:

• that the message signed was not tampered with (by checking hash against expected hash of message),
• that the signer was the expected user (by checking pubkey against expected).

2. The current use case is spending Cashu tokens that have been P2PK locked (NUT-11) to a Nostr NPUB. Both signSchnorr() and signString() are implemented in Nostrly Cashu Redeem.

[reneaaron]

1. That seems a bit redundant (and not consistent with existing APIs) to me. You can verify signatures against the pubkey, what would these newly introduced return values improve in that regard?

2. Cool, thanks for sharing!

[robwoodgate]

Many signers allow the user to switch profiles, so having the signer pubkey returned is a useful sanity check if the app is expecting a certain one to sign. And if you are receiving pubkey, it just makes sense to get the calculated hash too.

That way, the signer returns EVERYTHING needed to validate the message+signature in any conceivable circumstance.

It would be MORE redundant if an app made a comparitively "expensive" (time/resources) API call relying on a signature that wasn't ever going to validate the expected pubkey.

Example: in the signString() implementation of Nostrly CR, the app will ONLY witness the proof if the signer signed it from an account with the expected pubkey.

Example: at some point in the future, Nostr switches to SHA512. An app can see if the signer is still using SHA256 by comparing the hash returned against what they are expecting. Having the hash allows app to apply logic as needed (eg falling back to a SHA256 check).

Anyhow, the PR has one signer and at least one real world app implementation as specified, and one signer awaiting PR review.

If you guys would like to support the PR as specified too, it would be amazing.

Regardless, thanks for being the early supporter of non-event signing with signSchnorr().