From rusty at rustcorp.com.au Mon Nov 11 04:26:38 2019 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 11 Nov 2019 14:56:38 +1030 Subject: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers In-Reply-To: References: <87zhhb2bpf.fsf@rustcorp.com.au> <798f31a2-fb53-a7ce-4bd6-ef06102eebba@slamail.org> <877e4bt678.fsf@rustcorp.com.au> <857a3203-6f85-b40a-9d7a-bee320180a32@slamail.org> Message-ID: <87woc7ox6p.fsf@rustcorp.com.au> Ross Dyson writes: > 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. This is not the area I worry about, TBH, since every shopping website in existence has implemented address input (and some form of validation). I'm sure it'll be primitive to start with. Of course, UBL has a standard 'AddressType' too: http://docs.oasis-open.org/ubl/os-UBL-2.2/xsd/common/UBL-CommonAggregateComponents-2.2.xsd >>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? Quite possibly something we can delay; most current goods are virtual anyway. However, delivery address standardization would greatly improve the UX for such things. Cheers, Rusty.