Yaacov Akiba Slama [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-14 📝 Original message: On 14/11/2019 03:59, ...
📅 Original date posted:2019-11-14
📝 Original message:
On 14/11/2019 03:59, Rusty Russell wrote:
> Yaacov Akiba Slama <ya at slamail.org> writes:
>> So we can integrate between them without intermixing the semantics of
>> the protocols but we need only to define the interaction points between
>> them.
>>
>> In the previous worflow, the seller can for instance add in the LN
>> invoice H(Quotation (UBL)||Order(UBL)||Prepayment Invoice(UBL)), and use
>> H(Receipt(UBL)) as preimage. With such a workflow, the UBL documents are
>> cryptographically tied to the LN payment.
>>
>> So the property of UBL of not being machine *handlable* is not altered
>> but the LN cryptographic properties are still used to tie the workflow.
>>
>> Am I missing something?
> Sure, people can do this today: simply set your `d` field to "UBL:
> <hash>".
Exactly. But we can add a BOLT which contains 1) references to UBL as a
way to exchange the business information needed in the payer<->payee
interactions and 2) describe the process of tying the document(s) to the
payment(s).
> But it provide what we want from offers:
> 1. Does not provide a "static invoice" flow.
What do you mean by "static invoice" flow? Perhaps:
* Seller -> Buyer: Invoice (UBL)
* Seller -> Buyer: Invoice (LN)
* Buyer & Seller: Payment + Ack (LN)
* Seller -> Buyer: Receipt (UBL)
> 2. Does not provide a donation flow.
* Payer -> Payee: Order (UBL)
* Payee ->Payer: Invoice (LN)
* Payer & Payee: Payment + Ack (LN)
* Payer -> Payer: Receipt (UBL)
> 3. Does not provide a method for wallets to do recurrence.
A simplified workflow can be:
* Seller -> Buyer: Quotation (UBL) containing recurring information
* Buyer -> Seller: Order (UBL) containing recurring information
Then at every beginning/end of period (depending on the info in the
quotation/order)
* Seller -> Buyer: Invoice (UBL)
* Seller -> Buyer: Invoice (LN) (d contain the hash of the invoice +
f(previous docs))
* Buyer & Seller: Payment & Ack (LN)
* Seller -> Buyer: Receipt (UBL)
> 4. Does not provide end-to-end over LN (i.e. no HTTP(s) requests).
Yes as soon as LN support messaging (using [1] or [2] for instance)
--yas
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002275.html
[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002294.html
📝 Original message:
On 14/11/2019 03:59, Rusty Russell wrote:
> Yaacov Akiba Slama <ya at slamail.org> writes:
>> So we can integrate between them without intermixing the semantics of
>> the protocols but we need only to define the interaction points between
>> them.
>>
>> In the previous worflow, the seller can for instance add in the LN
>> invoice H(Quotation (UBL)||Order(UBL)||Prepayment Invoice(UBL)), and use
>> H(Receipt(UBL)) as preimage. With such a workflow, the UBL documents are
>> cryptographically tied to the LN payment.
>>
>> So the property of UBL of not being machine *handlable* is not altered
>> but the LN cryptographic properties are still used to tie the workflow.
>>
>> Am I missing something?
> Sure, people can do this today: simply set your `d` field to "UBL:
> <hash>".
Exactly. But we can add a BOLT which contains 1) references to UBL as a
way to exchange the business information needed in the payer<->payee
interactions and 2) describe the process of tying the document(s) to the
payment(s).
> But it provide what we want from offers:
> 1. Does not provide a "static invoice" flow.
What do you mean by "static invoice" flow? Perhaps:
* Seller -> Buyer: Invoice (UBL)
* Seller -> Buyer: Invoice (LN)
* Buyer & Seller: Payment + Ack (LN)
* Seller -> Buyer: Receipt (UBL)
> 2. Does not provide a donation flow.
* Payer -> Payee: Order (UBL)
* Payee ->Payer: Invoice (LN)
* Payer & Payee: Payment + Ack (LN)
* Payer -> Payer: Receipt (UBL)
> 3. Does not provide a method for wallets to do recurrence.
A simplified workflow can be:
* Seller -> Buyer: Quotation (UBL) containing recurring information
* Buyer -> Seller: Order (UBL) containing recurring information
Then at every beginning/end of period (depending on the info in the
quotation/order)
* Seller -> Buyer: Invoice (UBL)
* Seller -> Buyer: Invoice (LN) (d contain the hash of the invoice +
f(previous docs))
* Buyer & Seller: Payment & Ack (LN)
* Seller -> Buyer: Receipt (UBL)
> 4. Does not provide end-to-end over LN (i.e. no HTTP(s) requests).
Yes as soon as LN support messaging (using [1] or [2] for instance)
--yas
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002275.html
[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002294.html