Where are all the bunker devs? I tried to use zapstore/zsp w...

Leo Wandersleb

npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6

hex

66d23bee7a16f0908a49c3d8203276facff781f9baac66d335f2231f24b787f7

nevent

nevent1qqsxd53maeapduys3fyu8kpqxfm04nlhs8um4trx6v6lygclyjmc0acprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsydl97xpj74udw0qg5vkfyujyjxd3l706jd0t0w0turp93d0vvungnmfrla

Kind-1 (TextNote)

2026-01-22T00:30:58Z

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.

nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhggpt7fy nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgsl0k9y nostr:nprofile1qqsgezpch78ndwrpxu97hs4vm6x3whetmy0ssldmg30d7ue8jvwanyq0qffj7 nostr:nprofile1qqsty2cxkpgl653jje4fx39xxnv4ds7uxwnltmxu4k0dz8wugys20us8l2n6q

Raw JSON

{
  "kind": 1,
  "id": "66d23bee7a16f0908a49c3d8203276facff781f9baac66d335f2231f24b787f7",
  "pubkey": "46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d",
  "created_at": 1769041858,
  "tags": [
    [
      "client",
      "Yakihonne",
      "31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
    ],
    [
      "p",
      "0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd",
      "",
      "mention"
    ],
    [
      "p",
      "7579076d9aff0a4cfdefa7e2045f2486c7e5d8bc63bfc6b45397233e1bbfcb19",
      "",
      "mention"
    ],
    [
      "p",
      "8c8838bf8f36b861370bebc2acde8d175f2bd91f087dbb445edf7327931dd990",
      "",
      "mention"
    ],
    [
      "p",
      "b22b06b051fd5232966a9344a634d956c3dc33a7f5ecdcad9ed11ddc4120a7f2",
      "",
      "mention"
    ]
  ],
  "content": "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.\n\npairing 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.\n\napi 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.\n\nSo 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.\n\nnostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhggpt7fy nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgsl0k9y nostr:nprofile1qqsgezpch78ndwrpxu97hs4vm6x3whetmy0ssldmg30d7ue8jvwanyq0qffj7 nostr:nprofile1qqsty2cxkpgl653jje4fx39xxnv4ds7uxwnltmxu4k0dz8wugys20us8l2n6q",
  "sig": "e50cb9740c1c5ea4303373d5c3cd95ef2fbe5850bf052a0e64b73c7fbcaa9c55f7c0b74cfa45ebe9fa9a99d3b39b28a8f9aace3f278288d7c47e851d6ffca616"
}