{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-11-11\n📝 Original message:\nRoss Dyson \u003cme at rossdyson.com\u003e writes:\n\u003e Hi Rusty,\n\u003e\n\u003e We spoke in detail about this after your presentation at LNconf. I'm one of\n\u003e the contributors to LNURL so I am a little familiar with what you're trying\n\u003e to achieve and am very grateful you're considering implementing something\n\u003e similar to the mainnet protocol.\n\u003e\n\u003e I can only see delivery address being a nightmare for the network or wallet\n\u003e providers. If you take a quick look at any Shopify website right now and\n\u003e try to buy something to be delivered you will see validation of address\n\u003e inputs before accepting payment.\n\u003e\n\u003e This is the 'expected' UX of consumer applications in 2019. If offers were\n\u003e to not validate address inputs correctly the user will not receive the\n\u003e product, lose money, and have a [very] negative review of both the\n\u003e wallet-providing and the offer-providing businesses.\n\u003e\n\u003e Handling these UX expectations will require either the wallet provider or\n\u003e the offer provider to validate the inputs before proceeding with the sale.\n\u003e\n\u003e    1. If the offer provider handles validation then the network will have\n\u003e    to accommodate potentially infinite validation attempts (big no no I assume)\n\u003e    2. If the wallet provider were to provide the UX for input validation\n\u003e    they are taking on significant workload to develop a robust address input\n\u003e    UI, but more importantly the responsibility to correctly validate. There is\n\u003e    plenty of room to screw up and create a catastrophic user experience.\n\u003e\n\u003e So I think address validation input is only possible via 2. but I think it\n\u003e is too much workload and responsibility to expect from wallet providers.\n\nThis is not the area I worry about, TBH, since every shopping website in\nexistence has implemented address input (and some form of validation).\nI'm sure it'll be primitive to start with.\n\nOf course, UBL has a standard 'AddressType' too:\n\n        http://docs.oasis-open.org/ubl/os-UBL-2.2/xsd/common/UBL-CommonAggregateComponents-2.2.xsd\n\n\u003e\u003eFrom what I can see, it would not be impossible to bring delivery address\n\u003e functionality into offers retroactively after offers was already in prod.\n\u003e Perhaps icebox it?\n\nQuite possibly something we can delay; most current goods are virtual\nanyway.  However, delivery address standardization would greatly improve\nthe UX for such things.\n\nCheers,\nRusty."}
