Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-11 📝 Original message: Ross Dyson <me at ...
📅 Original date posted:2019-11-11
📝 Original message:
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.
📝 Original message:
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.