{"type":"rich","version":"1.0","author_name":"npub1d7e068ud72v0au6xf53qvek44eccfhlgnhzuclf6za6hnxrvx89sc93exj","author_url":"https://nostr.ae/npub1d7e068ud72v0au6xf53qvek44eccfhlgnhzuclf6za6hnxrvx89sc93exj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-12-15\n📝 Original message:\nOn Wed, Dec 15, 2021 at 01:59:49PM -0800, William Casarin wrote:\n\u003eHey Ronan,\n\u003e\n\u003eOn Wed, Dec 15, 2021 at 05:33:51PM +0000, Ronan McGovern wrote:\n\u003e\u003eIf not, what would be required to develop this?\n\u003e\u003e* A protocol change?\n\u003e\u003e* Could it be built with the current protocol (I see an app on LN Bits to\n\u003e\u003esplit but it doesn't seem to work).\n\u003e\n\u003eThis is typically done at the application level. The fountain podcasting\n\u003eapp works this way and it seems to work okish.\n\nThe tricky part is what to do when the payment partially fails. Perhaps\nyou keep trying with exponential backoff until the payment completes for\nall parties. If this was handled at the protocol level, would you fail\nthe entire transaction if one of the channels failed? This is the kind\nof business logic that would be tricky when designing a protocol-level\nsolution to this.\n\nI think it's reasonable to handle this at the application level for now,\nbut perhaps some standard protocols might be useful in the future.\n\nCheers,\nWill"}