pull down to refresh

ty
lightning relies overwhelmingly on such 'custodians'
Not so much Lightning itself, but yes Lightning users certainly do... it's extra unintuitive steps to avoid the LSPs... you can always just fund an outbound channel to another node directly if you know what you're doing and are inclined to do it.
you can always just fund an outbound channel to another node directly if you know what you're doing and are inclined to do it.
The preferred way, but can this sustain all users .... #912374 👀
On another note, it would seem that BTCPay and and LNBits both do something similar to Lightning.pub, in terms of 'node sharig.' I'm not as familiar with LNBits, but using BTCPay, I know I can add users who can accept lightning payments into their 'account' using my node. When they want to withdraw, they can make a pull-payment request and then I forward the payment to their external wallet using a private, funded channel.
Do you care to differentiate lightning.pub from this style of 'node sharing?'
reply
It's the same model, an account system using a local database.
Our thesis is everyone is trust smuggling anyway, so we may as well make tooling that's transparent and reliable for that. With this people can make those trust trade-offs hyper-locally, community/business/family settings etc.
Also we've made the whole thing nostr native, the accounts are Nostr based and the API works over Nostr... this solves the networking issues with self-hosted and allows us to get wild with UX and Enterprise-class features on top of it.
For example, inviting friends or family to your node is just sending them a link with your nodes nprofile encoded, or use a lightning address for debits not just payments.
reply
trust smuggling
great terminology!
For example, inviting friends or family to your node is just sending them a link with your nodes nprofile encoded, or use a lightning address for debits not just payments.
Sounds exciting. Haven't tried it out yet, but I'll experiment sometime soon.
reply