Avatar
DanConwayDev 1y ago

I have a CLI (ngit) that is usually used to read but sometimes used to write events.

I'm trying add support for relays that require AUTH to read.

If nip46 a bunker url is known and have previously been used to successfully sign event, I would like to opportunistically use it to respond to AUTH events.

I don't want to await the return of Nip46Signer:new() before sending read requests and I'd like a shorter timeout (or the connection attempts to be stopped when the client falls out of scope)

so that my CLI can close when other operations are complete.

Later, if the CLI needs to sign user generated events, it will attempt to connect to the remote signer again (if not already connected) and this time would need a longer timeout for connecting to the remote helper as provided through Nip46Signer:new() .

Reply to this note

Please Login to reply.

Discussion

Avatar
Yuki Kishimoto 1y ago

I reworked it, now it's always on demand (commit 4dbfa94876b136869e2feea75288f0c6a0beaa0e).

Avatar
Yuki Kishimoto 1y ago

I removed the connection timeout (was set to 10 secs) so from 4dbfa94876b136869e2feea75288f0c6a0beaa0e commit the timeout is used only for requests.

Avatar
DanConwayDev 1y ago

perfect thanks

Avatar
DanConwayDev 1y ago

nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet, I'm reopening this because whilst `Nip46Signer::new` is not blocking, `NostrSigner::nip46` is. When a nip46 signer is not connected (or not automatically responding) the utility will hang until the signer is connected. this is true of `4dbfa94` but I'm not sure if you have tweaked it since.

Avatar
Yuki Kishimoto 1y ago

The `NostrSigner::nip46` internally only construct the `NostrSigner` enumeration.

At a certain point the `Nip46Signer` have to wait for a response from the signer. Can you point me where you use it in the code?

Avatar
DanConwayDev 1y ago

I'm using it here:

https://github.com/DanConwayDev/ngit-cli/blob/4f84dc460c3494286233afe9ca480d3b7c0186b1/src/lib/login/mod.rs#L294 (main branch)

https://github.com/DanConwayDev/ngit-cli/blob/e60a419510696e3fa25a35be6cba35e547b53e24/src/lib/login/mod.rs#L293 (testing-auth-with-patched-signer branch)

The main branch doesn't block when attempting to login but the patched signer branch does.

I would prefer it if it only sent a request to the signer when it has been explicitly called to sign an event. If an AUTH request is received it should attempt to sign it but do this async in the background and not block. What do you think?

Avatar
Yuki Kishimoto 1y ago

Ok, maybe I found the issue. The connection with signer is already initialized on demand. But, the bootstrap is executed when `signer_public_key` method is called... I saw that in your code you are calling the `NostrSigner::public_key` method, that internally call the `signer_public_key` method. For this reason it block.

I'll rework it

Avatar
Yuki Kishimoto 1y ago

Try this commit: ede2a91ef7d3738b36a03243697fbd20efd335a1

Avatar
DanConwayDev 1y ago

That no longer blocks! Thanks. How are AUTH requests handled in this nip46 signer scenario?

Avatar
Yuki Kishimoto 1y ago

It's sent a `sign_event` request to the signer.

Avatar
Yuki Kishimoto 1y ago

In general the AUTH requests are handled in another thread, so will not block the main one.

Avatar
Yuki Kishimoto 1y ago

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.

Avatar
DanConwayDev 1y ago

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.

Avatar
Yuki Kishimoto 1y ago

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.

Avatar
DanConwayDev 1y ago

Ok, ill check it out but it looks like I have some refactoring to do now that NostrSigner is now a dynamic trait.

Avatar
brugeman 1y ago

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

Avatar
Yuki Kishimoto 1y ago

Thanks!

Avatar
DanConwayDev 1y ago

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

Avatar
DanConwayDev 1y ago

I'm quite frequently getting the following error when trying to sign events with the remote signer, whereas I do not get this under rust-nostr v0.35.0 :

`Error: failed to sign event

Caused by:

not subscribed`

Avatar
Yuki Kishimoto 1y ago

Thanks, I'll investigate.

Avatar
Yuki Kishimoto 1y ago

The `not subscribed` error is returned when subscription fails with all relays. What relays are you using? Maybe is related to NIP42 auth

Avatar
Yuki Kishimoto 1y ago

No, my bad. The subscription can fail only if relay not support read operations, if the filter is empty or for timeout. In the log what do you see when it fail and return `not subscribed`?

Avatar
Yuki Kishimoto 1y ago

Found the issue, tomorrow I'll push the fix.

Avatar
Yuki Kishimoto 1y ago

Fixed at 7587fba8ee72041689aa46c1436ecfa73d75d381