Feature request: Ability to reuse bunker URL for remote signers

[aaccioly]

Nak already supports signing events by providing a bunker connection token.

https://github.com/fiatjaf/nak/?tab=readme-ov-file#sign-an-event-using-a-remote-nip-46-bunker

However, at least when using it with a token generated by Amber, nak only works once.Afterwards, using the same token as a parameter for --sec returns an error stating that Nak is already connected.

Ideally, Nak should not error out. It should "remember" the signer credentials (e.g. via a file or environment variable) and allow the user to run multiple operations in a row with the same signer/connection token.

It would be great if there were an equivalent to the NOSTR_SECRET_KEY environment variable for remote signers (e.g., NOSTR_NIP46_TOKEN) that users could set once, just like they do with Nostr clients.

Moonshot Ask 1

It would be nice if Nak could also generate its own nostrconnect token and display it with a QR code à la ngit.

Moonshot Ask 2

Multiple bunker tokens (for different npubs)

It would be brilliant if I could pass a list of multiple bunker tokens (for different pubkeys) and then select which "profile" I want to use to sign a specific event (e.g. by npub).

Example:

export NOSTR_NIP46_TOKENS="bunker://<remote-signer-pubkey1-url>;bunker://<remote-signer-pubkey2-url>"

Then allow users to select which key to use for signing via the remote signer or user pubkey/npub.

Example:

nak event --sec <pubkey1> -c 'Posting as user 1' nos.lol
nak event --sec <pubkey2> -c 'Posting as user 2' nos.lol
nak event -c 'Posting as user 1 again' # Defaults to first token

[fiatjaf]

What do you mean by "token"?

There are many parts to making the bunker stuff. One is the "client key", which is the key the bunker uses to communicate with the relays. You can set that with the $NOSTR_CLIENT_KEY environment variable.

Other things are "secrets" and "authorized pubkeys". These can be passed as parameters, but the current interface isn't the best because they have to be specified manually on every restart. Eventually I'm planning to move to a file-based approach, but I'm still not sure how to do that given that you should also be supposed to launch multiple bunkers for different keys at any random times.

[aaccioly]

What do you mean by "token"?

I was thinking of the whole bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>as a token. I don't know if this is the current interpretation of token as per NIP-46:

https://github.com/nostr-protocol/nips/blob/master/46.md#direct-connection-initiated-by-remote-signer

I guess that the crucial feature for me would to be able to use a remote signer without generating new nsecbunkers manually on Amber so often. I'm a bit NOSTR_CLIENT_KEY that you mentioned. Are you saying that if I first

nak event --sec 'bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>'-c 'Posting as user 1' nos.lol

And then:

export NOSTR_CLIENT_KEY="<remote-signer-pubkey>"

nak will be able to use the signer without --sec + passing a whole new bunker connection string as parameter every time? If not, can you ELI5 what is currently possible (even if with a single key / signer pair)? Many thanks in advance.

[fiatjaf]

What I personally do:

1. hardcode a $NOSTR_CLIENT_KEY in my shell so it's always the same
2. start a bunker with nak bunker --sec ncryptsec1... <relay> <relay>
3. it shows a URL, which I paste in random apps
4. if I think I'll continue to use that app -- for example, Coracle -- I copy the "authorized key" corresponding to that app and restart the bunker with nak bunker --sec ncryptsec1... -k <key-for-coracle-here> <relay> <relay> -- I don't need to restart he bunker like this but this is just so it's saved in the shell history
5. every time I want to try a new app I take the last URL printed by the bunker process and use it there (it comes with a new "secret")
6. if I don't think I'll continue to use that app all the time I don't bother restarting and I just forget about that app's authorized key (it will vanish the next time I have to restart the bunker anyway)
7. the next time I have to reboot my computer or something I restart the bunker with the last used command that contains all the -k arguments from previously authorized apps

[aaccioly]

Hey fiatjaf, thanks for the delayed instructions. This works very well! And I'm beyond impressed by nak features,

Unfortunately, having the bunker in the CLI isn't convenient for folks that mostly use mobile clients like me.
What I would like to do is to be able to generate a few bunker urls with Amber and basically alternate between then.

nak already works perfectly for a single pubkey, e.g., you can do something like this:

nak event --sec 'bunker://<remote-signer-pubkey1>?relay=<wss://rerelay>&secret=secret-value>' -c 'Posting as user 1' nos.lol
nak event --sec 'remote-signer-pubkey1' -c 'Posting again as user 1' nos.lol

You can also start posting with another user the same way

