{"type":"rich","version":"1.0","title":"Ross Dyson [ARCHIVE] wrote","author_name":"Ross Dyson [ARCHIVE] (npub1l3…df762)","author_url":"https://yabu.me/npub1l3f8prue677q2neq6ehwpxras2xtj0v7s9zv4a39xpulp09q60hqhdf762","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-11-08\n📝 Original message:\nHi Rusty,\n\nWe spoke in detail about this after your presentation at LNconf. I'm one of\nthe contributors to LNURL so I am a little familiar with what you're trying\nto achieve and am very grateful you're considering implementing something\nsimilar to the mainnet protocol.\n\nI can only see delivery address being a nightmare for the network or wallet\nproviders. If you take a quick look at any Shopify website right now and\ntry to buy something to be delivered you will see validation of address\ninputs before accepting payment.\n\nThis is the 'expected' UX of consumer applications in 2019. If offers were\nto not validate address inputs correctly the user will not receive the\nproduct, lose money, and have a [very] negative review of both the\nwallet-providing and the offer-providing businesses.\n\nHandling these UX expectations will require either the wallet provider or\nthe offer provider to validate the inputs before proceeding with the sale.\n\n   1. If the offer provider handles validation then the network will have\n   to accommodate potentially infinite validation attempts (big no no I assume)\n   2. If the wallet provider were to provide the UX for input validation\n   they are taking on significant workload to develop a robust address input\n   UI, but more importantly the responsibility to correctly validate. There is\n   plenty of room to screw up and create a catastrophic user experience.\n\nSo I think address validation input is only possible via 2. but I think it\nis too much workload and responsibility to expect from wallet providers.\n\u003eFrom what I can see, it would not be impossible to bring delivery address\nfunctionality into offers retroactively after offers was already in prod.\nPerhaps icebox it?\n\nI am very excited for LNOs and LNIs. If we want to get offers in prod and\nbeing facilitated by wallet providers I think it would be best if it was\nstreamlined a little first.\n\nThanks for reading,\n\nRoss\n\nOn Fri, Nov 8, 2019 at 3:40 PM Yaacov Akiba Slama \u003cya at slamail.org\u003e wrote:\n\n\u003e Hi Rusty.\n\u003e\n\u003e On 08/11/2019 05:09, Rusty Russell wrote:\n\u003e \u003e Hi Yaacov,\n\u003e \u003e          I've been pondering this since reading your comment on the PR!\n\u003e \u003e\n\u003e \u003e          As a fan of standards, I am attracted to UBL (I've chaired an\n\u003e \u003e OASIS TC in the past and have great respect for them); as a fan of\n\u003e \u003e simplicity I am not.  Forcing UBL implementation on wallet providers is\n\u003e \u003e simply not going to happen, whatever I were to propose.\n\u003e\n\u003e In fact, using UBL in LN specification is simpler than trying to\n\u003e understand the semantic of each field needed by businesses. You are\n\u003e right that using such a standard put the burden into wallet providers\n\u003e instead of LN developers, but as a wallet (breez) provider, I can say that:\n\u003e\n\u003e 1) Most money transactions (currently in fiat) are between users and\n\u003e companies and not between two users. If we want to replace FIAT by\n\u003e bitcoin, we need to create an infrastructure which can be used by\n\u003e businesses. That means that LN needs to be able to be integrated easily\n\u003e into POS systems. So, as a wallet provider who want to help the\n\u003e transition from fiat to bitcoin, I need to be able to support standards\n\u003e even if that means that I have to implement using/parsing big and\n\u003e complicated standards.\n\u003e\n\u003e For simple user to user transaction, the wallet can decide to use only a\n\u003e subset of the fields defined by the standard.\n\u003e\n\u003e 2) From a technical point of view, it seems that there are already UBL\n\u003e libraries in java and c#. I don't think such library is hard to write in\n\u003e go, rust.., so every wallet implementation can use them.\n\u003e\n\u003e \u003e\n\u003e \u003e       We also don't want duplication; what if the \"UBL field\" were to\n\u003e \u003e say I were selling you a bridge for $1 and the description and amount\n\u003e \u003e fields actually said I was selling you a coffee for $3?\n\u003e \u003e\n\u003e \u003e       However, since invoices/offers and UBL are both structures, we\n\u003e \u003e should have an explicit mapping between the two.  What fields should\n\u003e \u003e have their own existence in the invoice/offer and what should be in a\n\u003e \u003e general UBL field is a question we have to think on further.\n\u003e I agree that we don't want duplication. This is the reason, I propose to\n\u003e use only ubl structure and add in the ln standard invoice an ubl\n\u003e \"opaque\" field which will be self-contained and only add in the\n\u003e invoice/offer/.. the fields specific to ln.\n\u003e \u003e          Anyway, you'll have to bear with me as I read this 172 page\n\u003e \u003e standard...\n\u003e\n\u003e Sure :-)\n\u003e\n\u003e BTW, Thanks a lot for your all your work. LN would not have been where\n\u003e it is without your push.\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191108/24dc4976/attachment.html\u003e"}