tyiu on Nostr: Yes. For example: 1. User drafts a kind 1 note in their favorite Nostr client and ...
Yes. For example:
1. User drafts a kind 1 note in their favorite Nostr client and taps “Post”.
2. Nostr client invokes the Share Sheet with parameters looking something like ["nostrsigner", "<nostr-client-name-plus-stable-uuid", "sign_event", "eventJSON"]
3. If the user has told the signer previously that it trusts the Nostr client to sign events of kind 1, then it’ll sign the event, not show any UI, and dismiss the share sheet.
4. If not, a UI will pop up asking the user to allow or deny the request, with an option to remember this preference for the future for this client.
4. Nostr client receives the completion callback with the signed event.
5. Nostr client publishes to relays.
This should work like an RPC call, and should work for other operations like get_pubkey, nip[04/44]_[encrypt/decrypt], and decrypt_zap_event.
I will be opening a PR to amend NIP-55 to support iOS signers soon once it’s a bit more fleshed out.
1. User drafts a kind 1 note in their favorite Nostr client and taps “Post”.
2. Nostr client invokes the Share Sheet with parameters looking something like ["nostrsigner", "<nostr-client-name-plus-stable-uuid", "sign_event", "eventJSON"]
3. If the user has told the signer previously that it trusts the Nostr client to sign events of kind 1, then it’ll sign the event, not show any UI, and dismiss the share sheet.
4. If not, a UI will pop up asking the user to allow or deny the request, with an option to remember this preference for the future for this client.
4. Nostr client receives the completion callback with the signed event.
5. Nostr client publishes to relays.
This should work like an RPC call, and should work for other operations like get_pubkey, nip[04/44]_[encrypt/decrypt], and decrypt_zap_event.
I will be opening a PR to amend NIP-55 to support iOS signers soon once it’s a bit more fleshed out.