Igor Cota [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-05 📝 Original message: Hello all, I feel that ...
📅 Original date posted:2018-04-05
📝 Original message:
Hello all,
I feel that one of the biggest promises of lightning lies in it being used
for everyday retail payments.
I'd like to see a system that's:
1) instantaneous like the contactless bank cards of today
2) encodes a fancy HTML receipt in bolt11 for the payers future reference
QR codes are a bit unwieldy and even more so if you want a nice HTML table
description of your grocery shopping with hundreds of items - this
relatively large amount of data makes them impractical to scan.
To this end I've been running an instance of c-lightning on Android
[1][2][3] and experimenting with payments via NFC. I set up a machine with
an NFC USB dongle that acts as an point-of-sale terminal [4]. So far so
good!
There are two basic ways you can use NFC enabled phones today - as passive
tag readers or in card emulation mode (not sure if the latter is available
on iOS).
Passive tags are really simple and encoding bolt11 to them works as
expected. If you set the right MIME type Android will open whatever app is
registered to handle lightning and you can either pay instantaneously or
after user confirmation. Works great provided both the phone and terminal
are connected to the network and have a route to each other.
Card emulation mode is more interesting because it enables us to have two
way communication and therefore an ad hoc connection to the lightning
network. After some handshaking, phone can tell the terminal that it wants
to connect to lightning via NFC. All communication between these two
lightning nodes can be done over NFC or even bluetooth [5]. This might be
useful as fallback in situations where mobile data is not available.
I settled on a MIME type (application/lightning) and an NFC application id
(LIGHTNING). There is also a very simple protocol to forward socket data.
For the sake of interoperability it would be great if we agreed on some
standards but I'm not sure how to proceed with this. Should these be part
of a future BOLT or is mailing list banter enough?
I look forward to your views!
Cheers,
Igor
[1]
https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
[2]
https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7
[3]
https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
[4] https://github.com/icota/presto
[5] https://github.com/ElementsProject/lightning/pull/1323
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180405/14754627/attachment.html>;
📝 Original message:
Hello all,
I feel that one of the biggest promises of lightning lies in it being used
for everyday retail payments.
I'd like to see a system that's:
1) instantaneous like the contactless bank cards of today
2) encodes a fancy HTML receipt in bolt11 for the payers future reference
QR codes are a bit unwieldy and even more so if you want a nice HTML table
description of your grocery shopping with hundreds of items - this
relatively large amount of data makes them impractical to scan.
To this end I've been running an instance of c-lightning on Android
[1][2][3] and experimenting with payments via NFC. I set up a machine with
an NFC USB dongle that acts as an point-of-sale terminal [4]. So far so
good!
There are two basic ways you can use NFC enabled phones today - as passive
tag readers or in card emulation mode (not sure if the latter is available
on iOS).
Passive tags are really simple and encoding bolt11 to them works as
expected. If you set the right MIME type Android will open whatever app is
registered to handle lightning and you can either pay instantaneously or
after user confirmation. Works great provided both the phone and terminal
are connected to the network and have a route to each other.
Card emulation mode is more interesting because it enables us to have two
way communication and therefore an ad hoc connection to the lightning
network. After some handshaking, phone can tell the terminal that it wants
to connect to lightning via NFC. All communication between these two
lightning nodes can be done over NFC or even bluetooth [5]. This might be
useful as fallback in situations where mobile data is not available.
I settled on a MIME type (application/lightning) and an NFC application id
(LIGHTNING). There is also a very simple protocol to forward socket data.
For the sake of interoperability it would be great if we agreed on some
standards but I'm not sure how to proceed with this. Should these be part
of a future BOLT or is mailing list banter enough?
I look forward to your views!
Cheers,
Igor
[1]
https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
[2]
https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7
[3]
https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
[4] https://github.com/icota/presto
[5] https://github.com/ElementsProject/lightning/pull/1323
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180405/14754627/attachment.html>;