{"type":"rich","version":"1.0","title":"Yaacov Akiba Slama [ARCHIVE] wrote","author_name":"Yaacov Akiba Slama [ARCHIVE] (npub1z0…at6uz)","author_url":"https://yabu.me/npub1z07sgdx84scq77jx3fddj3jt0w2w3vpa0t5gyk0nmcaggs3gyt7s6at6uz","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-11-12\n📝 Original message:\nOn 11/11/2019 06:11, Rusty Russell wrote:\n\u003e 2) From a technical point of view, it seems that there are already UBL \n\u003e libraries in java and c#. I don't think such library is hard to write in \n\u003e go, rust.., so every wallet implementation can use them.\n\u003e That is not the problem.  The problem is that our order flow is simple:\n\u003e\n\u003e         Seller: Offer\n\u003e         Buyer: Invoice Request\n\u003e         Seller: Invoice (or updated Offer)\n\u003e         Buyer/Seller: Payment \u0026 Acknowledgement (atomic)\n\u003e\n\u003e (This could, of course, fit into a larger business flow.)\n\u003e\n\u003e The closest UBL flow seems to be:\n\u003e\n\u003e         Seller: Quotation\n\u003e         Buyer: Order\n\u003e         Seller: (Prepayment)Invoice (or updated Quotation)\n\nIn UBL, 2 flows are defined (Traditional and Self Billing) and from what\nI know, the right flow depends on the country and even on the industry\n(services or goods for instance). What I suggest is to superpose the\n\"strict\" LN flow (invoice then payment) to the business flow. So for\ninstance when a prepayment invoice is needed, the simplified (from UBL\npov) flow will be:\n\n  Seller: Quotation (UBL)\n\n  Buyer: Order (UBL)\n\n  Seller: Prepayment Invoice (UBL)\n\n  Seller: Invoice (LN)\n\n  Buyer/Seller: Payment \u0026 Ack (LN)\n\n  Buyer: Receipt (UBL)\n\n\nThe advantage of such workflow are that we don't need to add any fields\nto the current invoice structure, nor to define in the LN protocol new\nmessages like offer or invoice request, nor to intervene in the semantic\nof the business workflow and in the required/optional fields in these\nmessages.\n\n\n\u003e\n\u003e It's also worth noting that, even compressed, none of the UBL examples\n\u003e fit into the 1023 byte limit of the existing invoice format:\n\u003e\n\u003e         UBL-Quotation-2.1-Example.xml: 1864 bytes (gz)\n\u003e         UBL-Order-2.1-Example.xml: 2515 bytes (gz)\n\u003e         UBL-Invoice-2.1-Example.xml: 3163 bytes (gz)\n\u003e\n\u003e Indeed, that Quotation alone requires a 32x32 QR code.\n\u003e\n\u003e\u003e\u003e \tHowever, since invoices/offers and UBL are both structures, we\n\u003e\u003e\u003e should have an explicit mapping between the two.  What fields should\n\u003e\u003e\u003e have their own existence in the invoice/offer and what should be in a\n\u003e\u003e\u003e general UBL field is a question we have to think on further.\n\u003e\u003e I agree that we don't want duplication. This is the reason, I propose to \n\u003e\u003e use only ubl structure and add in the ln standard invoice an ubl \n\u003e\u003e \"opaque\" field which will be self-contained and only add in the \n\u003e\u003e invoice/offer/.. the fields specific to ln.\n\u003e Except we need to go through the UBL spec and indicate exactly what\n\u003e fields are permitted, and which are required.\n\u003e\n\u003e Many UBI fields are not amenable to machine interpretation (eg. note\n\u003e fields).  These must be either explicitly exposed to the buyer (in case\n\u003e the seller uses them) such as shipping conditions, or explicitly\n\u003e forbidden/ignored.\n\u003e\n\u003e This is not a small task, and required intimiate knowledge of the UBL\n\u003e spec.  It's not enough just to make something *look* like UBL.\n\u003e\n\u003e Does anyone have expertise in this area?  Shall we form a sub-group to\n\u003e investigate this properly?\n\u003e\n\u003e Thanks!\n\u003e Rusty.\n\u003e"}