Thread

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.

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

yeah, wen auth ack

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.

Focus on the "working" part. :)

focus on yourself ;)

u 2 should get a room

I tried zapping this post from cashu.me wallet using nwc but no luck. Things do need to work to be usable.

On android, simple. on iOS, nearly impossible

Why is that for ios?

Touch tips

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

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.

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.

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.

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.

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.

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. The problem is not QR codes, it's the huge dynamically changing QRs. Smaller static QRs are a better UX than tap to pay

NY and Boston transit systems are all tap to pay now. Its super convenient.

Well yea I use tap to pay all the time, i mean for btc. Who offers a tap to pay terminal for btc?

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.

They're one-way. Don't worry about slow.

LNURL QR codes can be used both to deposit or withdraw

Lol grow some brains.

I would zap you but you don't have a LN address 😔