Yaacov Akiba Slama [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-12 📝 Original message: On 11/11/2019 06:11, ...

📅 Original date posted:2019-11-12
📝 Original message:
On 11/11/2019 06:11, Rusty Russell wrote:
> 2) From a technical point of view, it seems that there are already UBL
> libraries in java and c#. I don't think such library is hard to write in
> go, rust.., so every wallet implementation can use them.
> That is not the problem. The problem is that our order flow is simple:
>
> Seller: Offer
> Buyer: Invoice Request
> Seller: Invoice (or updated Offer)
> Buyer/Seller: Payment & Acknowledgement (atomic)
>
> (This could, of course, fit into a larger business flow.)
>
> The closest UBL flow seems to be:
>
> Seller: Quotation
> Buyer: Order
> Seller: (Prepayment)Invoice (or updated Quotation)

In UBL, 2 flows are defined (Traditional and Self Billing) and from what
I know, the right flow depends on the country and even on the industry
(services or goods for instance). What I suggest is to superpose the
"strict" LN flow (invoice then payment) to the business flow. So for
instance when a prepayment invoice is needed, the simplified (from UBL
pov) flow will be:

  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.


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