I'd love to see the whole flow between two devices, both new and previously connected. I think new is the experience most will have and it is first impression too.

What UX differences should new and returning users see? What type of things come to your mind as you imagine airdropping nuts to new users vs your well known friends?

Well I imagine there will be OS level permissions and walls to break through. Bluetooth tends to ask questions like "X is trying to send you a file" which is good for security but bad for UX. Have you managed to work around all of that?

Actually one thing I noticed is that small delay in confirmation of receipt. This can give us the opportunity to get a full acceptance flow for online payments. So you send me ecash and from your end it is done, but for me, I haven't really accepted it yet. I trade it for a new ecash and if it works, I accept. If it fails, or if I don't want to trust that mint, I reject. I could also reject it maliciously of course. If I report the payment as failed, then you can trade the ecash for a new one and if it fails, then there's a problem. But in most cases you just take back the funds and payment is cancelled/rejected. The problem case is interesting. Without p2pk and a timeout, there is no atomic payment and even with, there is no proof of payment like we have on lightning afaik. Are there any protocols or flows to address them?

My understanding was that as you add trusted contacts, you can get asked less security questions. But before that, you want to accept connections etc.

This was really helpful. Some good edge cases to think through. Here’s my first impressions. “So you send me ecash and from your end it is done, but for me…” I don’t see the user experience ending for the sender once they hit send on the ecash token. While the token is being sent, the wallet should display “sending” because there’s more going on than just the sending part. First, the token gets generated. Then, it’s transmitted via Bluetooth. Finally, the receiver has to accept and actually receive it. “I haven’t really accepted it yet. I trade it for a new ecash and if it works, I accept. If it fails, or if I don’t want to trust that mint, I reject. I could also reject it maliciously of course. If I report the payment as failed, then you can trade the ecash for a new one and if it fails, then there’s a problem. But in most cases, you just take back the funds and the payment is cancelled/rejected.” We can solve this by separating the token generation from its successful receipt. So, when the user sends the ecash and the token is generated, that part is done. If the recipient rejects the payment or it fails because of Bluetooth interference, we can show a message that says, “Ecash token was successfully generated but failed to send. You can try sending this token again by viewing the token and selecting the airdrop option.” “The problem case is interesting. Without p2pk and a timeout, there is no atomic payment and even with, there is no proof of payment like we have on lightning afaik. Are there any protocols or flows to address them?” Not sure if I totally get this point but here's my thoughts: the atomic nature of ecash at the token generation stage. Once a token is generated, that’s final. For the user experience, after the token is generated and sent via Bluetooth, it will either be received successfully or it won’t. We’ll show a success or error message based on that. Once the airdrop attempt is done, the user will be sent back to the home screen. There, they will see the token as either redeemed or pending. It shows as redeemed (so it can’t be double-spent) if it was received successfully, or pending if it didn’t get to the recipient. They can then try sending the pending ecash token again via airdrop.

The way I interpret your words, "received" means "received over Bluetooth" not "received and claimed". Correct me if I am wrong, but I think we see a successful transaction differently. You see it as when the token lands on the receiver's device, I see it as when the token is spent at the mint. When I as a receiver get an ecash token, I cannot know if it is valid until I trade it for a new one. I understand that a p2pk is different and maybe we should have two separate conversations across 2 threads to avoid confusion. With p2pk, I still don't consider the payment done until the token is claimed: 1. I as the receiver may decide that I don't want to claim the token because I don't trust the mint. 2. I may have technical issues reaching the mint at the time. Actually, if I want to reject the payment, I should send it back to you signed instead of to the mint and you can reclaim it yourself, and that would actually be an atomic refund once I reclaim the cashu token.