don't give blank-signing access to apps you can't trust -- I think this will be an ongoing lesson for people in the next decade -- but it's irrelevant of whether this is money or your identity -- you simply shouldn't do that without, at lease, getting a sample of what the app is asking you to sign.

This is the same idea as WoT -- you can fool some people for a very short-lived time at great expense.

That said, that's why I also added the concept of having a user-level passphrase on a wallet -- you could have no passphrase on low amounts, and as soon as you get to a certain limit your app is instructed to move to a cashu wallet that requires a passphrase to decrypt the proofs. 

 Ah, cool. So its the same cashu stuff me and @sebas played around with :) 

 what about receiving? does it use some kind of cashu<->lightning address gateway for zaps by people who use a client that does not understand cashu zaps? 

 Not yet, but I will probably write one; the beauty is that it doesn’t need to take custody at any time; you respond to an LNURL request with the mint’s bolt11, so it’s extremely lightweight 

 I think there are open source gateways already, no need to write a new one. It should just be setup during onboarding in the profile. 

 They don’t do the new spec, they just send you unlocked ecash via a dm 

 npub cash says they lock tokens to the public key. 

https://npub.cash/

https://m.primal.net/JQWZ.png
 

 "How cool is that?" 
nostr:nevent1qqs2tpr9l6yjrch3cxgflwdsst4xut3e0ps9vrcmnyvun4uv0fsuaqcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg86np9a0kajstc8u9h846rmy6320wdepdeydfz8w8cv7kh9sqv02gpsgqqqqqqspvpkrk 

 I love his "how cool is that". Please don't stop now that you're self-conscious about it Pablo. 

 Would you mind explaining this innovation to me (or whoever else see it) like im 5 years old? I have a hard time with dev talk sometimes 

 Is there a writeup of how Cashu pubkey-locking works? @calle 👁️⚡👁️ 

 https://github.com/cashubtc/nuts/blob/main/11.md 

 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 ^^ 

 I guess I’m defining API more broadly, as in “what UX does it enable”. Happy to connect to discuss in more depth if you’re open to it. 

 P2pk 

 so it's an on-chain utxo then?

there's the mint, and there's you

this isn't a blockchain protocol 

 https://github.com/cashubtc/nuts/blob/main/11.md 

 "The spending condition is enforced by the mint." = trust me bro

if it were a worthwhile amount to steal, i just have to persuade you to sign on the message hash and done 

 This is a custodial solution. There is always a level of trust in a custodial system. This is an improvement to everyone using custodial WoS or Alby.  If you want to maintain full custody run your own lightning node (and/or mint)