W3C Web Payment group

[renepickhardt]

you should look at this spec recommendation: https://github.com/w3c/payment-request/ to create a spec for Webln. this is hopefully to become a standard that browsers will speak at some point in time. Maybe even possible to integrate the macaroons in there somehow.

[wbobeirne]

Thanks for the link Rene. I'll definitely take this into consideration for the sendPayment function, but we'll have to come up with our own spec for everything else (Client creating invoices, signing & verifying messages, etc.)

[renepickhardt]

Just talk to @cdecker if doubts arise as he is member of the web payment group. Still believe being compliant with standards is a huge plus

[plwalters]

Agreed, I saw a note about a new spec from your Joule browser extension but I could not find a corresponding spec anywhere else that this was based on so I assume this is a brand new spec you are proposing, but I'm not sure if it is being proposed anywhere. Not to discourage that but I wonder if you followed an existing spec proposal such as the payment request API if it would be better for agreement and encouraging others to implement per a spec.

https://developers.google.com/web/fundamentals/payments/basics/how-payment-request-api-works

Actually many of the non-cryptocurrency developers that I have talked to are already using this spec so I wonder if there is a good way to adhere to it.

edit

Adding another link for a thread on the Linux Foundation mailing list which addresses this (https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001404.html) brought up by the one and only @renepickhardt ;)

[wbobeirne]

The more I think this over, the more I feel that WebLN and W3C payments serve very different purposes.

I plan to gear WebLN towards the use cases that make Lightning different than normal payments. Micro-payments, invoice generation, decentralized identity etc. The only sites that would use WebLN are the ones that want these kinds of Lightning-specific interactions.

The way I see clients integrating with W3C payments is by adding a Lightning as a payment provider. Unfortunately, the current doc considers the process of adding a payment provider "out of scope".

My hope for the future of W3C payments, and my plan with Joule is to be able to add Lightning as a payment provider through some extension hook. That way vendors that already use the API would simply need to add 'lightning' (Or whatever it ends up being) as one of the supportedMethods. I look forward to seeing how they allow browser extensions to provide this functionality, and would be happy to provide my thoughts and opinions on that if needed. I imagine this will be a common use case, as third party payment processors that don't have a browser (e.g. PayPal, Venmo) will likely want a way to integrate as well.

I hope y'all find this agreeable. I definitely want to stick with standards where they're applicable, but I think that the same interface and user experience for making a transaction for tens / hundreds / thousands of dollars at checkout is a much, much different one than having a user pay a fraction of a cent to view a piece of content (perhaps without them even approving it!)

[wbobeirne]

@PWKad For what it's worth, this standard is based around Ethereum's web3, so it's not entirely a brand new spec.

[plwalters]

jk, you do you brother. Good luck!

[renepickhardt]

just for reference: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001835.html

[melvincarvalho]

I added a post here in the w3c payments community group

https://lists.w3.org/Archives/Public/public-webpayments/2019Mar/0003.html

As a background the W3C typically offers two tracks. One is a working group, normally full of large companies that create specs designed to be standards.

The other is a community group which is open to everyone for free which can find like minded people to work together on creating specs. There's no reason at all why a community group cant make a W3C standard. It just generally tends to happen in working groups which tend to be less casual and have more organized regular meets etc.

Would love to collaborate on this, I'm definitely keen to use webln