nsecBunker crashes / token error

[derekross]

It looks like nsecBunker support still has some bugs. If Lume crashes, upon restart, I am presented with a token error. I've had this happen 3 different times. Each time, the application crashed in a different part of the UI. Each time upon restart, I get the error. To fix, I blow away the local application data and generate a new nsecBunker token. Rinse and repeat.

https://i.nostr.build/JJYM.png

[reyamir]

Hi @derekross, thank for your report

I've re-tested the nsecbunker feature, the current UI a bit messy, when user click connect with nsecbunker button, they need to go to nsecbunker webapp -> then click Approve

and token only can use one time, if token is redemn, app will stuck at the loading screen, this is bug I'm working to fix it

I'll do complete revamp on the UI for nsecbunker (and other signer app) in the next update.

[reyamir]

Other things I will add is auto-open nsecbunker webapp when some action need user's approval

[reyamir]

Hi @derekross, while waiting me update the UI for nsecbunker, you can follow this guide for using nsecbunker with Lume

https://github.com/luminous-devs/lume/assets/123083837/2e13310f-c10d-41de-8073-34c564c8fa8a

[derekross]

This is what I've done and it works great until the application crashes. Once it crashes it will no longer use the previous token that was supplied.

[reyamir]

oh, seem strange, I'll dig more into it

[reyamir]

Yo, I've found the problem here. With nsecbunker, user have 2 options:

1 - Using main key

With this option, user need to go back nsecbunker webapp to approve some action need user's approval (new post, zap, reaction,...)

2 - Using token

With token, user can assign policy so user don't need to go back nsecbunker webapp to approve some action everytime

But the cons is token is one-time usage, so if user login then close app or reload, the token is redeemed, app will stuck forever like your issue

So I need to improve this part to make sure user is acknowledged token is one-time usage, of token is redeemed, app will be redirect back to login screen instead of stuck

[reyamir]

I'm working on the next version, maybe release in tomorrow, if you don't mind I will send you the pre-release version to test it

[derekross]

okay. thank you. i appreciate it.

[reyamir]

Hi @derekross , I've pushed new version for improve nsecbunker support, you can try it here https://github.com/luminous-devs/lume/releases/tag/v2.2.1

if you see something need to be improve you can feedback me here 😊

[derekross]

Hi @derekross , I've pushed new version for improve nsecbunker support, you can try it here https://github.com/luminous-devs/lume/releases/tag/v2.2.1

if you see something need to be improve you can feedback me here 😊

Thanks. It looks like the workflow is better, but the same issue with Luke not reusing the token still exists. Upon restarting the app I have to generate a new token. And if I decide to go the non-token route and authorize individual events, it still has issues. Sorry.

[reyamir]

Ah, this is default behavior of nsecbunker, token is one-time-use (https://dev.nsecbunker.com/) but I still working on better flow for it, user only need to provide new token in specific screen instead of redoing full onboarding process

[derekross]

okay. though i don't have this issue with other clients with nsecbunker. i generated a token and i continue to use that token with those clients.

[reyamir]

oh, seem strange, let me check with Pablo

[pablof7z]

hey guys

@reyamir you should save the private key you generated locally; the one-time use token applies policies to that pubkey, so save it as you would save any nsec; no need to ask the user to give you a new token on each restart.

Also, I noticed a few commits ago you were trying to redeem the same token upon restarting the app, which is not going to work 😅

For clarity, the flow is:

1. user generates token on nsecbunker
2. user opens Lume and logs in with npub#token
3. Lume generates private key
4. Lume sends connect with user's pubkey+token
5. Lume stores user's pubkey and the private key generated in step 3.
6. Upon restart, Lume just reconnects with pubkey using the same private key generated in step 3.

[reyamir]

hey guys

@reyamir you should save the private key you generated locally; the one-time use token applies policies to that pubkey, so save it as you would save any nsec; no need to ask the user to give you a new token on each restart.

Also, I noticed a few commits ago you were trying to redeem the same token upon restarting the app, which is not going to work 😅

For clarity, the flow is:

1. user generates token on nsecbunker
2. user opens Lume and logs in with npub#token
3. Lume generates private key
4. Lume sends connect with user's pubkey+token
5. Lume stores user's pubkey and the private key generated in step 3.
6. Upon restart, Lume just reconnects with pubkey using the same private key generated in step 3.

Yo, I'm very appericate your support, my mistake is in the last step 😅 @derekross I'll push new version now

[reyamir]

Yo @derekross , new version is released https://github.com/luminous-devs/lume/releases/tag/v2.2.3 this time it will work well 😅

[MerryOscar]

@reyamir it looks like the NIP-46 connection string should also work with a format like this:

bunker://<hex-pubkey>?relay=wss://...&secret=<optional-secret>

are you able to support this format?

[reyamir]

Yes, I will add this format too