Where are all the bunker devs? I tried to use zapstore/zsp with Amber but it didn't work because zsp treats the secret of the bunker url as an api key while Amber treats it as a pairing code. And there is good arguments for both approaches.
pairing code: the bunker app pairs with a client and from then on uses a client key that is not exposed to the user to avoid re-use. This is a very tight link. If you want to use different clients you have to use different bunker urls and while that is hard to setup, it prevents a situation where you cannot know who is abusing the bunker as there is only one client per bunker url.
api key: knox uses the secret from the bunker url like an api key and allows ephemeral client keys. This is easier to setup as a bunker url can be re-used and it's more private as the client key is a nostr identity and re-use means privacy leaks.
So knox uses a long secret while Amber uses a short one and those differing approaches result in friction. And the nip allows both. I think there should be more clarity in the nip and as both approaches are somewhat valid, both should be supported. Maybe a pairing code should avoid the parameter "secret=..." and use "nonce=..." or something? Also privacy should be possible regardless of the client key being re-used or not, using giftwraps.
@Alex Gleason @greenart7c3 @nprofile1q... @Russell
pairing code: the bunker app pairs with a client and from then on uses a client key that is not exposed to the user to avoid re-use. This is a very tight link. If you want to use different clients you have to use different bunker urls and while that is hard to setup, it prevents a situation where you cannot know who is abusing the bunker as there is only one client per bunker url.
api key: knox uses the secret from the bunker url like an api key and allows ephemeral client keys. This is easier to setup as a bunker url can be re-used and it's more private as the client key is a nostr identity and re-use means privacy leaks.
So knox uses a long secret while Amber uses a short one and those differing approaches result in friction. And the nip allows both. I think there should be more clarity in the nip and as both approaches are somewhat valid, both should be supported. Maybe a pairing code should avoid the parameter "secret=..." and use "nonce=..." or something? Also privacy should be possible regardless of the client key being re-used or not, using giftwraps.
@Alex Gleason @greenart7c3 @nprofile1q... @Russell
