nostr:npub1wxl6njlcgygduct7jkgzrvyvd9fylj4pqvll6p32h59wyetm5fxqjchcan and nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft highlighter are doing this. I’m no expert but I have recently started supporting three npubs with 21 sats a day as a trial run m, hoping for to expand the fun giving soon
Discussion
Yes, fully a know about them already. But I see these services more of a Patrion like offering, and not truly a subscription one 🐶🐾🫂
⚡️
I don’t follow. (Sorry!) could you explain the difference please?
Ok. One is reoccurring donation with no obligations or expectations. If it happens, great, if not, it’s ok.
Subscription on the other hand, promises to give you a service for a payment and the service terminates when payment is not made. 🐶🐾🫡
Ah I see now.
I approached it with a no obligations mindset but I can see how it could be considered as a ‘this for that’ arrangement
I think subscriptions and the pull model are a compromise to the limitations of fiat. I think the internet native model should be micro payments, pay as you go, pay for what you consume. Wallets should be able to trickle out payments that way
I played with a prototype for this a while back: https://oak-node.net/doc/trunk/doc/ons/ons-4.md
If there's any service provider interested, LMK and I could revive it.
Essentially comes down to:
- offer a LN address where customers can easily pay to: user_id@service_provider.com
- the LNURL-pay endpoint creates invoices with the user ID in the description
- in effect, any payment to that LN Address results in an invoice with the user's ID in the description
- user can setup a recurring payment (or stop paying, or change the payment amount) anytime, using any recurring payment solution
- service provider needs a simple piece of software that can lookup current user balance based on paid invoices with that User ID as description
- the service can stop or resume, based on the user account balance
