search

joule-labs / webln

Spec and client library for WebLN apps and providers
244 stars 28 forks source link

Add ability to send multiple keysend payments at the same time #61

Open ericpp opened 4 months ago

ericpp commented 4 months ago

It would be nice to have a way to send multiple keysend payments at the same time, similar to: https://guides.getalby.com/developer-guide/v/alby-wallet-api/reference/api-reference/payments#multi-keysend-payment

This would allow WebLN providers like Alby to authorize multiple keysend payments at the same time rather than authorizing each one separately. This is particularly annoying with Alby which opens a popup window for each keysend payment, requiring the user to click the Authorize button over and over again.

wbobeirne commented 4 months ago

Can you give a little more context around your use-case? When might a user want to issue multiple keyspends all at once, as opposed to oncer per action?

ericpp commented 4 months ago

It would be particularly useful for Podcasting 2.0 boosts where a single boost is split amongst the podcast hosts and contributors. For example, this podcast has 9 splits, which results in Alby popping up an authorization popup 9 times: https://podcastindex.org/podcast/920666

It would be nice to have a multiple keysend command that would let WebLN clients authorize all payments at once.

amcquade commented 4 months ago

this would be an awesome feature :)

wbobeirne commented 4 months ago

Interesting, this is the first time I've seen a split payment UX like that! Forgive my ignorance, but I've got a bunch of questions about this, some of which is related to how an API like this might look:

  1. Are there any proposals or future enhancements that would allow it to appear as a single payment, but have it split to multiple nodes?
    • Basically, is it worth making a new method today for something that might be solved more elegantly tomorrow by something like BOLT-12?
  2. What might the UX be for a non-WebLN user, or a WebLN user with a client that doesn't support this method?
  3. Should the user be able to opt in to some of the payments, but not others? Like a list of checkboxes?
  4. How would you expect users to be made aware of the differences in fees between the payments?
  5. What would you expect the behavior to be if some payments cannot be routed, or the some of the payments fail, but others can be routed / succeed?

I typically like to think of features holistically end to end, not just the WebLN method, to make sure it's well understood what clients are expected to be responsible for, and what the ideal UX should be for them in implementing a method, and how web developers should handle the "degraded" experience for users without a WebLN client.

ericpp commented 4 months ago

Interesting, this is the first time I've seen a split payment UX like that! Forgive my ignorance, but I've got a bunch of questions about this, some of which is related to how an API like this might look:

  1. Are there any proposals or future enhancements that would allow it to appear as a single payment, but have it split to multiple nodes?

    • Basically, is it worth making a new method today for something that might be solved more elegantly tomorrow by something like BOLT-12?

I'm not aware of any proposals, but I'm also not fully up-to-date on BOLT-12

  1. What might the UX be for a non-WebLN user, or a WebLN user with a client that doesn't support this method?

The code performing the send would have to check to see if the webln.multiKeysend function exists and fall back to webln.keysend if it doesn't. Non-WebLN software would probably just use a keysend in a loop, but typically non-WebLN software doesn't require the same user interaction to send payments.

  1. Should the user be able to opt in to some of the payments, but not others? Like a list of checkboxes?

The code performing the send could handle this before calling webln.multiKeysend and pass in only the addresses that the user picked.

  1. How would you expect users to be made aware of the differences in fees between the payments?
  2. What would you expect the behavior to be if some payments cannot be routed, or the some of the payments fail, but others can be routed / succeed?

The return of that function could be an array with the payment hashes and final statuses for each address along with the fees that were assessed.

I typically like to think of features holistically end to end, not just the WebLN method, to make sure it's well understood what clients are expected to be responsible for, and what the ideal UX should be for them in implementing a method, and how web developers should handle the "degraded" experience for users without a WebLN client.

I should point out that I'm not a developer for Alby. I just thought it would be nice to have this feature to make it easier to send Podcasting 2.0 split payments (or anything else that implements split payments).