Yaacov Akiba Slama [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-13 📝 Original message: On 13/11/2019 05:44, ...
📅 Original date posted:2019-11-13
📝 Original message:
On 13/11/2019 05:44, Rusty Russell wrote:
> Yaacov Akiba Slama <ya at slamail.org> writes:
>> Seller: Quotation (UBL)
>>
>> Buyer: Order (UBL)
>>
>> Seller: Prepayment Invoice (UBL)
>>
>> Seller: Invoice (LN)
>>
>> Buyer/Seller: Payment & Ack (LN)
>>
>> Seller: Receipt (UBL)
>>
>
> This would be UBL treating Lightning as a dumb payment layer, which is a
> little like faxing email, and not a use case I'd be promoting for
> Lightning.
I don't understand the comparison. Both email an fax are way to transmit
data and are not related to the *content* of what is transmitted.
Consequently email and fax are in competing as a way to transmit data.
But LN and UBL (as I understand them) are not in competition because:
* LN is a messaging protocol (soon) and a payment protocol.
* UBL is a protocol defining business interaction workflow *around*
payments.
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?
--yas
>
> To be clear: the full UBL spec is machine *parsable* but definitely not
> designed to be machine *handlable*. This makes sense, since a machine
> cannot generally choose between quotations or interpret general contract
> terms.
>
> However, for the simpler (but very common!) case of an offer->purchase
> flow, we can define a subset of UBL for which this *can* be done, and a
> further-limited subset which must be examined by the user
> (e.g. description of goods, price details, shipping info).
>
> In addition, the atomic nature of LN needs to be baked into the
> protocol; in LN taking the payment *requires* a cryptographic receipt,
> and neutering this property would be horribly short-sighted.
>
> We need to define UBL extensions for the LN fields to tie them all
> together (e.g. payment_hash, node_id). We also need to define a
> transport mechanism for these over the Lightning Network.
>
> This is all quite possible! But it will take time and is a signficant
> amount of work: I need to be sure that others feel the same way before I
> embark on this project.
>
> Cheers,
> Rusty.
>
>>> It's also worth noting that, even compressed, none of the UBL examples
>>> fit into the 1023 byte limit of the existing invoice format:
>>>
>>> UBL-Quotation-2.1-Example.xml: 1864 bytes (gz)
>>> UBL-Order-2.1-Example.xml: 2515 bytes (gz)
>>> UBL-Invoice-2.1-Example.xml: 3163 bytes (gz)
>>>
>>> Indeed, that Quotation alone requires a 32x32 QR code.
>>>
>>>>> However, since invoices/offers and UBL are both structures, we
>>>>> should have an explicit mapping between the two. What fields should
>>>>> have their own existence in the invoice/offer and what should be in a
>>>>> general UBL field is a question we have to think on further.
>>>> I agree that we don't want duplication. This is the reason, I propose to
>>>> use only ubl structure and add in the ln standard invoice an ubl
>>>> "opaque" field which will be self-contained and only add in the
>>>> invoice/offer/.. the fields specific to ln.
>>> Except we need to go through the UBL spec and indicate exactly what
>>> fields are permitted, and which are required.
>>>
>>> Many UBI fields are not amenable to machine interpretation (eg. note
>>> fields). These must be either explicitly exposed to the buyer (in case
>>> the seller uses them) such as shipping conditions, or explicitly
>>> forbidden/ignored.
>>>
>>> This is not a small task, and required intimiate knowledge of the UBL
>>> spec. It's not enough just to make something *look* like UBL.
>>>
>>> Does anyone have expertise in this area? Shall we form a sub-group to
>>> investigate this properly?
>>>
>>> Thanks!
>>> Rusty.
>>>
📝 Original message:
On 13/11/2019 05:44, Rusty Russell wrote:
> Yaacov Akiba Slama <ya at slamail.org> writes:
>> Seller: Quotation (UBL)
>>
>> Buyer: Order (UBL)
>>
>> Seller: Prepayment Invoice (UBL)
>>
>> Seller: Invoice (LN)
>>
>> Buyer/Seller: Payment & Ack (LN)
>>
>> Seller: Receipt (UBL)
>>
>
> This would be UBL treating Lightning as a dumb payment layer, which is a
> little like faxing email, and not a use case I'd be promoting for
> Lightning.
I don't understand the comparison. Both email an fax are way to transmit
data and are not related to the *content* of what is transmitted.
Consequently email and fax are in competing as a way to transmit data.
But LN and UBL (as I understand them) are not in competition because:
* LN is a messaging protocol (soon) and a payment protocol.
* UBL is a protocol defining business interaction workflow *around*
payments.
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?
--yas
>
> To be clear: the full UBL spec is machine *parsable* but definitely not
> designed to be machine *handlable*. This makes sense, since a machine
> cannot generally choose between quotations or interpret general contract
> terms.
>
> However, for the simpler (but very common!) case of an offer->purchase
> flow, we can define a subset of UBL for which this *can* be done, and a
> further-limited subset which must be examined by the user
> (e.g. description of goods, price details, shipping info).
>
> In addition, the atomic nature of LN needs to be baked into the
> protocol; in LN taking the payment *requires* a cryptographic receipt,
> and neutering this property would be horribly short-sighted.
>
> We need to define UBL extensions for the LN fields to tie them all
> together (e.g. payment_hash, node_id). We also need to define a
> transport mechanism for these over the Lightning Network.
>
> This is all quite possible! But it will take time and is a signficant
> amount of work: I need to be sure that others feel the same way before I
> embark on this project.
>
> Cheers,
> Rusty.
>
>>> It's also worth noting that, even compressed, none of the UBL examples
>>> fit into the 1023 byte limit of the existing invoice format:
>>>
>>> UBL-Quotation-2.1-Example.xml: 1864 bytes (gz)
>>> UBL-Order-2.1-Example.xml: 2515 bytes (gz)
>>> UBL-Invoice-2.1-Example.xml: 3163 bytes (gz)
>>>
>>> Indeed, that Quotation alone requires a 32x32 QR code.
>>>
>>>>> However, since invoices/offers and UBL are both structures, we
>>>>> should have an explicit mapping between the two. What fields should
>>>>> have their own existence in the invoice/offer and what should be in a
>>>>> general UBL field is a question we have to think on further.
>>>> I agree that we don't want duplication. This is the reason, I propose to
>>>> use only ubl structure and add in the ln standard invoice an ubl
>>>> "opaque" field which will be self-contained and only add in the
>>>> invoice/offer/.. the fields specific to ln.
>>> Except we need to go through the UBL spec and indicate exactly what
>>> fields are permitted, and which are required.
>>>
>>> Many UBI fields are not amenable to machine interpretation (eg. note
>>> fields). These must be either explicitly exposed to the buyer (in case
>>> the seller uses them) such as shipping conditions, or explicitly
>>> forbidden/ignored.
>>>
>>> This is not a small task, and required intimiate knowledge of the UBL
>>> spec. It's not enough just to make something *look* like UBL.
>>>
>>> Does anyone have expertise in this area? Shall we form a sub-group to
>>> investigate this properly?
>>>
>>> Thanks!
>>> Rusty.
>>>