Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-13 📝 Original message: Yaacov Akiba Slama <ya at ...

📅 Original date posted:2019-11-13
📝 Original message:
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)
>
>   Buyer: Receipt (UBL)
>
>
> The advantage of such workflow are that we don't need to add any fields
> to the current invoice structure, nor to define in the LN protocol new
> messages like offer or invoice request, nor to intervene in the semantic
> of the business workflow and in the required/optional fields in these
> messages.

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.

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.
>>