Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-11 📝 Original message: Yaacov Akiba Slama <ya at ...
📅 Original date posted:2019-11-11
📝 Original message:
Yaacov Akiba Slama <ya at slamail.org> writes:
> Hi Rusty.
>
> On 08/11/2019 05:09, Rusty Russell wrote:
>> Hi Yaacov,
>> I've been pondering this since reading your comment on the PR!
>>
>> As a fan of standards, I am attracted to UBL (I've chaired an
>> OASIS TC in the past and have great respect for them); as a fan of
>> simplicity I am not. Forcing UBL implementation on wallet providers is
>> simply not going to happen, whatever I were to propose.
>
> In fact, using UBL in LN specification is simpler than trying to
> understand the semantic of each field needed by businesses. You are
> right that using such a standard put the burden into wallet providers
> instead of LN developers, but as a wallet (breez) provider, I can say that:
>
> 1) Most money transactions (currently in fiat) are between users and
> companies and not between two users. If we want to replace FIAT by
> bitcoin, we need to create an infrastructure which can be used by
> businesses. That means that LN needs to be able to be integrated easily
> into POS systems. So, as a wallet provider who want to help the
> transition from fiat to bitcoin, I need to be able to support standards
> even if that means that I have to implement using/parsing big and
> complicated standards.
>
> For simple user to user transaction, the wallet can decide to use only a
> subset of the fields defined by the standard.
>
> 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)
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:
Yaacov Akiba Slama <ya at slamail.org> writes:
> Hi Rusty.
>
> On 08/11/2019 05:09, Rusty Russell wrote:
>> Hi Yaacov,
>> I've been pondering this since reading your comment on the PR!
>>
>> As a fan of standards, I am attracted to UBL (I've chaired an
>> OASIS TC in the past and have great respect for them); as a fan of
>> simplicity I am not. Forcing UBL implementation on wallet providers is
>> simply not going to happen, whatever I were to propose.
>
> In fact, using UBL in LN specification is simpler than trying to
> understand the semantic of each field needed by businesses. You are
> right that using such a standard put the burden into wallet providers
> instead of LN developers, but as a wallet (breez) provider, I can say that:
>
> 1) Most money transactions (currently in fiat) are between users and
> companies and not between two users. If we want to replace FIAT by
> bitcoin, we need to create an infrastructure which can be used by
> businesses. That means that LN needs to be able to be integrated easily
> into POS systems. So, as a wallet provider who want to help the
> transition from fiat to bitcoin, I need to be able to support standards
> even if that means that I have to implement using/parsing big and
> complicated standards.
>
> For simple user to user transaction, the wallet can decide to use only a
> subset of the fields defined by the standard.
>
> 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)
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.