Reply to this note

Please Login to reply.

Discussion

Very helpful, thanks! It does appear that there's a bug in nos2x that prevents it from properly decrypting wallet backups using the NIP44 method. This is something we’ll have to catch so we can display a more helpful error message.

t Y guys/*gals

I think can be that I had the backup on your Jumble fork that had spark integrated, so when I restored the backup on zap.cooking, gives this error?

Someone tested created the backup on zap.cooking and restoring on zap.cooking and worked ok.

I did test earlier by restoring a relay backup from a different client and it worked for me, but might warrant further testing. This is definitely an edge case.

Thanks, I think we’ve got it solved! There’s no bug in nos2x, it was just a lack of detection method for the older wallet format created by the previous app. Bug was on our end.

I still reproduce the same problem.

It hasn’t been merged yet.

OK, the fix has been merged and tested.

I created a new wallet with the Jumble Spark prototype using the Keys.band extension, which does not support NIP-44 encryption, so the backup was encoded using NIP-04.

I then switched to nos2x to decrypt and restore the same wallet using Zap Cooking, and it worked as expected.

Your relay backup should work now.

Yes, worked ok now. I was able to restore, thanks.

The ciphertext being decrypted in his screenshot is a NIP-04 one, notice it ends with an "?iv=..." parameter.

Thanks for catching that. This will help improve the detection logic in these random cases.

What I'm saying is that the app that created this backup encrypted the seed with NIP-04 instead of NIP-44. It was a bug there. Just fix that, don't go around trying to detect edge cases.

Right, what I mean by edge case is that the app that created the backup was an earlier proof-of-concept that few people except myself and nostr:npub1vxd0dfst8ljvwva2egrpc53ve8ru78v8aaxfpravchkexmfmmu3sqnrs50 have used before, meaning the chance of other users experiencing this issue is low. It allowed both encryption methods because one of the signer extensions tested did not support NIP44, so our import function needs just to detect this. That's what this fix will cover.