gubatron
commented
1 month ago thoughts on NFC payment capabilities?
In my experience using Google Wallet for years now to pay for 99% of things with a tap, nothing beats this when it comes to payment experience, perhaps the Amazon One palm scanning is superior.
QR codes are useful for remote payments, but in person, nothing beats a one second tap.
Illium mobile wallet requirements 1) Splash screen (Create wallet / Restore wallet) 2) Create wallet flow (option to backup seed) 3) Restore wallet flow (enter seed, sync chain) 4) Wallet overview (view balance, etc) 5) Transactions (view outgoing and inbound txs) 6) Transaction details (view details of a tx) 7) Send (send illium, defaults to private tx with option to send public tx) 8) Receive (display address) 9) Settings (currency, language, network: mainnet/testnet, resync chain, biometrics, backup seed, proving server on/off/set own) 10) Loading states, Error states, etc
Comments from Chris When I built a wallet for BCH here was the spend workflow that I used.
1) There was a button to open a QR scanner and a button to send coins. 2) If you clicked the send button it would would open the send view. 3) If you scanned a QR code it would open the send view and populate the fields with data from the QR (address and optionally amount). 4) The send view would have a next button or something like that. 5) When you clicked next you'd be taken to another view showing you the details of the transaction you're about to make and asked to confirm it. 6) There were three options to confirm
I don't know if that's the UX you'd want but that's how I did it before.
There was also a "request coins" view that would let you enter an amount to request and would generate a QR code with the amount in it.
Like the URI would be something like:
illium://<address>?amount=<amount>Also on #8. I don't think we need to give users the ability to create a new address. It just complicates the implementation.
There's no privacy leak reusing an address so it shouldn't really matter