2022/08/03 11:00 UTC - LSP Spec Meeting
Video of call: https://drive.google.com/file/d/1hjUdx5bnkY40LBL648c3DGwzYEdYmPy7/view
Attendees:
Christian Decker, Yaacov Slama, John Carvalho, Reza Bandegi, Corey Phillips, Pavel Nikolov, Severin Buhler, Nick Slaney, Vivek Kasarabada
Notes by Pav Nikolov:
Reza - unified LSP channel request API. Some changes submitted mostly by Sevi - suggestion to have definition to have code generators. If everyone is OK, we can merge this as first version. Do we merge the 0fee proposal (channel renewal) - with BT we will have channel renewals as well - seems OK to be added as part of the spec.
**Sevi B **- 2 pull request (1 closed down) - the 2nd pull request was made to change API so you don't have to permanently store channel ID. If you want to renew channel (submitted as proposal). LSP Spec TG - Matt left notes. Breez did you think about price predictability with renewals? Channel renewal API - you don't know the price which you have to pay each month - can be challenge for user - no predictability.
Yaacov S - user pays for 1 channel creation and that is it (no subscriptions). John C - pool request and design for base spec is pretty much done. JIT are people happy about how its being represented in the spec.
Sevi - not happy, API is vulnerable, mixed feelings John - 1 as we are getting ready to launch our wallet - legal counsel - pretty concerned about unhosted / hosted wallet and where that falls. Legal was asking a lot of questions how LSP interacts with the wallet, what happens when the LSP is not there and where are the lines so there is no legal vulnerability. This will probably get worse, both legal teams (particularly US) will start to learn how LN works and are prone to designate it as money service.
How LN works - who is giving money to who, what do you know etc ... whether it falls under VASP service / custody etc ...
JIT idea backwards -instead of us trusting the user and opening channel preemptively and taking risk as LSP, why not show them invoice for the LSP instead - instead of having user generate invoice, which they cant receive from their own node, generate invoice from the LSP (buying channel) - getting the QR code from the LSP, its like middle-manning the payment, payment goes to LSP, instead of user - LSP knows which node is buying channel. You open 0 conf channel on user side as payment instead of forwarding channel and taking fee after. Payment is paying the LSP like any other channel purchase,
Nick - tough, you are letting LSP have the payment, introduces element of trust (to LSP) 0 conf is trusting LSP.
JC - you either trust the user or trust the LSP. You are middle-manning the payment process - legal may consider is as payment processing. They may feel the same way of JIT.
Sevi - fee you need to pay for the LSP to open channel, if you want LSP to push an amount to your channel on your side - same as channel request (only difference from UX you include - this will inject this into the receive flow.
Reza - if I pay someone and get LSP invoice and I am not told and see a node of an LSP, not many wallets decode invoices, but its weird UX
JC - That is true of every invoice unless they check. Further we can include in the node data, this is channel opening for LSP and forwarded payment to user and be more intentional for the user UX. For next call we can present phase 1 done in one place.
Nick - marketplace as next step / point to discuss. add Amboss for next call + Pool. LN+
Vivek - potentially discuss splicing and invite Rusty.