Ah, so the lock is initiated by the mint, not on the user’s Cashu client? Cause I was wondering how to prevent double spending.
It's initiated by the sending user but it's enforced by the mint.
Ah, so there is an http request from the sender to the mint before the nut zap. It sounded like magic to zap the ecash via nostr w/o any roundtrips to the lightning node.
That only works for unlocked tokens. You can zap someone an unlocked but encrypted token and that should work without talking to the mint. However, then it becomes less publicly verifiable.
Interesting. I was wondering why npub.cash doesn’t just send me an unlocked token via nostr DM when I receive a zap to my lightning address. I guess this is the UX that Pablo’s spec enables. But it also combines the Cashu wallet seed and the Nostr nsec as a single secret.
npub.cash does not do this, because I did not get to implement it yet. Also it was always meant to be an API service that is more hidden from the user. Like giving a Lightning address to a Cashu wallet and claiming the nuts automatically
Makes sense. Just my 2 sats worth… as a developer I’m more likely to integrate an API that delights me as a user first.
I understand that. What exactly is missing to make it a delight? DMs doesn’t count, as it’s not part of the API ^^