Oddbean new post about login | logout That no longer blocks! Thanks. How are AUTH requests handled in this nip46 signer scenario?
It's sent a `sign_event` request to the signer.
In general the AUTH requests are handled in another thread, so will not block the main one.
According to new NIP-46 clarifications, the remote signer public key could be different from the user public key. So I have to adjust it again. This means that if you'll call `NostrSigner::public_key` method with a NIP46 signer, it will block until the signer reply or the timeout is reached. After the first call is executed correctly, the pk is cached.
Is that so the events on the signer relay doesnt reveal the user pubkey? So is NostrSigner::pubic_key the signer pubkey or the user pubkey? I cache the user pubkey locally so I'd like to optionally supply this (any the signer pubkey if i need to store this too) to prevent blocking if reusing the signer info. If the user info gets changed I'd like it to error when signing.
In new version (for now in master branch) `NostrSigner::public_key` return the user public key. In the last release depends by the signer, but during my tests I saw that the same key is used (so the signer key match the user one), at least in amber and nsec.app.
Ok, ill check it out but it looks like I have some refactoring to do now that NostrSigner is now a dynamic trait.
Please also check part 2 of the last upgrade, might be easier to read and add some clarifications: https://github.com/nostr-protocol/nips/pull/1553
Thanks!
I'm finding that with v36 `NostrConnect::new()` is blocking until the remote signer responds to a request for the public key.
```
let signer = Arc::new(NostrConnect::new(
uri,
nostr::Keys::from_str(app_key).context("invalid app key")?,
Duration::from_secs(10 * 60),
None,
)?);
```
https://github.com/DanConwayDev/ngit-cli/blob/30f1a3efa9265b1403a7aa68fffbd65291face3d/src/lib/login/mod.rs#L294 I realised that it was blocking elsewhere. But it would be save a trip if I could supply the user public key if it was known to prevent this from becoming blocking.
I've added `NostrConnect::set_user_public_key` at commit ce05916f4acef2351e6ab648e4e7296a6d10f8d9
thanks. I've suggested so `bootstrap` shouldn't fail after `set_user_public_key` is called. nostr:nevent1qvzqqqqx2ypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmwdaehgu3wdau8gu3wv3jhvtcpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhszyrhwden5te0dehhxarj9ekk7mf0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg4waehxw309aex2mrp0yhxummnw3ezucn89uq32amnwvaz7tmwdaehgu3wdau8gu3wv3jhvtcppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq32amnwvaz7tmjv4kxz7fwdehhxarj9e3xwtcpzpmhxue69uhkummnw3ezumt0d5hsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqypm7gc6n3cj87283gv63pxv0ce7ax0lh7lh98mk8g5lr2xkgy6jszyc3gk3