nak event --sec 'bunker://<remote-signer-pubkey2>?relay=<wss://rerelay>&secret=secret-value>' -c 'Posting as user 2' nos.lol
nak event --sec 'remote-signer-pubkey2' -c 'Posting again as user 2' nos.lol

The problem is that after doing this, nak won't allow me to post as user 1 again without creating a new bunker url, i.e., this doesn't work.

nak event --sec 'remote-signer-pubkey1' -c 'Posting again as user 1' nos.lol

The core of my ask is for nak to "remember" the credentials for remote-signer-pubkey1 and remote-signer-pubkey2 so that I can alternate users without creating new bunker urls every time, hopefully this makes sense.

[fiatjaf]

The problem is that after doing this, nak won't allow me to post as user 1 again without creating a new bunker url, i.e., this doesn't work.

nak event --sec 'remote-signer-pubkey1' -c 'Posting again as user 1' nos.lol

The core of my ask is for nak to "remember" the credentials for remote-signer-pubkey1 and remote-signer-pubkey2 so that I can alternate users without creating new bunker urls every time, hopefully this makes sense.

No, it doesn't make sense. I don't understand it at all. nak doesn't allow you to do that? It should definitely allow you to do that. Does it crash or something?

[fiatjaf]

Wait, I think I understand what you're saying. Amber doesn't like when you use the same bunker "token" twice on nak. Is that it?

That's because when connecting to a bunker nak (or any client) will generate a "client key" to use when communicating with the bunker. The bunker (Amber, in this case) will store that "client pubkey" and mark it as authorized.

But then if you run it again, because nak doesn't have a persistent database it doesn't store the "client key", so it will create a new one, and Amber will reject that one.

The way to fix this on nak is to do this step:

1. hardcode a $NOSTR_CLIENT_KEY in my shell so it's always the same

[aaccioly]

Sorta. My main problem here is that I have several different accounts on Amber.

I.e., npub1a6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajq7w0tyc and npub17lhksy5s3mrc09pw23653vt2v3u35mj3rdqxpe0h0spt23mve9fs3mhy5j. I need to alternate between accounts for testing purposes without passing my nsec as a command line argument or storing it as an environment variable. But thinking about what you said above, I guess that I could create a few functions like thr ones bellow. Not ideal but I think it does the job.

nak1() {
  NOSTR_CLIENT_KEY=xxx nak --sec 'bunker-url-1' "$@"
}

nak2() {
  NOSTR_CLIENT_KEY=yyy nak --sec 'bunker-url-2' "$@"
}

Can NOSTR_CLIENT_KEY be any random key? What's the expected format, just a regular pubkey style hex? (E.g., 288903febd2084e513f46b83ce1358b7d054b4c27d7d4618c6df69d13b96f642)

[fiatjaf]

I'm pretty sure you can use the same NOSTR_CLIENT_KEY for all your Amber accounts, so no need to do these functions unless Amber is doing something very unexpected. Did you try it?

But yes, NOSTR_CLIENT_KEY is just a regular secret key in hex style.

[aaccioly]

I'll play around with it later today. I thought I tried this before but I may have screwed the client key format.

Thanks for the patience Fiatjaf.

PS: An interesting idea would be to somehow derive a consistent client key from the bunker URL when it's not passed explicitly. Or even generate and store a specific client key during the first run (while still allowing the user to override it). It would be good to document this as well.
Happy to work on it if you think it can be useful to other folks.

[fiatjaf]

How do we derive a consistent client key such that it is different for each machine? I don't think this is possible.

I guess the simplest way would be to save it in a file somewhere but when I did this I was thinking it would be a stateless oneshot thing. I may need to introduce that file at some point.

[aaccioly]

How do we derive a consistent client key such that it is different for each machine? I don't think this is possible.

I have to think about this one, but you can hash the bunker url + "unique enough info", e.g. CPUID, MAC address, etc. Then we extract the bits from the hash. I don't think that anything will be 100% foolproof, if we try to hash too many things the hash won't really be consistent. But we'll, if it is good enough for big tech to fingerprint users it should be good enough to generate "unique" private keys.
Or if having different keys per bunker url isn't a requirement then nak can just generate a random key and persiat it somewhere, which is what I'm assuming most clients are doing.

I guess the simplest way would be to save it in a file somewhere but when I did this I was thinking it would be a stateless oneshot thing. I may need to introduce that file at some point.

Yes, that was my original idea. Maybe something in .config. Nak automatically generates the file with a random key if one doesn't exist, otherwise it uses the key in the configuration file (or the environment variable if it has been set).

[aaccioly]

I'm pretty sure you can use the same NOSTR_CLIENT_KEY for all your Amber accounts, so no need to do these functions unless Amber is doing something very unexpected. Did you try it?

