erik on Nostr: This was really helpful. Some good edge cases to think through. Here’s my first ...
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.
“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.