rich1.0Ross Dyson [ARCHIVE] (npub1l3…df762)https://yabu.me/npub1l3f8prue677q2neq6ehwpxras2xtj0v7s9zv4a39xpulp09q60hqhdf762njumphttps://yabu.me📅 Original date posted:2019-11-08 📝 Original message: Hi Rusty, We spoke in detail about this after your presentation at LNconf. I'm one of the contributors to LNURL so I am a little familiar with what you're trying to achieve and am very grateful you're considering implementing something similar to the mainnet protocol. I can only see delivery address being a nightmare for the network or wallet providers. If you take a quick look at any Shopify website right now and try to buy something to be delivered you will see validation of address inputs before accepting payment. This is the 'expected' UX of consumer applications in 2019. If offers were to not validate address inputs correctly the user will not receive the product, lose money, and have a [very] negative review of both the wallet-providing and the offer-providing businesses. Handling these UX expectations will require either the wallet provider or the offer provider to validate the inputs before proceeding with the sale. 1. If the offer provider handles validation then the network will have to accommodate potentially infinite validation attempts (big no no I assume) 2. If the wallet provider were to provide the UX for input validation they are taking on significant workload to develop a robust address input UI, but more importantly the responsibility to correctly validate. There is plenty of room to screw up and create a catastrophic user experience. So I think address validation input is only possible via 2. but I think it is too much workload and responsibility to expect from wallet providers. >From what I can see, it would not be impossible to bring delivery address functionality into offers retroactively after offers was already in prod. Perhaps icebox it? I am very excited for LNOs and LNIs. If we want to get offers in prod and being facilitated by wallet providers I think it would be best if it was streamlined a little first. Thanks for reading, Ross On Fri, Nov 8, 2019 at 3:40 PM Yaacov Akiba Slama <ya at slamail.org> wrote: > 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. > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191108/24dc4976/attachment.html>