Joao Joyce [ARCHIVE] on Nostr: đź“… Original date posted:2019-01-28 đź“ť Original message: Ok, that would work for ...
đź“… Original date posted:2019-01-28
đź“ť Original message:
Ok, that would work for this particular case which is of course a very simple PoC. But the problem of connecting multiple payments to a user account still stands, or am I missing something?
And the user would also be required to keep a copy of the pre-image for every bought item right? It feels like just holding a priv key should be enough to get all my books, items, account info...
I get that there might be implementation and UX issues around something like this but I’m not seeing the privacy risks around it.
Why should some of these use cases be ruled out preventively and not just pass that responsibility to the user who might benefit from them?
As a user I think I wouldn’t mind giving permission for a service to keep my high scores or all the books I got, or all the music I bought in the same account...
And if that can be done in a single step, opted-in and I don’t even need to provide any personal info that could lead to my “human identity” even better! That would be a major improvement from most services now who force you to have an email account which can most of the time give a lot of information about someone and provide them a password which, who knows what they do with it and how they store it...
________________________________
De: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Enviado: 28 de janeiro de 2019 01:21:13
Para: Joao Joyce
Cc: lightning-dev at lists.linuxfoundation.org
Assunto: Re: [Lightning-dev] Lightning network user identification
Good morning Joao,
>
> Eventually I could use something like SQRL or BitID which enable some level of anonymity. But now the user would have to keep an app for login and another for payments. He is expected to have both apps to use the service and keep both private keys secure. Both would use QR codes which makes for a lot of confusion and a terrible user experience. Of course I would have to eventually code the email/password anyway as a fall back.
>
> Contrast this scenario with this one which is basically identical to the one in the video:
> 1 - User goes to the ebook store.
> 2 - User selects the book he wants and scan a LN invoice.
> 3 - Wallet shows payment info and asks if user wants to provide his identity.
> 4 - User confirms payment and identity in the same action.
>
> There was no need for the user to create an account or to log in to the service. And no need for the store to keep any private data, just a unique userID that is only valid for that particular store.
Why is not the proof-of-payment sufficient?
Service generates a secret, user pays for the secret, proof of knowledge of secret authorizes use of the book.
In short, use the payment preimage as "unique userID".
You also automatically ensure that userIDs are usable only if paid for.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190128/fd09c7c4/attachment.html>;
đź“ť Original message:
Ok, that would work for this particular case which is of course a very simple PoC. But the problem of connecting multiple payments to a user account still stands, or am I missing something?
And the user would also be required to keep a copy of the pre-image for every bought item right? It feels like just holding a priv key should be enough to get all my books, items, account info...
I get that there might be implementation and UX issues around something like this but I’m not seeing the privacy risks around it.
Why should some of these use cases be ruled out preventively and not just pass that responsibility to the user who might benefit from them?
As a user I think I wouldn’t mind giving permission for a service to keep my high scores or all the books I got, or all the music I bought in the same account...
And if that can be done in a single step, opted-in and I don’t even need to provide any personal info that could lead to my “human identity” even better! That would be a major improvement from most services now who force you to have an email account which can most of the time give a lot of information about someone and provide them a password which, who knows what they do with it and how they store it...
________________________________
De: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Enviado: 28 de janeiro de 2019 01:21:13
Para: Joao Joyce
Cc: lightning-dev at lists.linuxfoundation.org
Assunto: Re: [Lightning-dev] Lightning network user identification
Good morning Joao,
>
> Eventually I could use something like SQRL or BitID which enable some level of anonymity. But now the user would have to keep an app for login and another for payments. He is expected to have both apps to use the service and keep both private keys secure. Both would use QR codes which makes for a lot of confusion and a terrible user experience. Of course I would have to eventually code the email/password anyway as a fall back.
>
> Contrast this scenario with this one which is basically identical to the one in the video:
> 1 - User goes to the ebook store.
> 2 - User selects the book he wants and scan a LN invoice.
> 3 - Wallet shows payment info and asks if user wants to provide his identity.
> 4 - User confirms payment and identity in the same action.
>
> There was no need for the user to create an account or to log in to the service. And no need for the store to keep any private data, just a unique userID that is only valid for that particular store.
Why is not the proof-of-payment sufficient?
Service generates a secret, user pays for the secret, proof of knowledge of secret authorizes use of the book.
In short, use the payment preimage as "unique userID".
You also automatically ensure that userIDs are usable only if paid for.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190128/fd09c7c4/attachment.html>;