Recurrent payments outline about luds HOT 15 OPEN

Instead I propose the following: lnurl-pay returns a field like EXPIRES_IN: , meaning that on that date the service will stop being provided (as in the end of PATIENCE_DAYS in the scheme above). Just that.

+1 for this because of simplicity and flexibility.

I don't like that it gives a service too much capability, in particular service can occasionally reduce next timestamp from being a >year away to, say, 350 days away and hope a careless user won't notice while with recurrence rule the only thing a service can >change is recurrence period (monthly/yearly) which is very noticeable.

Other than that it's more vague than having a recurrence point + patience, does not let user see future payment points in a >calendar (and do some planning based on that if needed), does not seem to make things easier in general.

Perhaps wallets can help here by showing history and the next expiry in the approval screen.

from luds.

We want to be a drop-in replacement/complementation of existing schemes which are based on conventional calendars.

from luds.

The idea of writing code that translates all these weekdays and timezone magic into actual date objects or timestamps frightens me. Can we replace all that with just raw unix timestamps and intervals in seconds instead?

from luds.

I always thought we could count on services keeping balances for users and lnurl-pays just recharging these, and you've included that currentBalance field there for similar purpose.

But now I'm thinking maybe services want to measure that balance in something else than satoshis: "days", for example, or some form of "usage credits", but it also doesn't make sense to include these custom things in the spec.

Instead I propose the following: lnurl-pay returns a field like EXPIRES_IN: <unix timestamp>, meaning that on that date the service will stop being provided (as in the end of PATIENCE_DAYS in the scheme above). Just that.

Then some days before that timestamp the wallet can start prompting the user to pay again, and doing some smart calculations to group that prompt with other prompts that happen to be expiring in a near date.

What am I missing here?

from luds.

The idea of writing code that translates all these weekdays and timezone magic into actual date objects or timestamps frightens me. Can we replace all that with just raw unix timestamps and intervals in seconds instead?

This does not quite work with months because they have varying number of days + leap years. For example, if first payment happens on Jan 31th there's no way to translate it strictly to Feb since it only has 28 days except leap years, that's why RRULE stuff.

It may sound complicated but all languages have specialized Calendar objects which should be relied to do these calculations.

from luds.

That's true. I forgot about those oddities.

But what do you think of the EXPIRES_IN proposal? Using that services can opt to whatever weird interval they want. They can just sell you a subscription for 22 days and a half, and then next time you're paying they change it to 64 days and adjust the price accordingly and so on. And they can do the weird datetime calculations on their servers.

from luds.

Can we also leave out the SERVER_TIMEZONE parameter and just use one singular timezone? Using a unix timestamp is probably best but if it can't be avoided, we should use the +0000 timezone. Not only is it easier to standardize but would also help with privacy.

from luds.

I believe recurrences are appealing and wrong. BOLT12's mistake need not be aped by LNURL.

I mean, which calendar?

https://www.worldatlas.com/articles/calendars-used-around-the-world.html

If BOLT12 finalises some recurrence structure, then adopt it.

from luds.

@fiatjaf

Instead I propose the following: lnurl-pay returns a field like EXPIRES_IN: , meaning that on that date the service will stop being provided (as in the end of PATIENCE_DAYS in the scheme above).

I don't like that it gives a service too much capability, in particular service can occasionally reduce next timestamp from being a year away to, say, 350 days away and hope a careless user won't notice while with recurrence rule the only thing a service can change is recurrence period (monthly/yearly) which is very noticeable.

Other than that it's more vague than having a recurrence point + patience, does not let user see future payment points in a calendar (and do some planning based on that if needed), does not seem to make things easier in general.

@takinbo
Yes and more, on a second thought timezone seems useless: both service and client should define a first recurrence point as their local time and it does not matter if for example the weekday happens to be 3rd Monday of month for client yet still 2nd Sunday for service. What's important is standard calendar software should be relied upon at all times to do these calculations so edge cases like user/service changing a timezone are handled automatically.

@HamishMacEwan

I mean, which calendar?

Gregorian calendar to be compatible with Apple, Google and pretty much every other calendar software.

If BOLT12 finalises some recurrence structure, then adopt it.

Thankfully this work has already been done for us in iCal format, no need to reinvent the wheel.

from luds.

Why not use blockheight as the measure of time?

from luds.

Blockheight would be precise to a resolution of around 10 minutes, and guaranteed to be synchronised across the network.

from luds.

I agree on enforcing UTC for all communication which unix timestamp should cover. Wallet and service GUI can show start/end datetime as they please.

Recurrence point is determined by both WALLET and SERVICE on the day of the first successful payment (SERVER_TIMEZONE is provided to ensure that point is the same for server and client)

I am a little confused on the wording Recurrence point is determined by both WALLET and SERVICE, when considering for instance a substack/gym membership, wallet requests to subscribe and service should return amount to pay and expiry time along with patience_days. This will cover cases like 1st month is free (or a symbolic 1 sat payment) but on 5th of next month user needs to pay.

from luds.

@pseudozach agreed, it's too rigid as currently outlined, first recurrence point should be movable into future.

from luds.

Overall it is expected that WALLET re-queries a static LNURL-PAY after each recurrence point

Perhaps it would be good to somehow send along an identifier tied to the initial lnurl-pay request that the user approved?

from luds.

@aeschylus said

Why not use blockheight as the measure of time?

That's what I ended up using for recurring payments on Oak Node: https://oak-node.net/doc/trunk/doc/bcron.md

The UI translates it to "approximate human time", like "in ~2 days" or "every ~6h".

IMO a blockheight-based approach would be a good starting point for a recurrence spec.

(UTC epoch is also good, the trouble I had there was specifying intervals, from and until. "Every 3rd Monday of the month until end of year" brings back the calendar chaos.)

from luds.