Should allowances / autopayments be a part of WebLN?

[wbobeirne]

This is an open discussion as to whether or not some concept of prompting the user to setup an allowance / auto-pay with the app should be handled at the client level, or the WebLN level.

I'll start: I've got an issue open over on Joule https://github.com/wbobeirne/joule-extension/issues/42 for adding auto-payments. The WebLN spec actually works no problem with this, since simple sendPayment calls can be executed without prompting the user.

However, having each client do it differently can cause some uncertainties for apps and what the user experience is going to be. If you wanted to, say, charge a user 1 satoshi per second of video they watched, that would be a terrible experience with the Joule of today. You'd want to make sure the user wasn't constantly getting interrupted. Likewise, it'd be nice for the app to see your allowance, and warn you / remind you to top it off before you get empty and are interrupted in the middle of something.

Open to all feedback!

[jnewbery]

My view: yes, this should be part of webln.

One reason is that the application can know in advance how much to ask for in an allowance. For your example of the video, the server could ask for an allowance that covered the entire length of the video, and then take per-second payments. If webln didn't include a mechanism for requesting allowances, the client application (Joule) would have to guess how much of an allowance to ask the user for.

[MikeD123]

+1 @jnewbery

I feel like it would be great to treat allowance just like typical security tiers on custodial wallets. E.g. Sending > X requires 2FA.

Pain points from other networks (e.g ETH)

• Service provider --> Poorer conversion rates.
• No defaults by design --> Wasted costs on gas permitting allowances.

Quick high level.

export interface allowance {
// Global default setting for any interaction. Could set a flag for this to be private or public by default, and/or relative to proximity.
  nodeDefault?: number | number;  
  channelDefault?: string | number; // Specify defaults for repeat usage. E.g. Spotify vs Netflix 
  allowanceRefresh?: number; // Elapsed time required before a limit can be refreshed. 
  proximityDefault?: number; // number of hops away request is coming from.   
}

Any feedback on the following

• Settings for privacy surrounding defaults?
• Settings regarding proximity as a global setting? Balance between scalable risk mitigation and UX for new service providers. Would also encourage more connections amongst one another?

This already may be solved and sorted as it's almost a month ago since mentioned. Apologies if so, but keep up the awesome work!

[ziggamon]

I agree w/ above speakers, automatic/recurring/etc payments is something very needed.

Obviously with good security settings and such, but if it's not in place then that would in deed draw people to centralized solutions. And lack of recurring payments is definitely something that has held back payments adoption.

Would be super glad to work with you on this and trying it out with Bitrefill.

[wbobeirne]

@MikeD123 this is all still WIP so thanks for the suggestions. I have some feedback:

• I think it'd be hard to bake routing into the allowance (channelDefault, proximityDefault) since you'll most likely just take the most optimal route depending on fees and capacity available.
• I had also planned to have routing fees count against the allowance to avoid some kind of high-fee / small tx exploit (A bunch of 1 satoshi transactions made with 100+ satoshi fees.)
• WRT privacy, I would only reveal to sites allowances that would apply to them. If you wanted to inspect a user's allowances (e.g. some kind of getAllowances call), at least for Joule's implementation, it would match against the requester's origin & pubkey and only show allowances that are setup with that origin & pubkey combination.

I still feel that interface would require a lot more information to be useful for applications to know the bounds of the allowance, so I'd also like to see information to the tune of:

export interface Allowance {
  total: string;              // 64 bit int of amount of money initially setup for the allowance
  remaining: string;          // 64 bit int of amount of money left before refresh
  pubkeyWhitelist?: string[]; // List of node pubkeys that this allowance applies to. If list is undefined, allows transactions to any node.
  timeToRefresh?: number;     // Time in seconds until the allowance refreshes. Only provided if allowance is configured to auto-refresh.
  refreshInterval?: number;   // Time in seconds between allowance refreshes. Only provided if allowance is configured to auto-refresh.
}

---

@ziggamon Recurring payments ala subscriptions is totally something I want to tackle as well, but I look at them as being a little different. I think they'll take the shape of a limited access macaroon that the subscription service holds and charges you with every month. It'd be limited to the monthly fee amount. However, I don't think LND is there yet in terms of macaroon generation and customizability.

This spec is more about seamless payments, so still the traditional model of click something -> buy something, but without the whole modal / enter password / confirm transaction

[MikeD123]

@wbobeirne

Yup, I agree. Just wanted to get something down to jump-start the feedback. Appreciate you dropping in yours

Motivation for allowances to me is

• Protect the end-user from bad actor service providers abusing the "debit" style privilege.
• Streamline UX in the same time.

The way that I see it, allowance is at a few levels...

Alice
- Global - // Default allowance for any new service provider looking to interact. 0 is an allowance.
  - Service - SubmarineDEX // Service providing the swap to other assets. Allowance 1000 satoshis
    - ServiceDetail - SubmarineDEX LTCBTC // Specific variant of the service provided. E.g with exchange it would be a trade pair. Gaming would be a specific game, etc...

// Am I missing the mark a little? Np if so. 😄

refreshInterval?: number;   // Time in seconds between allowance refreshes. Only provided if allowance is configured to auto-refresh.

// Should this say is not configured to auto-refresh?

Sorry for all the questions, and appreciate the patience if I'm on the wrong page.

[wbobeirne]

Circling back around to the implementation for this in Joule. Sorry I didn't get to your questions earlier, I had put allowances on the backburner:

The way that I see it, allowance is at a few levels...

This should ideally be opaque from the spec. The WebLN provider can decide how it breaks up allowances, the app should simply ask for what they're allowed. In the case of Joule, I'm going to be doing it per-domain, and seeing if any other noteworthy use-cases arrive. But I expect that should cover the majority of them.

// Should this say is not configured to auto-refresh?

No, my intent here was that if there was no auto-refresh, you wouldn't tell them how frequently. I'm thinking for a first iteration of this though, I'm going to exclude all auto-refresh stuff from it. If multiple clients all come together on what that might look like, we can spec it out together later.

[MikeD123]

Sorry I didn't get to your questions earlier

Dude - Don't sweat it. You're busy, keep crushing it 😊Amazing work for the community (Thank you).

web3 allowance usage is non-existent really. It's obfuscated and just "max'd out" (e.g. make it 99999999999) so you never hear from it again. This is bad practice, and it's formed out of necessity. Having a default baked into the standard will mitigate risk for first time interactions with an application, without dismissing it all together IMO.

In the case of Joule, I'm going to be doing it per-domain, and seeing if any other noteworthy use-cases arrive. But I expect that should cover the majority of them.

Would domain literally be the domain URL? Or Node Channel? Just clarifying...

Thank you!