> somewhere in the middle are services that run the web server for people who run their nodes at home behind their routers
LN Address Bridges?
"Custodial" is the most neutral that comes to mind.
It tells you the wallet and the funds are essentially owned by someone else.
Seems to be the main point of adding the extra adjective in the first place. Otherwise you'd just say "wallet" or "LN address", done.
Are blinded paths possible with BOLT11?
Could it be added as a stand-alone feature? Or would it depend on other things that only come with BOLT12?
Saw it mentioned in the LND repo, but as a sub-task of adding full BOLT12.
Custodial
"Un-hosted" implies "hosted", both have the same effect on framing the discussion.
Yes.
When it first came out, "hosted" was strategically chosen to gaslight node-runners and newbies into down-playing the importance of self-custody.
The technical side of your spec may well solve a technical problem, but the title helps propagate a concept that's antithetical (through the ensuing discussions, changelogs, feature names, UI labels, review podcasts mentioning it, etc).
All I'm saying is creating a spec with "hosted" in its title is IMO self-defeating, if not even damaging long-term.
Did you say "hosted" LN wallets?
#[0] had some feedback on that choice of words 1y ago: https://dergigi.com/2022/06/27/the-words-we-use-in-bitcoin/
Thanks for the feedback. Yes, top-ups are probably the most intuitive. That's even a step forward from the current one-time fee models IMO.
> LN-only recurring payments without a 3rd party
This is exactly what I'm aiming for with the spec, especially focused on self-custodial wallets.
See this test account, where a 1 sat push payment was done every ~10 minutes: https://se.oak-node.net/profile?pk=NPUB17XS6KVLERTM384UA6ZDY0ZV5HJPPL32832K55FD330L2TA3S6H0S8HV3SR
It needs a "helper package" on the sender node to schedule the recurring sending, a glorified cron job that triggers a LNURL payment with a memo.
I'm open to ideas, though, if there's a simpler way to do it.
These would be automatic *pushed* payments, but I get your point. An optional y/n prompt, where yes results in an invoice via DM, sounds reasonable.
There is no solution now for people who forget to set the memo.
The LNURL with embedded memo would work for a one-time top-up, but won't help the user if he makes a mistake in the scheduled payment.
Now that you mention it, there might be a way to do this (only accept payments with valid memo) using HODL invoices. Adding to the list, thanks.
It already is open source, it's just not "polished" enough yet: https://lab.oak-node.net/ons-4-satship-enterprise/
Re: relay implementation: for now it supports nostr-rs-relay. If there is demand, I can look into other ones too.
Good point with charging per event writes. Adding it to the list.
You can always use a throaway anon account.
To make DMs "less persistent", the bot could use ephemeral messages. It could still encrypt them DM-style, but ephemeral = not persisted by relays.
Thanks, I didn't know it's been discussed already.
Yes indeed, what matters is what people will start using.
Thank you sir, good catch! Fixed and patched.
Great! Good point with WoS and limitations on the memo length.
I tried to get a QR going, but AFAIK I can't generate a QR for LN Address with a pre-defined memo. Will look into it tho, maybe I can generate an invoice. However that's another interaction with the LN node, trying to keep the comms to a minimum.
Re: cancelling subscriptions, fraud etc
The way I tried to address that is by letting the user choose 1) how much and 2) how often to pay. So for a service that's 30k sats per month, a user could pay 1k sats per day, or 30k / month, or go for 3-400k to pay for a full year in advance.
My thinking is the users who want more control can go for "smaller payments more frequently". Let's say for the user who pays small amounts per day, if the service provider rugpulls or goes rogue, worst case is the user loses 1 day of funds.
Could be I'm over-complicating things, but that's what I would do if there's a service provider I don't trust or somehow looks shady :)
Does this cover your point about fraud and cancellation issues?
True. That's also an option, but it has user friction (open DM, click pay, switch to wallet, etc) for every invoice.
I was looking for a way to automate that.
Until BOLT12 comes, the least-friction I could come up with was a push-based schedule done on the client side, either as a bot (self-custodial) or some wallet feature (custodial).
To paid relay operators:
I'm working on a concept for how service providers could add recurring LN subscriptions and I'd like your feedback.
I already drafted a spec and coded a demo for something that IMO should work with current LN tech (BOLT11 and LN Addresses).
Spec: https://oak-node.net/doc/trunk/doc/ons/ons-4.md
Demo: https://se.oak-node.net
Let me know what you think. Does it make sense? Do you see any major problems with it? Is there something I missed?
Thanks!
cc #[20] #[7] #[27] #[10] #[8] #[0] #[12] #[29] #[16] #[15] #[1] #[17] #[31] #[23] #[21] #[18] #[26] #[25] #[30] #[19] #[3] #[14] #[4] #[11] #[6] #[9] #[22] #[28] #[13] #[2] #[24] #[5]