📅 Original date posted:2019-11-08
📝 Original message:
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.
>
> We also don't want duplication; what if the "UBL field" were to
> say I were selling you a bridge for $1 and the description and amount
> fields actually said I was selling you a coffee for $3?
>
> 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.
> Anyway, you'll have to bear with me as I read this 172 page
> standard...
Sure :-)
BTW, Thanks a lot for your all your work. LN would not have been where
it is without your push.
Yaacov Akiba Slama [ARCHIVE] /
npub1z0…at6uz
2023-06-09 12:57:17
in reply to nevent1q…rh0c
Author Public Key
npub1z07sgdx84scq77jx3fddj3jt0w2w3vpa0t5gyk0nmcaggs3gyt7s6at6uzPublished at
2023-06-09 12:57:17Event JSON
{
"id": "0224c8ce9ab9997c455b9c42b15c4ff87959acccf5a225bf23d5934a71ea5b07",
"pubkey": "13fd0434c7ac300f7a468a5ad9464b7b94e8b03d7ae88259f3de3a84422822fd",
"created_at": 1686315437,
"kind": 1,
"tags": [
[
"e",
"a9016896e78ef5f5473204edd89280667686b471d7f529d125afce8e0e678ed9",
"",
"root"
],
[
"e",
"bacc2d9487d17fbf868427f20fe6e28693443c5fa9f57e5d449485ef01cf3327",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2019-11-08\n📝 Original message:\nHi Rusty.\n\nOn 08/11/2019 05:09, Rusty Russell wrote:\n\u003e Hi Yaacov,\n\u003e I've been pondering this since reading your comment on the PR!\n\u003e\n\u003e As a fan of standards, I am attracted to UBL (I've chaired an\n\u003e OASIS TC in the past and have great respect for them); as a fan of\n\u003e simplicity I am not. Forcing UBL implementation on wallet providers is\n\u003e simply not going to happen, whatever I were to propose.\n\nIn fact, using UBL in LN specification is simpler than trying to \nunderstand the semantic of each field needed by businesses. You are \nright that using such a standard put the burden into wallet providers \ninstead of LN developers, but as a wallet (breez) provider, I can say that:\n\n1) Most money transactions (currently in fiat) are between users and \ncompanies and not between two users. If we want to replace FIAT by \nbitcoin, we need to create an infrastructure which can be used by \nbusinesses. That means that LN needs to be able to be integrated easily \ninto POS systems. So, as a wallet provider who want to help the \ntransition from fiat to bitcoin, I need to be able to support standards \neven if that means that I have to implement using/parsing big and \ncomplicated standards.\n\nFor simple user to user transaction, the wallet can decide to use only a \nsubset of the fields defined by the standard.\n\n2) From a technical point of view, it seems that there are already UBL \nlibraries in java and c#. I don't think such library is hard to write in \ngo, rust.., so every wallet implementation can use them.\n\n\u003e\n\u003e \tWe also don't want duplication; what if the \"UBL field\" were to\n\u003e say I were selling you a bridge for $1 and the description and amount\n\u003e fields actually said I was selling you a coffee for $3?\n\u003e\n\u003e \tHowever, since invoices/offers and UBL are both structures, we\n\u003e should have an explicit mapping between the two. What fields should\n\u003e have their own existence in the invoice/offer and what should be in a\n\u003e general UBL field is a question we have to think on further.\nI agree that we don't want duplication. This is the reason, I propose to \nuse only ubl structure and add in the ln standard invoice an ubl \n\"opaque\" field which will be self-contained and only add in the \ninvoice/offer/.. the fields specific to ln.\n\u003e Anyway, you'll have to bear with me as I read this 172 page\n\u003e standard...\n\nSure :-)\n\nBTW, Thanks a lot for your all your work. LN would not have been where \nit is without your push.",
"sig": "1704d3e2373e22ca62d8a0589b4bbfef1d622b6b077914838ae533b9e556df959bee5940bf470c387d95234e421848a276a2915e0bd170ae9d6eb09546159f2a"
}