Bitcoin wallets must start working on tap to pay systems. QR code sucks.
Login to reply
Replies (71)
Bitcoin wallets must
start working on tap to pay
systems QR code sucks
This haiku was found in the wild by npub1halkcws4lz49fdcznckk9unhsfh8yd6n6n7cnl68alkej7qptmxqjk60zq
Read the origin of this art: https://njump.me/eb68d04dbbb233e2db1cc5918386a3dd21403fd96bbf04cb5f98e97d33043abe
When I hear "we're so early" but see "we're so far behind"
Hard agree
Was thinking about this just yesterday.
you should add NFC support to amethyst, and get someone to make a yubikey style thing.
To pay? We have some NFC support, but just for nostr events 🤔
yeah, i can't think of anything practical off the top of my head. but there's no reason i can see why lightning terminals could not send the invoices over NFC. hard agree. someone needs to do it.
i do think a secondary feature that would be useful is that when the NFC sends the invoice, it could also negotiate a bluetooth link so the user's phone doesn't need internet access to dispatch the payment to their lightning node or custodian or LSP.
"start working" 🥜😎
Focus on the "working" part. :)
Yes, the process should be as seamless as using Apple Pay to get real adoption. We also need legislation to exempt these transactions from being a taxable event. If we want people to spend their Bitcoin it can’t be a taxable event every time you tap.
focus on yourself ;)
u 2 should get a room
We have boltcards, how hard is it to put into software?
I tried zapping this post from cashu.me wallet using nwc but no luck. Things do need to work to be usable.
👏🏾 👏🏾 👏🏾
View quoted note →
Good idea
Walmart doesn't support tap to pay and they're doing alright. Just saying
It would be cool if the Bitcoin wallets on phones could just tap each other instead of the QR code/camera model.
Touch tips
💯
On android, simple. on iOS, nearly impossible
Or could use boltcard approach with lnurlw.
Or an offline transfer protocol like ecash.
Then the online terminal can do the withdrawal from node/lnurl-server or mint, while paying device remains offline
For automatic payments, I think it is way better to just add a NWC uri with a set budget and give that to the service/pubkey generating content..l
NWC is a nerfed persistent connection that requires manual user pre-provisioning and doesn't even offer static payment codes or budget requests
If you want better UX's you need to use better protocols, not browser extension slop
Happy to extend NWC to include those features if that is all it needs.
Needs a total rewrite for the handshake, not to mention the server handlers, it's literally leftover browser extension slop that never considered the bigger picture of ad-hoc and service connections
Keep letting that NIP repo access go to your head though, muh numbers...
This would be YUGE for Bitcoin adoption!
I’m hoping @MoneyBadger can solve this. 😉
yeah, wen auth ack
QR is static data. NFC is unmonitorable. QR is the best airgapped option.
I agree, but we're talking about a point of sale solution. Tap to pay is what people know. Aiming a camera while standing in line weird.
Auth? I'm intrigued. Describe what you have in mind
nip 42 flow forces clients to often have to resend events at the beginning of opening a websocket. there should be an ack so the client can just send it once after they know if the relay has allowed their storing of events, just once.
hmm, they'd have to send some event in any case in order to be ack'd, otherwise the relay can't know who's socketing... only alternative I could think of is pro-active auth, fail/retry is probably the simplest
currently, the only way the protocol acknowledges valid auth, sort of, is by an OK/CLOSED message (EVENT and REQ, respectively) with an errror. the ack should include a human readable part of the response that indicates, eg "authed to read/write; role name X of policy https://relay.url/policy.md%22
yea some standard GFY codes that could infer scope would probably help, looks like there's a human readable but is only appended after a single ambiguous prefix
yeah, specifying the policy also part of nip-11 as well, so a relay should be configured to telegraph to users what the policy is. this is too complex to use machine encoding. there is two parts. one part can be precisely described, such as event limits, event kinds, etc etc, the other half is the human-curated part of the policy.
any rejection of query or event publish will specify the policy violation it invokes.
you can be whitelisted to use a relay, but try to send events or queries that are forbidden by the relay, and it rejects them. so the ack is not a blanket permission, it is just an acknowledgement that the user has a role defined in the policy and they are restricted by the rules associated with the role.
the ack's purpose is just to prevent the waste of bandwidth and improve that initial load time, which is important, in my opinion. well written clients will proactively query and cache results that the user will want to see, to further improve UX.
QR can work if we had better scanning hardware. China is doing it with Alipay/Wechat for years but often with dedicated scanners where customer show their QR codes to pay. Using LNURL-withdraw this could be done with lightning as well.
I like QR Codes, prevents people from taping your pocket.
What's their effect? Do they scan more reliably and faster or is there some other benefit?
Phoenix Wallet for example had a 50% fail rate when we used it to pay at our local Meetup for no apparent reason. Maybe it was the weird light in that bar or some reflections by the bartender's smartphone display... 🤷♂️
We couldn't figure it out
mobile phone cameras often don't have enough resolution for the amount of data in a lightning invoice. if the QR is only an LNURL like LUD16 you get less problems.
LN terminals should use lightning addresses and require changing to use full onion wrapped invoices.
many phone cameras can't capture the QR at high enough resolution. this is a bigger problem in poor countries where phones are often 5+ years old tech
Yes 💯
Switching to a different app on the same phone often worked though. So we swapped to ZEUS or WoS after Phoenix failed and those apps could often fetch the invoice 🤷♂️
Maybe Phoenix was just bad 😆
probably depends on the QR code library in use then also
oh yeah, most phones have a good scanner in the phone now. you can scan with the camera, copy, and paste into the lightning wallet and pay that way for this case. but try other LN wallets too, and if you love the one you have, bitch at the devs about the QR reader library.
What can i test with? Never even seen a tap to pay device unless its iphone to iphone and there is no standard to follow?
🔥🔥🔥, AMEN 👌❗️😤
NY and Boston transit systems are all tap to pay now. Its super convenient.
I have never had issues with phoenix (on iOS) but it could be a camera issue. The scanner devices usually have a cone shape to reduce light falling in. When you turn the phone upside down to show your QR it reduces reflections.
Would be a great feature but I would not call QR codes sick. Easy System. Works!
yes.
View quoted note →
Qr codes aren't that bad and tap to pay isn't always possible. That being said, it should be used when it is.
They are extremely slow in comparison
But not always convenient. How would the audience donate to speakers on this situation without a qr code?
View quoted note →
It's good to create solutions for this where it is possible to use. I think it opens up a series of possibilities if nfc chips are safer and cheaper than cameras.
Why is that for ios?
Yes. The problem is not QR codes, it's the huge dynamically changing QRs. Smaller static QRs are a better UX than tap to pay
They're one-way. Don't worry about slow.
LNURL QR codes can be used both to deposit or withdraw
Lol grow some brains.
Hard agree, contactless is so easy, but I'd also be a bit scared of paying with Bitcoin that way.
I would zap you but you don't have a LN address 😔
Who says you need to be in a line? Payment systems simply need to need an amount. The QR could be presented at the shelf where the item is. Think future.
Well yea I use tap to pay all the time, i mean for btc. Who offers a tap to pay terminal for btc?
Just wait... #nostr #safebox
View quoted note →
Aqua wallet already has a virtual Visa Debit card. Samson's probably already working on either Aqua NFC functionality or integration with Google or Samsung Pay.
I'm waiting for a FOSS app that uses NFC to pay (like Google and iOS). But I'm not familiar with the technology so I don't know whether the NFC interface can handle complete invoice information (with a lot of data) or just the payment itself.
It is possible but really a marginal iteration that requires a ton of effort. We can solve it today if merchants are willing to buy new hardware, but it doesn’t scale well.
Ah thought it might be.
Better to just bypass the tap to pay fiat minefield and get merchants to accept bitcoin directly..