[Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

Rusty Russell rusty at rustcorp.com.au
Mon Nov 11 04:26:38 UTC 2019


Ross Dyson <me at rossdyson.com> 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.


More information about the Lightning-dev mailing list