{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-11-29\n📝 Original message:RE: Roy Badami's comments on edge cases around submitting a Payment\nmessage to a merchant and then not receiving a timely response:\n\nI agree, it is messy.\n\nI'm hesitant to try to specify One True Way of handling it in the\nspec; I've got a feeling that this might be a place where different\nimplementations might try different things, with the best\nimplementation winning.\n\nFor example, if some future nifty-keen Bitcoin client is re-using an\nold Invoice to send a monthly subscription payment and they can't\ncontact the paymentURI, then the right thing is probably for it to\nretry once a day for three or four days and if they all fail then give\nup and tell the user that the service is no longer in business (or\nchanged their paymentURI without leaving behind a redirect).\n\nIf it has a single-use Invoice created a minute or two ago, the right\nlogic might be:\n  + If the paymentURI is completely non-responsive, just error and\ntell the user \"payment failed\"\n  + If connected to the paymentURI and payment sent, but disconnected\nbefore receiving a response, then try to send-to-self the coins to\ncancel payment.\n\nAgain, I'm not at all sure that is the best way to handle it;\nimplementors have the right incentives to give their users the best\nuser experience, so I feel comfortable leaving the spec fuzzy for now.\n\n-- \n--\nGavin Andresen"}