But yes, NOSTR_CLIENT_KEY is just a regular secret key in hex style.

Unfortunately it's not working. First message for each profile is sent correctly, after the first message nak gets stuck after <name-of-the-relay> ok and never publishes the event. E.g.:

export NOSTR_CLIENT_KEY=\"$(nak key generate)\"
❯ nak event --sec 'bunker://ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64?relay=wss://relay.nsec.app&secret=xxxxx" -k 1 -c 'Attempt number 33445 to make multikey nak work with Amber - now without hardcoded NOSTR_CLIENT_KEY' haven.accioly.social
haven.accioly.social... ok.
{"kind":1,"id":"d908ce4316fee0c06a93bb790ca2075343f53e1b671c19bf0649c0faea74d6c8","pubkey":"ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64","created_at":1750375587,"tags":[],"content":"Attempt number 33445 to make multikey nak work with Amber - now without hardcoded NOSTR_CLIENT_KEY","sig":"6a38dc641945425c16e87657f83a08032eec3ce0d686d11a07a78c93e0385c97e24cfa7c1e28262088b87ca73fdca517aac0afa283294fe4e0db4f8860c01072"}
publishing to haven.accioly.social... success.
❯ nak event --sec 'bunker://f7ef6812908ec787942e547548b16a64791a6e511b4060e5f77c02b5476cc953?relay=wss://relay.nsec.app&secret=yyyyyyy' -k 1 -c 'Commenting with other profile' -t 'e=d908ce4316fee0c06a93bb790ca2075343f53e1b671c19bf0649c0faea74d6c8;;root;ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64' -t 'p=ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64' nos.lol
nos.lol... ok.
{"kind":1,"id":"8e9d93feae6f87cfe320bcb24400ac253d6839fa46020bec3305f348ba7ed581","pubkey":"f7ef6812908ec787942e547548b16a64791a6e511b4060e5f77c02b5476cc953","created_at":1750375758,"tags":[["e","d908ce4316fee0c06a93bb790ca2075343f53e1b671c19bf0649c0faea74d6c8","","root","ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64"],["p","ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64"]],"content":"Commenting with other profile","sig":"edf73aa140c2ce39a559d2b3486da6b1fbf61bff2f13092133ddb2204466a61d1197345de9ec6ca5b1ccd1e55a06408fbd4a34b9e3329eb3a84f81f06c4b4c89"}
publishing to nos.lol... success.

❯ nak event --sec 'bunker://ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64?relay=wss://relay.nsec.app&secret=xxxxx' -k 1 -c 'And commenting yet again with original profile using nak1 function' -t 'e=d908ce4316fee0c06a93bb790ca2075343f53e1b671c19bf0649c0faea74d6c8;;root;ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64' -t 'p=ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64' haven.accioly.social
haven.accioly.social... ok.

^C

So basically I can't alternate between profiles when using a fixed NOSTR_CLIENT_KEY. The strategy with two NOSTR_CLIENT_KEYS also only work for a single event.

nak1() {
  NOSTR_CLIENT_KEY="zzzzzz" nak "$@" --sec 'bunker://ee9d979e7e1418a9f7472baf82dc96082a0d4251b77bcb170a6ecec93fadff64?relay=wss://relay.nsec.app&secret=xxxxx'
}

nak2() {
  NOSTR_CLIENT_KEY="wwwww" nak "$@" --sec 'bunker://f7ef6812908ec787942e547548b16a64791a6e511b4060e5f77c02b5476cc953?relay=wss://relay.nsec.app&secret=yyyy'
}

[aaccioly]

By the way. I tested with multiple relays just to discard any potential issues with Haven / Khatru. No dice. It may be something on Amber's side of the equation as Khatru's built-in remote signer theoretically works, having said that I have been using Amber + Amethyst with several keys without any issues.

[fiatjaf]

I just installed Amber and created two keys and one bunker for each key. I have a static $NOSTR_CLIENT_KEY environment variable on my terminal.

I can very naturally use the two Amber bunkers from my terminal as many times as I want:

In the beginning I told Amber to "ask me every time" so I got a bunch of phone notifications and authorized the signing. Then I told Amber to remember my choice and allow signing so I could just sign without being prompted. Everything always worked.

[aaccioly]

This is... interesting.... It remains broken for me (Latest nak, Amber 3.4.1 free). What happens if you create a couple of new keys in Amber, each with their own bunker urls, and then select the option to fully trust the client and proceed to alternate between the bunker urls as you did abive (say, posting regular kind 1 events)?
Also, why I can't see messages such as <name of relay> ok and publishing to <name of the relay>... success in your output? (Just making sure that logs aren't a factor here).