Recurring Subscriptions

[pablof7z]

NIP to implement Patreon-style support.

Adds a way to:

• Create support tiers (kind:7002)
• Subscribe to support tiers (kind:7001)

Viewable: https://github.com/nostr-protocol/nips/blob/nip88/88.md

[vitorpamplona]

Very cool!

I'd like to see a way to tell the NWC service (or a DVM) to keep paying the 7001 event until that event gets deleted.

It must be a service to avoid missing payments (in case the user doesn't open a client on that day) and also avoid double payments in case the zap event disappears (relay is offline or busy for a day or so).

[benthecarman]

This could be a problem, most relays don't support this AFAIK. Also a subscribed user's client might just think the relay is acting up, not that the subscription is over.

I think it'd be better if there was a revoke event, it could have an e tag that points to the new tier that replaces it.

[AnthonyRonning]

Echo some of the concerns, plus another one: historical references. The user was a subscriber for X months, for example. That might be useful for both accounting and reputation, in addition to possible content that could still be accessed from those months if someone chooses to do a newsletter/patreon client but let users keep what they paid for during the subscription time.

Another possible approach:

Could we just have the client stop zapping? I can see the usefulness in having a nostr native event to trigger the start of the subscription, but since verification depends upon analyzing the zaps to check if sub'd, couldn't we just have the user stop zapping? If they gave out an NWC string, then some user action might be required anyways to make sure the service stops withdrawing anyways despite a deleted 7001.

[pablof7z]

yeah, that's the thing, we need a way for different clients to know they shouldn't continue zapping.

Yeah, some kind of flagging would probably be better than an kind:5 which has broader implications.

[AnthonyRonning]

Approach sounds great, thank you for drawing it up! Just a few edge cases and thoughts around changing prices and keeping historical references.

[AnthonyRonning]

How should changing the amount happen? A new 7002 ? Replace it? Reference the previous 7002 in the new 7002?

The question of reasoning here is to consider what might happen if denominated in sats and need to change that with huge price changes, or standard repricing of services.

I wonder how to:

1. historically track subscriptions previously no matter what the prices might have changed to
2. indiciate to the user that the previous pricing model has changed and they SHOULD NOT zap with the previous price without creating a new 7001 at least.

[pablof7z]

I think it might just make sense to move this to NIP-33 events and the 7001 should e tag the version it's subscribed to.

[AnthonyRonning]

Echo some of the concerns, plus another one: historical references. The user was a subscriber for X months, for example. That might be useful for both accounting and reputation, in addition to possible content that could still be accessed from those months if someone chooses to do a newsletter/patreon client but let users keep what they paid for during the subscription time.

Another possible approach:

Could we just have the client stop zapping? I can see the usefulness in having a nostr native event to trigger the start of the subscription, but since verification depends upon analyzing the zaps to check if sub'd, couldn't we just have the user stop zapping? If they gave out an NWC string, then some user action might be required anyways to make sure the service stops withdrawing anyways despite a deleted 7001.

[AnthonyRonning]

@vitorpamplona

I'd like to see a way to tell the NWC service (or a DVM) to keep paying the 7001 event until that event gets deleted.

I would love to see some NWC interactions as well, though I'm concerned about it triggering based on seeing something end it. We can't guarantee the wallet is going to see deleted events or the stop event if we take @benthecarman's suggestion.

[benthecarman]

While I agree that nwc should be used for giving invoices to the user, I don't see where it really fits into this nip outside of a recommendation section.

Maybe this nip should be incorporated into #851 somehow. Like tagging which subscription event you are creating the nwc for.

[vitorpamplona]

Creating the 7001 event and sending to the NWC relay could mean that the NWC service is authorized by the user to get an invoice and pay that invoice in the appropriate cadence.

Or maybe it's just an extra event that has the 7001 inside of it that tells the NWC service to pay periodically.

However, I'd like to see a way to tag which NWC service is authorized to pay each subscription in case the user has multiple NWC services setup.

[AnthonyRonning]

Creating the 7001 event and sending to the NWC relay could mean that the NWC service is authorized by the user to get an invoice and pay that invoice in the appropriate cadence.

Or maybe it's just an extra event that has the 7001 inside of it that tells the NWC service to pay periodically.

However, I'd like to see a way to tag which NWC service is authorized to pay each subscription in case the user has multiple NWC services setup.

There's not really a concept of NWC services on a nostr level yet, I feel that it would be out of scope for this NIP. And any person can forward an event to "an NWC relay" (which there also isn't an exclusive concept of) so I don't think that would work either.

[vitorpamplona]

There's not really a concept of NWC services on a nostr level yet,

The NWC wallet service replies to payment requests with signed events (kind:23195). The pubkey used for those responses could be used to identify which NWC service is supposed to be paying the 9001 subscription. We could add that key directly as a tag in the 9001.

Clients already use that key to identify the NWC wallet service. So that could be very easy to integrate.

[kiwiidb]

I envisioned something along the following lines, using the new NIP49 proposal:

• Next to their LUD16 a user has a Zapplepay-like service in their profile identified by pubkey/relay
• Subscriber produces a 7001 event signaling intent to subscribe
• The NWC service of the subscriber (Alby/Zapplepay) picks up the 7001 (and optionally asks the user for confirmation in some way through DM/email/notificiation) and then sets up the connetion with the service described above. The connection has a budget/period and also the 7001 event is referenced when setting up the connection.
• The Zapplepay-like service of the receiver is responsible for generating the invoices on behalf of the user in due time and using the NWC connection to pay them. It will also produce the zap event but clients should recognise that this is actually the 7001 author zapping. The subscriber should probably also get notified if an automatic payment like this happens.
• Cancelling probably be just deleting the NWC connection on the sender side. Clients need to validate the payments anyway, the 7001 event in itself doesn't mean much.

[AnthonyRonning]

I can see something like that working. Though ideally there's no external NWC third party necessary. I'm a bit concerned of the centralizing factor here for third parties storing user NWC strings, especially if it becomes a "one string to rule them all" scenario instead of a specific string per subscription action. It'll lead to needing bigger budgets set on the wallet side and will lead to more trust that the service provider doesn't steal as much of the user's funds as possible.

I'd like to see services with subscription capabilities bring their own NWC capabilities in house, or keep it on the nostr client side. If an NWC service is needed just to set a cron job, then I'd like that service to be as trustless and servicable by anyone as possible. I don't like that zapplepay has to be a thing, it's a hack and I don't want to see it being part of important integration points for nostr.

[vitorpamplona]

Maybe we can invert the architecture here. What if the pubkey receiving subscriptions must own a server that periodically parses 7001 events and sends ln invoices for payment in the cadence it offers? This would simulate the traditional way of paying for things (you have to create invoices and send them out when they are due).

That service can send the invoice over regular DMs OR we can create a new event kind (e.g. 7002) to carry the ln invoice in such a way that clients can create specific UIs for their payment, including automatically paying them with a Zap when they arrive.

Since the service already created the LN Invoice, it's not likely that it will accept double payment in the same invoice.

Payments then may be late, since there is no 24/7 service running on the subscriber side, but it could be ok.

[AnthonyRonning]

What if the pubkey receiving subscriptions must own a server that periodically parses 7001 events and sends ln invoices for payment in the cadence it offers

Yeah I think that would be similar to my "services bring NWC in house" comment. Though I think it would work with NWC as is, I don't think it needs a new event kind.

Regarding the "must own a server part", couldn't individual users take advantage of this as well? IE, Alice set up a subscription tier for her own npub, Bob wants to "subscribe" to Alice. Bob gives Alice a specific NWC meant for her, with appropriate budgets set up, and when Alice comes online in her nip88 aware client, she sends Bob an invoice via NWC. It would work better with a monthly cadence due to the async nature, but it still allows individual control and no server needed.

[vitorpamplona]

Bob gives Alice a specific NWC meant for her

This sounds weird. It's like giving my vendor a user/password access to my bank account so my vendor can pay their own invoices by themselves. Sure, we can set things up to make everything work within the budget, but it's still weird granting people the right to spend in my wallet.

Alice comes online in her nip88 aware client

If the responsibility of keeping the cadence is with the subscription receiver, then sure. If Alice is late because she didn't connect her NIP88-aware client, it's her fault. But being late will make things messy (people like exact predictability, e.g. invoices come on the 1st day of the month). I still think a better user experience should have a server for the cron job.

no server needed

Isn't the NWC a server? Otherwise, the 23194 payment request event, which is ephemeral, might never be seen by the NWC. Looks like this method requires both clients (Alice's sender and Bob's payer) to be online at the same time to make sure the ephemeral event is processed.

[AnthonyRonning]

weird granting people the right to spend in my wallet

At the end of the day, it's a payment request, not an explicit spend. Almost every payment app that exists allows payment requests to occur and internal controls around it.

Isn't the NWC a server

No, it's not. It works just fine with Mutiny mobile wallets. The requirement for server is not necessary, the user pulls these down themselves.

23194 payment request event, which is ephemeral

That's why I created this awhile back: #537

The Mutiny nostr relay stores these in order for users to be able to retrieve them when they are offline. Making NWC ephemeral & basically synchronous is a design flaw IMO.

I'll bring up that there's a lot of things in flight with NWC still and as long as some model can work with nip88, I don't think we absolutely have to know what that should be yet. That's just my opinion, I don't want to hijack nip88 with comments around NWC but I'll leave with those thoughts. I do think there's a lot of ways this can play nicely with NWC (or potentially NWC services if we expand upon those more) but I don't think it's an absolute requirement.

[vitorpamplona]

Agree, the connection to NWC shouldn't stop this PR.

Let's not forget a lot of people don't like using NWC, so we may need to make an option that is fully manual.

I think the cron job to send invoices should be a DVM. The receiver pays the DVM to send invoices to everyone.

[erskingardner]

In NIP-99 we use the same tag format but we call it price, I feel like we should standardize. I have no preference on which word we use but given NIP-99 is already out there and in use, it might be easier to use that.

https://github.com/nostr-protocol/nips/blob/master/99.md#price-examples

[pablof7z]

Ok, made quite a few updates; moved the tier event to a 37001 to use NIP-33, subscribing events can keep a copy of the subscribed event.

[believethehype]

NIP88 in its current form has been implemented in the NostrDVM framework and noogle client.